I''m writing a multiplayer FPS, and i''ve never written any server code based on UDP before. what are good design ideas? i looked in the most recent posts and couldn''t find anything directly related to this. for example, should the server only have one socket, and recvfrom() with only that socket, or have seperate sockets for each ''connected'' client? if only one socket were used, i suppose the address returned by recvfrom() would have to be checked against other clients to see if a new client is trying to connect, etc. and if data arrives from two different clients at once, recvfrom() (or recv()) will only return data from one of them? also, would it be advantageous to have the client handshaking stuff done on a seperate thread? if the main server thread has to do all the client initialization (e.g. transferring player names, player skins, etc.), then i''m guessing more state information would have to be maintained per client and checked every frame.

I''ve been considering similar problems with a UDP networking class I''m writing - since noone knowledgeable seems to have replied to your post, I''ll tell you some of the stuff I''ve found, hopefully it''ll be helpful.

I looked at the Quake 2 source as a reference (easily obtainable from many sources), and it appears that only a single socket is used for server connections, and all handshaking/sending/receiving etc. is done by the main thread. This is likely a good idea for server performance reasons, as it eliminates the overheads for context switching etc. on a single processor machine. The disadvantage to this is the code is not easily scalable to multiple processor machines, so you may want to consider this depending on the exact specifications of your project.

The problem that you mentioned with data arriving from more than one client at the same time will never occur, that stuff is handled by the underlying network architecture. Recvfrom() will always return at most one datagram, in the order in which the datagrams are received over the network.

You also mentioned transfering player skins etc. It may be a better idea to open a seperate TCP connection for large file transfers, since UDP is not optimally suited to this. You may be able to use it however, based on how advanced the stuff you''re wrapping around the UDP protocol is - if you want to do this over UDP you may have to implement a sliding window algorithm etc.

thanks for the advice. it looks like i will use only one socket for all traffic. if it gets too complicated for asset tranferring, etc., then i will open a tcp connection just for that.

you mentioned that recvfrom will only return one datagram at a time, but what if there is more than one datagram from the same address? will recvfrom return more data than was sent in a single sendto call, assuming there are more datagrams available from the same client and they are all at the front of the network buffers. simply put, i want to know whether or not a call to recvfrom will get data from only one sendto call.

Yes, recvfrom() will only ever get the data from one sendto() call. It just returns the data from the first datagram waiting.