Talk:User Datagram Protocol

From Wikipedia, the free encyclopedia

What happens if a send of an UDP datagram is requested while the length is larger than the current MTU? Is the packet dropped, truncated, or split? Is it reassembled at the receiver end?

Answer: The network layer protocol (IP) will fragment the datagram and send it in separate pieces that fit within the MTU. Normally the receiving station will reassemble the fragments.

Contents 1 confusion 2 Concurrence 3 Re: confusion/concurrence 4 IpV6 5 Tunneling 6 Sample code 7 Usefullness 8 IPV6 UDP 9 ipv4 - ipv6 headers 10 Length 11 Compared to TCP

[edit] confusion

"In the TCP/IP model, UDP provides a very simple interface between a network layer below and an application layer above." yo Now wait aminute: is UDP part of TCP/IP? If so, it could stand more explanation. If not, perhaps the above should be re-worded. My guess is that you wanted to say something like: 'UDP and TCP are both transport protocols, either of which could be run over IP'. hjj

TCP/IP has two different meanings, it can either mean TCP over IP or it can mean the TCP/IP protocol suite including IP TCP UDP ICMP etc. Plugwash 20:08, 22 September 2005 (UTC)

I can fix to say TCP/IP suite if that suites your fancy, but technically it is correct (though I originally wrote it so I'm biased :-). [[User:jtk|jtk] Tue Jul 18 04:xx GMT 2006

From the article: "UDP adds only application multiplexing and transactive, header and data checksumming also found in a TCP header on top of an IP datagram" This seems to be broken. What's that comma doing there? There are surely some words missing from this sentence too. If I understood what it was trying to say I'd attempt to edit it.

That is broken, I'll fix. What the heck is transactive? :-) jtk Tue Jul 18 04:xx GMT 2006

[edit] Concurrence

I too agree with the confusion over the first sentence. It should be ammended. UDP is NOT part of TCP..It is a separate entity. In fact, this article makes no reference to "connectionless". It is the distinct difference and counter point to the "connection" oriented TCP.

[edit] Re: confusion/concurrence

Added a link to Internet protocol suite, that explains why UDP does belong to the TCP/IP model. For short, the TCP/IP model is a layer model. Many protocols fit into the layers. One of them is UDP; another is ICMP.

[edit] IpV6

What about UDP and ipv6?

Both are part of TCP/IP. --200.208.45.2 22:31, 22 Apr 2005 (UTC)

[edit] Tunneling

Is it possible to tunnel UDP in TCP? My internet provider has shut down all UDP traffic and has no intention on opening them.

Get another provider would be the better alternative. How can they not support UDP? What about DNS? But, you can tunnel anything in just about any way. Might be better and easier to just set a tunnel for everything though. jtk Tue Jul 18 04:xx GMT 2006

My ISP doesn't allow UDP either, and getting another is not an option. Is there anything I can do besides live without copious programs I want to use that require it? Dazuro

Not really. You either need to find a way to tunnel, complain or find an alternative means of access. I suggest at least complaining. It might not do any good, at least not initially but if no one complains then don't be surprised if they further restrict access in the future. Here's what I recommend. Send them a polite email and ask them to categorize themselves according to RFC 4084. State that you are only being offered and are paying for something akin to web access and you would like "full internet connectivity" per the RFC (or whatever other service as described by that memo you want). [ jtk - Fri Sep 1 15:48:52 GMT 2006 ]

It certainly is possible but you will need a machine that *does* have UDP access to the internet to be the other end of your tunnel. Therefore whether a soloution will be feasible depends on your ability to obtain such a machine with the bandwidth availible to do what you desire (either by getting a favor from someone or by paying for it). Also you may find you need *nix machines at the ends of the tunnel as windows doesn't tend to be very flexible in this regard. Plugwash 23:55, 24 October 2006 (UTC)

[edit] Sample code

Does is really belong to the article? I think that it should be removed. For readers without technical background it adds nothing but confusion. And for the rest, I don't think WP is the place to look for sample code. --Teemuk 07:28, 27 July 2006 (UTC)

I agree. It makes the page a lot longer than it needs to be and doesn't add to the article. I'd prefer a shorter article that has understandable content. 155.31.230.36 21:02, 26 September 2006 (UTC)

I disagree! The minimalistic approach greatly simplifies the task of understanding UDP in a programming context, which is vital to many people learning protocol behavior. If a user doesn't understand that section, they don't have to read it. But how many people attempting to understand UDP will not have a basic concept of what a programming language is? And besides, I've seen much longer Wikipedia articles than this one. You have too, I'm sure. --M. W. Holt (talk) 20:46, 1 May 2008 (UTC)

I also disagree. It makes this information complete and useful by giving a context on how UDP is used. Those that find this information useful will outnumber those that don't, just by the nature of the fact that those who seek information on UDP will be technically minded in the first place. Your statement could be made about many math articles containing theorems too, but yet because someone may find it incomprehensible does not mean it should be cut out. Nodekeeper 14:05, 5 October 2006 (UTC)

First, I'm not convinced that the number of people who find the sample code useful will outnumber those that don't (any evidence of this?). Second, it's not strictly a question of usefulness; it's a question of whether this information is encyclopedic. Articles about other protocols do not include sample code. Third, the sample code does not make the information complete, for completeness we would have to show how to use UDP in all the different environments, not just with Berkeley sockets.

For these reasons, I propose the sample code be removed and perhaps replaced by a link to the Berkeley sockets article which includes similar sample code.--Teemuk 09:22, 6 October 2006 (UTC)

Someones just gone and added some ruby source, having code in the standard system language that uses the standard systems socket api (even windows uses something pretty close to berkley sockets) is one thing but this could very rapidly turn into a flood Plugwash 08:41, 30 October 2006 (UTC)

I'd just like to comment that I found this sample source code very nice, I am rather amazed that this client server code can be written in so few lines of code. It gives a good practical example of using UDP which I think may be useful to people wanting to learn about UDP. I think it would be a shame to remove it. SpaceDude 22:35, 2 October 2007 (UTC)

[edit] Usefullness

Could someone add a section explaining how UDP is actually useful (which it obviously must be), or at least explain to me? I don't see how you could use it as you cannot guarentee packages will be received.

You don't always need every packet, especially in time-senstive applications. Take the telephone for example: if you miss a few milliseconds of sound you won't notice, but you would notice if it took an extra half-second to get the sound to you. That's one type of application where it is useful. The other is in things like DNS, where the cost of setting up a TCP connection would be two-three times the cost of just asking for the data again if it gets lost. DStaal 19:35, 24 October 2006 (UTC)

The internet in general doesn't gaurantee that all packets will arive or that packets will arive in order or that no duplicates will arive. TCP gets arround this by giving every packet a sequence number, acknowlaging what data has been received, resending packets that are never acknolaged and buffering up data at the receiver until it can be delivered to the application in order. This makes life simple for application programmers but this simplicity comes at a price (for more detail of what this price is read the TCP article).

UDP puts the responsibility for dealing with lost packets (and if required tracking sessions) onto the application and hence allows a method to be chosen that fits the applications needs. For example a DNS server has no reason to wan't to track client sessions but using TCP would force it to so instead a much simpler system is used (if a client doesn't get a reply to its request within a set time then it sends it again). The internet telephony app will try and do without lost voice data rather than waiting for a resend. Plugwash 00:14, 25 October 2006 (UTC)

"The internet telephony app will try and do without lost voice data rather than waiting for a resend." "try and do"? If you "do", "try" is understood and redundant. Change "try and do" to one of these two: "try to" or "and do". If "try" is needed for the sentence, we would have to put "try" in front of most verbs. We would start sounding like the pidgin english of Hawaii, as in "try stay go". (Yes I put the period outside the quotation marks deliberately. No matter the rule, the period is not part of the quoted material.) —Preceding unsigned comment added by 207.5.245.62 (talk) 13:34, 29 March 2008 (UTC)

As a native English speaker, I'd say "try and do without" is idiomatically reasonable, although I'll accept that "try to do without" is probably more correct grammatically. (Incidentally, while you're criticising grammar, please note that English is capitalised.) DrVxD (talk) 19:47, 9 June 2008 (UTC)

[edit] IPV6 UDP

the udp protocol as defined in this article and in rfc768 is only suitable for use over protocols that use 32 bit host addresses. Does anyone know what RFC defines the IPV6 variant of UDP? Plugwash 00:18, 25 October 2006 (UTC)

Yes - RFC 768 plus section 8, "Upper-Layer Protocol Issues", of RFC 2460. The only change from RFC 2460 is the change to the way the pseudo-header is defined when UDP runs over IPv6. Guy Harris 01:23, 28 October 2006 (UTC)

[edit] ipv4 - ipv6 headers

The ipv4 and ipv6 headers in the tables are wrong. However, that seems to be wanted (they are called "pseudo-headers"). Why? Doesn't it just add confusion? invernizzi.l 4:08am, 9 feb 2007 (UTC)

They're not IPv4 and IPv6 headers, and they aren't wrong. They are, to use the language of (as per the previous section, "IPV6 UDP"), "pseudo-headers", which are prepended to the UDP header and data to compute the checksum to be put into the UDP header. Perhaps calling them "pseudo-headers" adds confusion for some, but, for better or worse, that's what they're called in the RFC's that specify them - RFC 768 and RFC 2460 (section 8). As the UDP page says, they "mimic" the IPv4 and IPv6 headers; they aren't identical to the IPv4 and IPv6 headers. Guy Harris 10:29, 9 February 2007 (UTC)

[edit] Length

The length doesn't make sense to me. 65537 leaves room for an 8 byte header, but this header should be included in the length according to rfc768:

"Length is the length in octets of this user datagram including this header and the data. (This means the minimum value of the length is eight.)"

http://www.faqs.org/rfcs/rfc768.html

65527 is the theoretical max for the size of the data field, but that would lead to a length of 65535 (0xffff). -Nathan Friedly —The preceding unsigned comment was added by 69.223.75.253 (talk) 20:56, 23 April 2007 (UTC).

Where is 65537 mentioned? Or did you mean 65527? The article does say that the header is included in the length; it also says that 65527 is "a theoretical limit ... for the data carried by a single UDP datagram" (emphasis mine). I.e., the article doesn't say that 65527 is the maximum value of the length field, it says that it's the maximum size of the data field. Guy Harris 03:56, 24 April 2007 (UTC)

Yea, I meant 65527.. and I get it now. It just didn't make sense the first few times I read it, probably because I was looking for the max value which isn't directly mentioned and I mistook that for being it. Thanks. -Nathan Friedly —The preceding unsigned comment was added by 68.79.180.24 (talk) 05:24, 24 April 2007 (UTC).

[edit] Compared to TCP

"Compared to TCP, UDP is required for broadcast (send to all on local network) and multicast (send to all subscribers)." Would "Unlike TCP, UDP..." be more correct? Also, is UDP required? Couldn't you use something else? I don't see how this sentence applies to TCP. --Daev 23:50, 3 May 2007 (UTC)

How about "Unlike TCP, UDP can be used for broadcast ... and multicast ...." I'd have to look, but there might be some other transport protocols (less well-known) that can be used for broadcast or multicast; however, I think the best way to phrase it is that it can be used for broadcast and multicast, unlike TCP, which can only be used for unicast. Guy Harris 02:51, 4 May 2007 (UTC)