I’ve used TCP/IP up until now; I just need to know if you can always count on a packet being sent to arrive in the same size/intact structure. I don’t care that I have packet loss. I just need to know how to read the data I get over the network. I know with TCP/IP You save the stuff and read it back using 'packet' headers and such, because it’s a stream and is reliable. What about UDP, if you send 3 ints. If the other side does get the packet, will it be 3 ints or will it be 1 int and 2 bytes of the second int? If that is the case how would I take care of that? The clients are all receiving and sending from different computers. Thanks. If anyone has a link to some where that covers this it would more then welcome, I didn't find anything on this in particular. most of the stuff I found was about udp losing packets, and such.

I beleive UDP packets arrive intact; they contain the data you sent them with -- if you send a packet with 3 ints, then, if it arrives at all, it will contain those 3 ints in the order you sent them. The question is: will it arrive? UDP packets are not guaranteed to arrive, and, if they do arrive, they are not guaranteed to arrive in the order you sent them (I think).

Can anyone second that they stay 'packetized', I know that they might not arrive, I just need to be sure of the nature in which they work before I go and write the netcode for this game XD, would hate to do this and then in the end have it work totally diffrent and go with a totally diffrent setup.

When reading from an unreliable datagram stream you must read everything available in the stream, to quote MSDN: "For unreliable protocols (for example, UDP) the excess data is lost; for reliable protocols, the data is retained by the service provider until it is successfully read by calling recv with a large enough buffer." (although you may be able to use MSG_PEEK flag) You can use ioctlsocket with FIONREAD to determine how much data is waiting to be read (assuming windows).

You will recieve only complete messages, never pieces. Note that data corruption is still possible, although not likely. This is due to the small size of the CRC.

ok thanks!