Hi all... I just read the complete Beej's guide to network programming and now I think a lot about how I will make my game network. First of all, my game is a FPS, where you are a simple sphere rolling around shooting at each other. That's why I think UDP could be a good choice since it's really fast, and the game is fast paced. I am ready to make myself a queue system where you have High priority packets Low priority Packets Acknowledge Needing Packets ForcedRouting packet etc The thing is, recv() and send() will always tell how many bytes where sent or received and so on... That bring me to think that a good approche would be to convert into char[] all data that has to be sent, so that if I send 512 bytes, and 510 is returned, ill be able to tell my program : ok this packet needs to resend the last 2 bytes, since they already are in an array. One question comes to mind, if 510 is returned like in my exemple above, can I be sure that it's the 510 first bytes ? Another question is : Would it kill my process time to always convert my float to char[] to send them ? Thanks for any help, by the way i never did network programming, i'm just curious.

You should probably do some more research into how TCP/UDP works.

UDP is not really "faster" than TCP, it just handles data differently. Most people see TCP as being slower because it makes sure that data is sent in order. That means if a packet is damaged or dropped before it gets to you, the TCP stack will not give any data to the application layer until that packet has been retransmitted and recieved. UDP also has a smaller header, so it uses less bandwidth (but that is mostly negligible nowadays, unless you send very small packets)


Your application (USING UDP) will never recieve a partial packet from the network. The network stack will drop the entire packet (in the case of UDP).

If you use TCP, you can get fragmented packets. (Which is what I think you are describing).

With TCP you will have to keep track of where one packet ends and another starts. It is a stream based protocol, so you cannot be assured that the packet you recieve is part of a whole packet that was sent, or multiple packets that have been recieved together.

You will have to write your own application level header to do this. The easiest way is to prepend the data with an integer describing how many bites are in the data. Your application will read that number in, and keep a counter of how many bytes have been copied. when that many bytes have been recieved, you can then dispatch that packet to whatever system in your application will handle that message, and the process starts over.

It doesn't matter what kind of data is in that buffer. Treat the buffer as if it is an array of chars (like you said). Don't actually convert the numbers to an ASCII representation.

Based on my understanding of UDP and winsock, sendto() reads the data buffer from first element to last element not exceeding buffer size. Unreliability is reflected on the order of the message buffers.

Kuphryn

Just to be clear, with TCP you will never get any out of order data, or skipped bytes. everything will be sent in order and you can be assured that if you get 512 bytes, those bytes are contiguous and in order.

And UDP, you can assume that if you recieve a datagram (packet), that datagram is complete. However, you may recieve datagrams out of order. The data within a datagram however, will be in order.