My server is running at lets say 40 fps, and does a non-blocking recvfrom every frame. What if there are more than 40 packets per second? Do they get stacked up? I assume they just get lost, so if the server gets 100 packets a second, then a random 60 of them will be lost right? That brings me onto my next question, what if a packet is sent, but I only recvfrom about 5 seconds later? How long does a packet stay in the buffer? Or does it stay there until overwritten by another packet? So if 7 packets get sent to me in under 3 seconds, then i do a recvfrom, will it recieve the last one? or will it not recieve any? And onto my final question, reliable packets. You mark important messages with a reply request, and if you dont get a reply in say, a second, you resend it. This brings up a load of problems because it requres timers, also you have to somehow number your packets, so if the other end does get your packet, but the acknowledge reply packet gets lost, it doesnt act on the same packet twice. Is there not an easier way? Like some kind of API function, or even a third part library that takes care if this ugly stuff? Ok, thats all I can think of, any help would be much appreciated

Im not sure about your questions, but to overcome the first problem, you just keep calling recvfrom until there is no data coming any more that frame.

[edited by - Tylon on May 19, 2002 7:12:36 AM]

a) The packets will wait in the queue.

b) They stay there until you take them out. If the queue would overflow then the sender blocks. You always get packets in order of reception (which, with UDP, isn''t necessarily the order of emission).

c) You will need a book on networking, there are many possible schemes. A possible method is to include sequence numbers in your paquets and check them on the client side, and sending a NACK to the server if paquets are missing, so that the server sends them again.

d) Yes, there is something in the library that takes care of all that stuff, that''s called TCP.




Documents [ GDNet | MSDN | STL | OpenGL | Formats | RTFM | Asking Smart Questions ]
C++ Stuff [ MinGW | Loki | SDL | Boost. | STLport | FLTK | ACCU Recommended Books ]

Thank you, that was very helpfull.

Im trying to optimise this for speed and large number of clients, therefor I dont think TCP would be a suitable choice. What I would really need is a protocol thats exactly like udp, except it has reliable packets built into the API so I dont have to handle them . I guess im asking for a bit too much though ;o

Why not use a mix,
UDP for packets that can be lost and tcp for important information?

For reliable data, TCP is one of the fastest solutions you''re going to get EXCEPT that it throttles the connection, which it does for a very good reason.
One of the problems with reliable data, is the receiver can''t say "I haven''t received packet X" until it receives packet X+1 (and assumes that out of order packets are lost and requests a resend). This can slow things down if the sender is only sending packets every so often. There are a number of ways around this, most of which use some sort of timing mechanism, so i suggest you learn to live with timers

Hi there, I am in the process of using UDP to get to grips with network programming for games, what''s the best solution for speed as in I don''t really care if sent packets are received so I thought that client''s send data directly to the server and the server send data to the clients via a multicast is this the best method for such application ??

Thanks

-Nik

Reliable UDP without using TCP can be done without too much trouble.
You can check out http://www.replicanet.com/ as this offers a complete solution for reliable UDP.



[edited by - fnagaton on May 24, 2002 11:17:48 AM]

Multicast is probably not common enough to use as the only way of transmitting data, you should transmit seperately to clients who can''t access a multicast server, or even if the server can''t access a multicast server. The article on multicasting on this site explains it quite well and has some sample code also for this.

While TCP waits for message n+1, with UDP you can have the system tolerate up to k missing messages. If it receives message n+k befor e receiving message n, then complain and have the server re-send packet n ("NACK n").

Note that all networks even support multicasting, and that you cannot arbitrarily grab a multicast address (there is an application process).

Documents [ GDNet | MSDN | STL | OpenGL | Formats | RTFM | Asking Smart Questions ]
C++ Stuff [ MinGW | Loki | SDL | Boost. | STLport | FLTK | ACCU Recommended Books ]