1
\$\begingroup\$

I wonder if server responses on client operation requests should be tied by some operation id?

Tied would be when:

1.Client app sends request to server to e.g. buy item X, and sets operation id as ID.

2.Server responds with operation id and true or false. This would mean that operation with that id was successful or not.

Untied example:

1.Client app sends request to server to e.g. buy item X

2.Server responds with just an updated data of item X, where new item owner would be mentioned. This way client can check if owner name is equal to it's own name and if true, assume that item was bought successfully. Same response data could be sent to other clients, to let them know that item X was bought by someone.

Which approach is better?

IMHO untied is better and simpler in implementation, but it feels like there can be so many edge cases which I don't see right now.

\$\endgroup\$
1
  • 1
    \$\begingroup\$ I have buying implemeted like this: Client sends buy request. Server sends information that it removed you money. Server sends information that you recieved an item. (Both of those are used for another stuff, like looting). Or server sends information message that you cant buy this item (this is used for other stuff too, like telling you that you already looted something). So its more like your approach 2, and it works quite well. \$\endgroup\$ Commented Aug 22, 2013 at 11:46

1 Answer 1

Reset to default
0
\$\begingroup\$

Consider how you can remove ambiguity in your design. A combination of the two choices or the second choice would do that well. For example, you can also send back an enum letting the client know bit more information, something like ErrorItemPurchasedByOtherPlayer or SuccessItemPurchased. Of course enums would be converted into a byte or two to simplify the data transfer. Simply returning true or false is ambiguous because it doesn't really give you much information.

Returning an enum, along with the updated item information would give you all the information you need. I don't think it's necessary to inform other players who purchased the item, but you could push an update on item availability to other players also viewing the store when an item is purchased.

Your untied example is the same as your tied example, it just contains more information (it's trivial to extract true/false from the supplied information). So there aren't edge cases added.

\$\endgroup\$
2
  • \$\begingroup\$ I've intentionally made both examples same. Problem is not about buying item X. It's about the way client should exchange data with server. \$\endgroup\$ Commented Aug 22, 2013 at 14:53
  • \$\begingroup\$ @DenisNarushevich I know they're doing the same task. I'm talking about the information you can get from them. You can get the same information in your untied example that you get in your tied example. You were worried about adding edge cases, I'm saying there won't be any. The tied example data is a subset of the untied example data. \$\endgroup\$ Commented Aug 22, 2013 at 14:55

You must log in to answer this question.