• Advertisement
Sign in to follow this  

General Client/Server questions

This topic is 3965 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello all: How would you handle communications with Asynch UDP? I am thinking that my game loop has access to a set of buffers that the socket can fill. Basically switch a flag each loop so that WHILE(loop=0) GAME processes packets in buffer A UDP adds new messages to buffer B WHILE(loop=1) GAME processes packets in buffer B UDP adds new messages to buffer A I am guessing that input (from client to server) is simply gathered once per frame? However, if I have an asynch model for keyboard input (even fires on keypress) then I would have to add those messages to an outgoing buffer similar to input. I don't want to be sending from the same buffer that I'm adding messages to just because of the possibility of sending an incomplete message. Another question is, say player presses UP_ARROW to run forward. A RUN_FORWARD request is sent to the server, validated and an OK_TO_RUN or NOT_OK_TO_RUN is sent to the client. Does the client wait for the response or do I just start running and POP him back in the event of a denied request? It seems like the server needs to validate some things before we let the client display them (CAST_SPELL_X). The server would have to determine if it's possible for the client to cast spell X and if so ONLY then would the client perform the animation. I know similar questions have been asked but they are darn hard to find with the new search functionality (when you can't narrow searches to a specific forum even). So feel free to point me to any relevant posts, good books on this material, etc. Thanks for reading and any replies! Webby

Share this post


Link to post
Share on other sites
Advertisement
You're mixing two models, which may or may not work.

Fully async communication is just that - everything is event driven. You have no loops, no sequential processing, no strict buffer processing (although they are used).

Further it also depends on API used.

With async you have no loops. You just trigger the events as needed, or wait for operations to occur. But there are no loops anywhere.

Boost::ASIO for example allows something like this:

void start_receive()
{
socket.async_receive_from( buffer, address, &on_receive )
}

void on_receive()
{
unpack and verify buffer;
lookup client object based on address.
client->on_receive( buffer ); // this one processes the packet
start_receive(); // start listening again
}



Sending is equally trivial, just async_receive_from is replaced with async_send_to.

This allows for arbitrary concurrency, since each this loop is independant from number of threads. All async_ calls return immediately. The callbacks will always be called in a different thread. As such, you don't need to worry about many dead-lock situations, there's even provision for impliciy thread locking within io system.


Quote:
Another question is, say player presses UP_ARROW to run forward. A RUN_FORWARD request is sent to the server, validated and an OK_TO_RUN or NOT_OK_TO_RUN is sent to the client. Does the client wait for the response or do I just start running and POP him back in the event of a denied request?


This is generally bad. The ability to run should be validated completely client-side. Server may send back the confirmation, but until then, client assumes the command went through. If server later notifies that isn't the case, then you rubber-band the client back to authoritative location, either location reported by server, or, if you use simpler synchronization, to last known good location (for example from where you started the movement).

If you wait for server confirmation before triggering the action, the game will be unplayable, possibly even when on LAN (although on LAN you can sometimes use fully synchronized movement - depends on type of game).

Just keep in mind that even 50--100ms command latency can degrade user experience a lot.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement