Quote:Original post by Indigo Darkwolf
In C++, select() only tells you what sockets are ready to be read from. You would actually receive the data with recv() and recvfrom(), and both of these functions return the number of bytes in the packet.

And yes, normally you only create and bind a single socket in UDP.

thanks for replies!
This is my server concept:
client can send two types of datagrams, both comes in 1 packet.
Thanks to buffer size and max packet size I do not need to know how big the packet is and fetch it whole, I just then need to interpret the data correctly becouse of datagram data type.
All theese datagrams are to be red on my server listening socket.

So after I read the first datagram, do I call select function again to see wheather there is another datagram on the socket and repeat this until I have red all data from the socket? Or should I rather set unblocking state and repeat recvfrom until I get WOULDBLOCK error message? What is a better approach?

The beauty of UDP is that you don't necessarily have to do anything the like. Data arrives in packets, and either you get a packet or you don't. There is no "repeat until all data has arrived" like with TCP. When a different packet arrives, that's a different entity, but again it will be complete or it won't arrive at all.

Also, you don't even necessarily need select at all. It depends on your implementation of course, but in principle, you can get away perfectly well by just blocking on recvfrom. When a packet arrives, the complete data including sender's address etc. is already there when your thread wakes up, and while no packets arrive, you don't consume any CPU cycles at all. You also only have one syscall instead of two or three, and none of the overhead associated with copying file descriptors to kernel space etc.
For a game, which will usually want send out some data periodically even if nothing is received, you will probably not want to block the main thread, but do this in a separate thread, but that's just an implementation detail.

Thanks!
I think I am getting it. This is my server.
Server will have a list of structures, each for one client that the server serves to. Server expects to receive the packets for each client in a way that if it reads num-of-clients game packets, all the players in the list have their new state.
Those players that did not get updated are marked "connection idle". After this server immediately starts to read packets until it has red them all or reads until num-of-clients packets are received again. During this second read server updates players that are marked "connection idle"(also along with other players) if their state comes in those packets. If a player keeps "connection idle" for more than 100 server peek iterations the player is marked as "connection offline". This double read of game packets also promises for server to have more up-to-date data after the peek if server cpu goes bound.
My server then uses player states list to compute answers to clients.