UDP

When you send data using UDP, you send blocks of data in packets which are limited by size. You are in control of the boundary of your message in this case.

If you use TCP, it has a stream interface. You send data, but you can't tell it where the packet boundaries are. I could send "ABC", and TCP could send it as "A" "BC" in 2 different packets. What this means for users is that they may need to keep track of message boundaries manually.

Back to UDP. If your structure will fit into the MTU size, you can just do a straight copy to send the data. Don't even worry about network byte order if you are only supporting little endian machines. If your structure won't fit into the MTU size, you will have to resolve that by sending smaller structures.

Additionally, your structure needs to be POD (plain old data). If it contains things like a std::string, std::vector or simply a Node *, it won't send as-is over networking without a bit of data serialization.

To clarify the TCP vs UDP scenario, you can actually make TCP act much more like UDP than it should by using things like TCP_NODELAY (disabling the Nagle algorithm). You can also force the stack to send out a TCP packet into fixed sized chunks provided they are within the maximum transmission unit (MTU) size. I definitely don't think you should do something like this, but I'm just making a point that TCP can be adjusted to act a little more like UDP.

Quote:

you can actually make TCP act much more like UDP than it should by using things like TCP_NODELAY

No, you can't. Any proxy or layer-4 router on the way between you and the destination will totally invalidate any assumptions you make here. As will any input buffering on the receiving end, and any re-sends because of any dropped packet. Do not believe that TCP_NODELAY turns TCP into a packet-based protocol in any useful way.

Quote:

Original post by hplus0603 Quote: you can actually make TCP act much more like UDP than it should by using things like TCP_NODELAY No, you can't. Any proxy or layer-4 router on the way between you and the destination will totally invalidate any assumptions you make here. As will any input buffering on the receiving end, and any re-sends because of any dropped packet. Do not believe that TCP_NODELAY turns TCP into a packet-based protocol in any useful way.

I'm pretty sure that routers aren't re-implementing TCP in the IOS. I've worked with Juniper, Cisco, and Foundry devices in the past. When they receive a packet, they look at the header and forward it along. I know that it doesn't definitively turn it into a packet based protocol, it's still stream oriented, but you can control the chunks that get sent out. So if you're expecting 800 byte chunks, you'll get 800 byte chunks.

There are many other factors that can ultimately make this fall apart, but all I was saying is you can send out data in fixed chunk size as long as it's less than the MTU (and probably even less than that because of things like GRE tunnels which require extra overhead on the packets ~4bytes per nested tunnel). Unless there's something really wrong with the network setup, an 800 byte (for example) message packet shouldn't be broken apart or clumped together by any network device other than the initial sender or final receiver. It simply isn't it's job. I agree that this isn't how you should program things though, but I've seen programs that have used CORBA that specifically depend on this behavior and do NOT support receiving multiple messages in one packet, or putting multiple packets to form one message--and they use TCP.

Yes, it's bad. Yes, it's not the right way to do it. But I've seen it done.

There exists routers that do layer 4 re-aggregation. For example, TCP over X.25. Other applications may include satellite internet and various microwave providers. Not to mention cell phone IP, which may go through enough layers of proxying to add several hundred milliseconds of latency to almost any use case!

Even with bog-standard TCP-IP-over-ATM (like you get with a standard DSL) or TCP-IP-over-Ethernet (like you get within the office), the first packet you drop will cause a re-send of merged data, so that the "packet" you sent will suddenly not be atomic, even if it's less than half the MTU. This means that you cannot guarantee "packet" based behavior from a sending node, no matter what the IP infrastructure may be.

Now, on the receiving end, there will be an incoming buffer, which will not care at all about what kinds of packets it receives. When you call recv(), it will return as much of the available buffered data as possible. Thus, as soon as your receiving end calls recv() once in an interval where two "packets" were received, your "packetizing" hack (that doesn't work) will stop working on the receiving end, too.

No, you cannot guarantee individual packets over TCP, no matter what the infrastructure.

Text is binary data, use ascii characters 0 - 256 as binary numbers.

Just watch out for lost packets, if you use UDP. :)

Oh yeh, and if you send "player position" in the client message, it could be hacked to allow people to teleport around in the multiplayer game, so thats a total nono if you want to lockout cheats in net games...