Talk:User Datagram Protocol/Archive 1

Archive 1

IpV6

What about UDP and ipv6?

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

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)

Reliable IP multicast also uses UDP. Far as I know, all IP multicast uses UDP, though I've never quite figured out why that should be used exclusively. Non-IP multicasts (such as Infiniband's multicast) also use unreliable transport protocols comparable to UDP, to the best of my knowledge. However, leaving it open seems more "correct", as UDP does not appear to be a fundamental requirement as much as it appears to be convention. --Jcday (talk) 18:32, 19 August 2008 (UTC)

It has to do with sockets and ACK packets required in TCP. You can only have about 2000 sockets open for TCP. So a broadcast would be limited to 2000 clients at a time. — Preceding unsigned comment added by 192.127.94.7 (talk) 17:58, 7 March 2012 (UTC)

Sample code

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

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)

I believe that "sizeof(buffer)" should be replaced by "sizeof(buffer) - 1" in the C++ server code, to ensure that buffer remains a zero terminated string. The client code has an even more serious problem: "sizeof(buffer) + 1" is obviously wrong, as buffer only contains sizeof(buffer) number of characters (6, to be exact). 84.0.183.211 (talk) 13:24, 12 January 2009 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Indefinite article

See Wikipedia:Administrators' noticeboard/Incidents#User: 109.77.xx.xx and the indefinite article and Talk:XMPP#Please discuss changes to the indefinite article. Andrewa (talk) 15:07, 24 May 2013 (UTC)

confusion

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

"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

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.

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.

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

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)

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)

Initiating Reception?

I don't understand something about starting up communication with UDP. Say I connect to a port on another computer that only outputs packets. How does that computer know my UDP port number if I have not sent it any packets? If it does not know my UDP port, then it has no way to output packets to me. How is communication initiated? 208.252.219.2 (talk) 14:40, 28 July 2009 (UTC)

It can't just send, it has to receive a request first. There is no such thing as 'initiating reception' as an isolated function, data transfer is initiated by the sender or by the requesting client. perhaps Berkeley sockets article helps, else any TCP/IP programming book should help. Kbrose (talk) 16:20, 28 July 2009 (UTC)

By 1's complement, do you mean to do a bit for bit exclusive nor or exclusive or? ... or do you mean to do a 2's complement add with 0 for a carry? —Preceding unsigned comment added by 71.237.227.76 (talk) 23:59, 12 January 2010 (UTC)

Confusion after "Russell Tebay" vandalism

Hey, everyone, I got confused by the insert-revert-revert-revert stuff that was going on after a vandal inserted the "Russell Tebay invented UDP" phrase. I accidentally reverted Kgfleischmann‎‎'s attempt to clean up the problem. Fortunately, someone came along behind me and reverted my revert of the reverts, leaving the article clean. Sorry 'bout that, y'all! — UncleBubba ^{( T @ C )} 18:54, 2 October 2010 (UTC)

13th most visited article?

I noticed that this article, according to [1], is the 13th most visited Wikipedia article, ahead of Justin Bieber, Julian Assange, and Deaths in 2010. Any idea why this may be? Seems very strange. InverseHypercube 18:49, 2 August 2011 (UTC)

I'm equally confused and curious Jebus989^✰ 21:59, 12 September 2011 (UTC)

I don't think it's real, I have a suspicion that there's some software/malware somewhere that interrogates this page to check whether it's online or something. If you look at the statistics, there's a peak every 2-4 or so days- I think that's indicative of this kind of thing- real users would read the page every day with variations for weekends and such like.Teapeat (talk) 22:41, 12 September 2011 (UTC)

Orphaned references in User Datagram Protocol

I check pages listed in Category:Pages with incorrect ref formatting to try to fix reference errors. One of the things I do is look for content for orphaned references in wikilinked articles. I have found content for some of User Datagram Protocol's orphans, the problem is that I found more than one version. I can't determine which (if any) is correct for this article, so I am asking for a sentient editor to look it over and copy the correct ref content into this article.

Reference named "rfc2675":

• From Jumbogram: Borman, D.; Deering, S.; Hinden, R. (August 1999). IPv6 Jumbograms. IETF. RFC 2675.
• From IPv6: RFC 2675, IPv6 Jumbograms, D. Borman, S. Deering, R. Hinden (August 1999)

I apologize if any of the above are effectively identical; I am just a simple computer program, so I can't determine whether minor differences are significant or not. AnomieBOT⚡ 13:01, 11 February 2012 (UTC)

 Done --Kvng (talk) 19:16, 14 February 2012 (UTC)

Erasure Codes for Reliability

In the reliability section there is this sentence: "If an application requires a high degree of reliability, a protocol such as the Transmission Control Protocol or erasure codes may be used instead." If I'm reading that section correctly I think they are referring to missing packets, not packets with corrupted data. Erasure codes seem to handle corrupted data and not missing packets. I think that sentence should read "If an application requires a high degree of reliability a protocol such as the Transmission Control Protocol may be used instead." Jonberling (talk) 16:43, 8 June 2012 (UTC)

No, erasure codes can handle an erasure of a full packet. — Preceding unsigned comment added by 207.239.83.38 (talk) 00:28, 14 July 2012 (UTC)

 Done --Kvng (talk) 13:28, 10 June 2012 (UTC)

What happens

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.

• Note that you may need to explicitly enable fragmentation on the transmitting end. Recent versions of Linux will instead by default return EMSGSIZE when a UDP packet write exceeds the MTU of the interface. (See the UDP(7) manpage for details). Cjs (talk) 05:38, 24 August 2012 (UTC)

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)

Why not just put the proper headers in there? It could even have fields labelled "Other Info", just so that at least the addresses don't appear at the beginning. —Preceding unsigned comment added by 163.181.251.9 (talk) 22:56, 26 June 2008 (UTC)

You may not know, at that particular layer, what the "proper" or "real" headers are, since there are other fields (such as the fragment identifier) that are typically generated by other layers, and also various optional fields that may or may not be added after the UDP layer is constructed. Cjs (talk) 05:42, 24 August 2012 (UTC)

Incorrect Maximum Size Calculation?

I think that the calculation of maximum size is wrong; they give the maximum amount of data in a UDP datagram that can fit in a single IPv4 packet/fragment. (Their limit is the 65535 byte maximum length of an IPv4 packet/fragment determined by the 16-bit length field in the IPv4 header.) However, an IPv4 datagram may consist of multiple packets, and the maximum length of the data in a datagram is the fragment offset (max (2^13-1)*8) plus the length of a fragment (65535 bytes) minus the lengths of the various headers; this total is well over the maximum 65535-8 bytes of data at the UDP layer. Cjs (talk) 05:47, 24 August 2012 (UTC)

Some experimentation appears to show that, with fragmentation enabled, Linux 3.2 will accept a UDP payload of 65535-8-20 bytes (maximum UDP length field minus eight bytes for UDP header and 20 bytes for a minimum IP header), but not 65535-8 bytes (the theoretical maximum calculated above). My guess is that the inability to do a theoretical full-size UDP datagram because it's larger than will fit into a full-size IP packet/fragment is a bug, and I wouldn't be surprised if it's a common one. Cjs (talk) 07:00, 27 August 2012 (UTC)

Joke

Does this actually make sense as a joke? "You know what the best part about a UDP joke is? I don't care if you get it or not." Mercurywoodrose (talk) 02:11, 24 October 2012 (UTC)

Yeah. Good one, actually. -—Kvng 14:39, 31 October 2012 (UTC)

IPv4 Pseudo Header

Why these IP pseudo-headers for checksum calculation are in such a prominent place in the article!? Normally one doesn't care about checksum calculations, but needs to lookup actual IP/UDP packet structure. This is just plain misleading to include these and NOT include real packet structure. Dc987 (talk) 20:18, 19 November 2013 (UTC)

The real packet structure is higher up in the Packet structure section. You may have missed it because there's not much to it. I have removed an unnecessary heading in the Checksum computation section. I don't think this material should be removed but it would be fine if it were made less prominent. WP:BOLD suggestions welcomed. ~KvnG 15:29, 22 November 2013 (UTC)

Endian

There's no mention of endian ordering of the UDP header packets. Yes, it's *assumed* that it's in "network order" (big endian), but if a newbie encounters this, it may not be immediately apparent. I'd recommend something like "bytes are in network order" with an xref to network order, maybe parenthetically "(big endian)" as well... 173.195.59.162 (talk) 15:27, 6 November 2014 (UTC)

UDP inherits its endianness from Internet Protocol but I don't see any discussion of endianness there either. ~KvnG 15:35, 9 November 2014 (UTC)

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.)"

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).

65535 is the index of the last element in the array, but not the length. The length should be 65536. If I need to create a buffer to hold the maximum amount of data that can be delivered in a UDP packet, it seems I should allocate either 65536 for the whole packet, or 65528 to hold only the data field.- Lbailey726 (talk) 19:12, 8 January 2017 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on User Datagram Protocol. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://archive.is/20070731124008/http://www.networkperformancedaily.com/2007/08/whiteboard_series_nice_guys_fi.html to http://www.networkperformancedaily.com/2007/08/whiteboard_series_nice_guys_fi.html

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 20:07, 26 July 2017 (UTC)