Hi guys, before you put this topic into the worthless big, it''s not about ''how do i receive a packet'', but rather the efficency of it. The way I''ve seen it, UDP packets get lost, received in the wrong order, etc. The way I was doing for testing purposes was storing all received data in one buffer. This became an issue when I added code to detect when a new sender starts sending data, to finsih working with the old data so the two players'' data doesn''t get mixed in together. Then I say ''what if in the mix of players, packets don''t arrive in order''. Is this an issue? I know packets can arrive in the wrong order, but how exactly? Lets say a simple sento call that sends a 24byte structure. This can theoretically be split up? My new method is to create a small buffer for every client. When a data comes I parse through each player to find which one sent it, and add to their buffer. When enough information comes I process that packet and clear the data that was processed. Your thoughts, Chris

I use a message style interface where received packets are placed onto a prioritized message queue. My queue is of fixed sized of n elements where n is set to a suitably high enough value that I will know that for each loop that all messages will be processed before I run out of free message packets. In rare cases where if I run out of free messages then the buffer reading is put on hold till there is a free message. But this shouldn''t be a problem as I assign way more than enough message packets to handle a typical loop. Like wise I use a message queue for sending packets. I set the number of elements to a suitable size that lag will not factor in too much from having too many items in the queue. If the queue is filled completely that means that I am sending too much data than what the network can handle and I can throttle it back and also overwrite non-important messages still pending in the queue with more important messages.

The single sendto() at the UDP layer may get fragmented on the net, but it will be reassembled and only handed to you as one contiguous packet on the other end. The re-ordering that sometimes happens in UDP is between successive calls to sendto().

Thus, if you call sendto() with X bytes, you will receive a packet of exactly X bytes on the other end, if it makes it. It may, possibly, make it twice, which means you''ll get two packets of X bytes. I actually like this property of UDP; it splits packets for me, I don''t have to send length+data like you would in TCP.

I''d suggest allocating an instance of some "connection" object per player that connects, and put them in a hash table based on source IP and port number (use recvfrom() to get this for each packet). Then, when you get a packet, look up the player object in the hash table, and pass the packet to that object. That way, you can have N players and their data won''t be mixed up. When you don''t find a player in the hash table, that means a new/unknown player sent you the data, and you can do the appropriate thing.