The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

I've implemented a client/server network game architecture, but I'm running into an issue (using SDL_net).

I have the server broadcasting all the states of game objects to each client on every frame. On each client I listen for updates from the server on each frame (as well as sending input events to the server). Sometimes a specific client may take a little long to parse/deserialize a given server update, but meanwhile the server keeps sending new updates to that clients socket queue. The client is done parsing so each server update just gets concatenated on the previous update in the socket queue. Once the client is ready, it will pull down data from the socket queue, but the contents are bigger than the max buffer and the program freezes/crashes on SDLNet_TCP_Recv. I therefore have no ability to error trap or test the size of contents before I have to call this receive function.

I don't see any way for the server to "flush" the contents of a socket before it sends a new update to client socket queue, nor a way to make the socket queue size match buffer.

Please don't tell me to increase the buffer size.

Any help would be greatly appreciated.

How much data is going from server to client at any given time?  Are you able to do any prediction on the client side, and infrequently send full updates to the client?  Are you able to thread some of the network processing?

Also, TCP might not be a good option if you are sending frequent and large data dumps.  As long as you're sending the full dump each time, UDP might be a great option.  It's not reliable, but if the client misses n packets, it doesn't matter because you're always sending the full state.


In terms of flushing, that's something you'll have to do.  If you know that each packet/message has a known length and you are able to skip packets, you'll have to manually read then dump the data rather than read and process.
Also, what sort of processing happens?


On Thu, Jun 16, 2016 at 7:37 PM, jsalina wrote:

Small amount of data - buffer is 1024 bytes. I would switch over to UDP if I was sure the same issue wouldn't happen (server updates getting concatenated on each other). I want to guarantee the any given client socket queue has no more than 1024 bytes in it. I could send updates less frequently, but depending on latency variances I might need that speed. I could look into processing the incoming server update data in a separate thread, but never ventured there before...

If there was a way to flush to the socket I would, but doesn't appear SDL_net gives that ability (at least with TCP - it looks like UDP has a FreePacket() method).

An obnoxious hacky option would be for the client to send the server an update once it's done processing, and until the server receives that update, don't send anymore data to that client since it can't get it to anyway.

Nevermind I found my issue... I was putting 1024 in the maxlen field of the receive method below, it needs to be 1024 - 1 and it works fine. Sorry for the trouble.

int SDLNet_TCP_Recv(TCPsocket sock, void *data, int maxlen)