Jump to content

  • Log In with Google      Sign In   
  • Create Account

Splitting data for UDP


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
5 replies to this topic

#1 boboS   Members   -  Reputation: 149

Like
0Likes
Like

Posted 08 January 2014 - 06:48 AM

Hello. Maybe this question was asked and answered before but I was not able to search it to the forum.

 

  I want to use UDP for a project (its experimental thats why I wont use TCP yet). I want to send big buffers of data and set fragmentation off on UDP so I need a simple example on how to split and concatenate data back. At least a hint on what functions to use for fragmenting data in memory. An also where can I find more documentation on memory data management in C++ of any kind ? 

 

Thanks



Sponsor:

#2 Bacterius   Crossbones+   -  Reputation: 9281

Like
0Likes
Like

Posted 08 January 2014 - 06:58 AM

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.


The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#3 Tispe   Members   -  Reputation: 1046

Like
0Likes
Like

Posted 08 January 2014 - 07:40 AM

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.



#4 vinnyvicious   Members   -  Reputation: 387

Like
0Likes
Like

Posted 08 January 2014 - 07:46 AM

You should take a look on this: 

 

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

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



#5 boboS   Members   -  Reputation: 149

Like
0Likes
Like

Posted 10 January 2014 - 04:52 AM

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.



#6 samoth   Crossbones+   -  Reputation: 5034

Like
0Likes
Like

Posted 10 January 2014 - 06:33 AM

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.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS