Operation Request/Response loop

bsdll

I have a working client and server implementation based on the blank server setup.

To the server, I have added a custom operation in the OnOperationRequest procedure which then creates a SendOperationResponse call back to the client.

In the client, I have a while(true) loop which just waits for a keystroke. It also calls peer.DispatchIncomingCommands(); just to make sure everything is being processed.

In the OperationResult procedure I have added a handler for my custom operation. It just writes out some data to the screen, that I know came from the server.

My question:

The handling of the operation response it totally unlinked from the operation request. It seems that you need the call to peer.DispatchIncomingCommands(); to make sure it processed them.

How can you make sure that the operation response is valid before allowing anything in the game to continue?

For example, in a trading game, you make the request to trade an item with another player, the server checks and the other user doesn't have the item any more so denies the trade. I would think that the client should wait until the server responds before it allows the user to do anything with the traded item. But with the threaded concept it seems you have to assume the item is traded, allowing the user to manipulate it before it's declined.

Thanks,
Darren.

dreamora

No you don't have to allow the user to modify it. instead you wait for the operation response and when you get it you set the state accordingly while its state would be pending while the operation is processed.
as the server gets back in less than 1s for pretty sure normally its no problem

bsdll

So, with your reply and a bit more thought, I think I can see this now.

What the client 'wants' to do and what the client is 'allowed' to do aren't necessarily the same thing. And then when the server allows the client to do something, the update on the client needs to be independent of the actual request.

So in my example, you make the request to trade, at which time the client should be locked from manipulating (eg destroying, trading, modifying, etc) the object. Totally independently, the client should then watch for a request to reload the user's items, at which time if the trade was approved the item would no longer be in the hand to be manipulated anyway.

Is that a better flow?

It's just different in the sense that I have always programmed with a request getting a response before action can continue, whereas this seems to be based on two independent processes.

Thanks,
Darren.

dreamora

Yes that flow would be better / how you would actually do it.

I am not sure how you ever were able to program differently, cause with asyncronous requests that go to an external point of authority there is no way around it without very ugly and unmaintainable code. Its pretty normal that the external point will come back to you with a "callback" which is what is happening here too when you get the event for example. You will need to handle stuff seperately and distinct of each other anyway, cause lets assume the case where a user sells something: that will not only get you one event sent back but multiple ones:
1. that tells the client that selling is ok
2. one for the update inventory / item removal
3. one to update the money the player has
4. potentially another one if he sold an item he had equipped to update the appearance.


Perhaps you are for some reason thinking that the request -> answer will need eternities to complete, not a few hundred ms which is below the normal reaction time of many users and even more so below it if you have a halfway polished UI with transitions effects that take longer and the request + answer

bsdll

What I meant was pre-photon, using SOAP, I just asked the server to make the trade, paused the client and waited for a response. It wasn't real time (but was < 100ms so the pause was irrelevent, it's not an action game).

Thanks for your replies, I am going to re-architect my design into requests and responses, seperating out the two different logics. I knew the timing was faster than the client could redraw, is it was more the split of the processes.

In regards to your steps, would 2,3,4 not be done in one response? Or are you suggesting to have different objects do their update and then fire off a message to the client to update as well.

Thanks,
Darren

dreamora

No, 2,3 and 4 can not happen in one response at least not reasonably out of my view

Reason is that all of these 3 things can happen in reaction to other interactions too (for example unequipping something, looting money, looting an item) and you don't want the same functionality present in dublicate in 50 places, thats a nightmare to support if you can do it with distinct focused events and event handling on the client so you have "a single point of failure" to debug and maintain.