Jump to content
  • Advertisement
Sign in to follow this  
Core2Duo

UDP inquiry

This topic is 3687 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Kindly enlightened my UDP knowledge, In my experience TCP delivers the message like the FF: <My complete message block> or <My complete message block> or <My complete message blo ck> or <My comp lete message blo ck> Contrary to TCP, does UDP always deliver the packets as a complete message block? if the whole packets are corrupted or not arrived as a whole it will be dropped But it will always delivered the message as complete block like the FF: <My complete message block> or May not arrived at all if packets are not complete. Thanks.

Share this post


Link to post
Share on other sites
Advertisement
It's a bit trickier due to the way API is designed.

When you call recv() or recvfrom(), you read contents of UDP packet a whole. Any data from that particular packet not recv()ed is discarded.

Trying to send() over UDP is atomic. Either entire call succeeds and data is sent as whole, or call fails.

So in this respect, how you send() something is how you will recv() it. The reason for this is direct consequence of UDP being stateless and lacking any kind of flow control.

Quote:
May not arrived at all if packets are not complete.


Packets may also arrive in different order than they were sent, multiple times, or, on a very rare occasion be corrupted. There is also no notion of "all packets". Each UDP packet is independent, and the limit on maximum payload is ~64k. It typically doesn't make sense to use UDP for large amounts of data.

Note that sending UDP packets larger than MTU may cause problems with certain ISPs or routers.

Share this post


Link to post
Share on other sites
That is correct. UDP does not split packets. When you send a packet, you will either receive the whole packet or nothing.

Yes too, the theoretical maximum size that a UDP packet is around 64k but it really depends on your local socket send/receive buffers, the destination and any routers along the way. It's probably best to keep messages less than 8192 (WinXP I think is this) unless you control the entire network you are communicating on. If the data you are sending is larger than this, you will have to do your own splitting and implement your own error recovery if you can't afford to miss a packet.


Hope that helps,
Dave.

Share this post


Link to post
Share on other sites

Thank's guys,

The reason I asked this, is that I'm thinking whether I will use my existing TCP packet parsing routine for gathering complete message block from collected received packets which puts on que, my TCP routine message block parsing is somehow intensive due to the nature of TCP which is stream base.


My Received packets Que
-----------------------------
1. <#1headers_paylo
2. a_footers>
3. <#2headers_payload_footers>
6. <
7. #3headers_pay
8. load_fo
9. oters><#4headers_pay
10 load_fo
11 oters>



Quote:
Original post by Antheus
So in this respect, how you send() something is how you will recv() it.


Quote:
Original post by javapimp
UDP does not split packets. When you send a packet, you will either receive the whole packet or nothing.



If this is the nature of UDP, Well, I think I'm in luck, it is much easier to collate a complete message block from collected received packets on que, since I will only need to check each row if it is a valid data or not and do some appropriate action for late messages, acking and dealing with duplicate messages.

So, using UDP I should expect the FF scenario, in this example, message 1 and 2
is not inorder message 3 was dropped and message 4 was duplicated.


My Received packets Que
------------------------------
1 <#2headers_payload_footers>
2 <#1headers_payload_footers>
3 <#4headers_payload_footers>
4 <#4headers_payload_footers>


Thanks all.



Share this post


Link to post
Share on other sites
I think I misspoke when I recommended keeping the packet size small.

The maximum size of a UDP packet is ~64K: 65535 - sizeof(IP header).

IP _will_ fragment the UDP packet if it is larger than the minimum MTU and it _will_ reassemble it at the destination. I believe this fragmentation/reassembly occurs at each hop and the amount of fragmentation depends on the minimum MTU of the two nodes.

For instance, the default MTU for windows is 8K I think. If your datagram is larger than that it will be fragmented into 8K chunks before it is sent and reassembled at the next node. If the MTU at the next hop is say 4K, the datagram will be fragmented into 4K chunks and reassembled at the next node. I think most recommendations to keep UDP datagrams small (within the MTU) is to avoid the overhead of fragmentation. (Please correct me if I'm wrong. I'm just learning this stuff myself).

As for losing data, UDP does not guarantee the packets will be delivered, nor the order. However, it is transactional in that if it is delivered, it will be whole. If you send a 64K datagram, you will receive all 64K, or nothing. If the datagram is fragmented, it will be reassembled in the proper order (barring possible corruption of the fragments, but that's what checksums are for). The datagram should arrive exactly as it was sent.

I hope that helps. Someone chime in if I've misspoken somewhere. I won't be offended if I'm corrected. :-)

Thanks,
Dave.

Share this post


Link to post
Share on other sites
That's pretty much it. With UDP you can have packets out of order, duplicated or lost, the packet itself will be automatically fragmented into and re-assembled and that is completely transparent from your end.

If you want a reliable delivery, you'll have to do the dirty work yourself (retransmission, ordering, acknowledgements...).

Share this post


Link to post
Share on other sites

Thanks guys, most of you mentioned about maximum payload size limit, sending large amounts of data, sending 64K of data and MTU limitation. Thank's for reminding me that guys, Tho, I did not respond to that from my previous post, But...

Isn't it cool to say to your end user, Yes, Using my network library you can send your messages larger than the MTU and you dont have to worry about network bandwidth =)).

Heh, just kiddin, most you guys knows how to deal with that, which you already mentioned from your post, splitting payload and doing the dirty works mentioned by oliii =))

Seriously, who want's to send 64Kb or even 15Kb of data for network games, most
network games only need small bytes of game information concurrently.


Here's how I send my a large payload of data:

PayloadPartitionSize = 256 //Bytes
SendingFrequency = 128 //ms

Even the end user send large data, Internally, I will partition the payload in 256 bytes, with this I'm sure the total number of bytes per send will not exceed 300 bytes ( 256, lib header, protocol header ) = more or less 300 bytes. the partitioned bytes will be re-assembled at receipient's end automagically.

128Ms sending frequency will be 7 times per second plus some internal sending say 3 times per sec, more or less I will be sending data 10 times per second, that will be 10/Freq * 300Bytes = 3Kb/Sec.

With this settings, I'm sure I will not exceed 3Kb per second, which is suited
to the current network game im making ;))

Now, if I want to create a certain game type that requires larger than 300bytes per packet and requires more than 3Kb/Sec. All I need to do is adjust the PayloadPartitionSize and SendingFrequency settings.

I hope my implementation is correct and efficient


Thanks again, every assistance is very much appreciated.







Share this post


Link to post
Share on other sites
I don't see 15K as being hard to reach. Especially with state-based methods (the sending the whole game state in one shot for example).

You also have to remember that with every packet you send, there is an overhead attached (the UDP header). So effectively, the lower the number of packets, the less overhead you get. The MTU on a home user line is usually around 1100, 1288 bytes.

Share this post


Link to post
Share on other sites
Quote:
Original post by javapimp
That is correct. UDP does not split packets. When you send a packet, you will either receive the whole packet or nothing.

Yes too, the theoretical maximum size that a UDP packet is around 64k but it really depends on your local socket send/receive buffers, the destination and any routers along the way. It's probably best to keep messages less than 8192 (WinXP I think is this) unless you control the entire network you are communicating on. If the data you are sending is larger than this, you will have to do your own splitting and implement your own error recovery if you can't afford to miss a packet.


Hope that helps,
Dave.




I recall (maybe wrongly) that you might get duplicates ??

Share this post


Link to post
Share on other sites
UDP packets may be delievered zero, one or more times, in an arbitrary order compared to other packets. Examples include packets dropped because of congestion or lossy links, and packets re-ordered because of link-level reliability controls (e g some microwave links will checksum and re-transmit low-level packets, possibly out of order). Duplication is rare in my experience, but happens sometimes when there's multiple paths in network set-up (redundancy, or just a configuration problem), and also sometimes when back-haul routing changes from under you.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!