Splitting data for UDP

You don't need any "functions" (though you might like to write your own to do that). Just send the first X bytes of the memory buffer, increase the pointer by X bytes, and repeat until the buffer is exhausted. For concatenating, do the same except you write into the memory buffer (allocate a buffer as large as possible, ideally by sending the length of the incoming data first, or if you must, reallocate a buffer to increase its capacity when you run out of space, for C++ you could use an std::vector, but for optimal performance you must know the length of the data before receiving it).

Please note that sending large data buffers over UDP over the internet is extremely unreliable, and you will almost certainly not receive the buffer you originally sent (packets will be missing, and possibly in the wrong order). Also note that using UDP "because it's experimental" instead of TCP is probably not the right reason, in fact usually it's the opposite. TCP and UDP have rather different semantics, you can't just hotswap them and except things to work efficiently, or even at all.

Enet is a small and open source UDP wrapper which can be found here http://enet.bespin.org. It uses a Quake3 style protocol to minimize latency.

It manages all packet fragmentation for you, all you have to do is provide a pointer to the data you want to send and the size which can be a few bytes to many megabytes.

You should take a look on this:

http://www.ra.is/unlagged/network.html

http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking

The idea for data concatenation was to tag packets with ID's to see order them on arrival or to see if there is any missing.

Thanks for the link.

want to use UDP

"experimental"

want to send big buffers of data

Unless you

• need shortest possible latency and cannot ever (that is, rarely) afford to wait for a resend
• do not care too much if some bit of data is lost (i.e. you can simply and quickly ignore lost datagrams)

or

• do this purely out of academic interest or for the fun of hacking together your own protocol

you are probably doing it wrong by using UDP.

UDP is not any better or faster than TCP, but it is much more complicated to get right since it has no congestion control, does not enforce order and has no reliability layer. In particular, sending large amounts of data is non-trivial to get right.

Using TCP, you can throw kilobytes or megabytes of data at the socket (usually with a single API call -- on my Debian box, send will happily accept hundreds of megabytes in one chunk) and you are guaranteed that it will arrive on the other end. And no, sending a megabyte of data via TCP will not be any slower than sending it via UDP.

The notable difference between UDP and TCP is that TCP will resend packets that are lost and provide the data on the other end in the correct order with no "holes". That means that in presence of packet loss, TCP may sometimes have slightly more latency because it may have to wait for a resent packet. Other than that, they perform exactly identical.

Except of course, TCP's flow control will dynamically adapt to path MTU and router capacity whereas UDP will simply throw your datagrams away when you exceed some obscure limit such as filling a router's forward queue.

For urgent realtime applications where you can just use the next tiny datagram that arrives instead of the lost one (say, for position updates in a fast-paced game that come in 10-20 times per second), UDP is a big win. However, for bulk data, you should really, really, really use TCP.