Talk:User Datagram Protocol
This is the talk page for discussing improvements to the User Datagram Protocol article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
Archives: 1Auto-archiving period: 365 days ![]() |
![]() | This article is rated C-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||||
|
Usefullness
[edit]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)
UTP is not garunteed when sending a message, but thats where TCP comes in. TCP resends the part of the message that doesn't get received. If no part of the message is received then TCP resends the entire message again
- User_Datagram_Protocol#Reliability_and_congestion_control discusses this. ~Kvng (talk) 21:37, 5 August 2021 (UTC)
I may just be being picky...
[edit]But I corrected several things like *space**period* and "dotdot" at the end of sentences. —Preceding unsigned comment added by 216.212.238.139 (talk) 00:51, 3 July 2008 (UTC) TTTT
Should the discussion here about the comparison between TCP and UDP use the term segments instead of packets? Mitchb2 (talk) 13:19, 4 September 2009 (UTC)mitchb2
- Message is used now and this seems reasonable. Packet is still used for exchange required for setup. This is correct, there are no segments until the connection is established. ~Kvng (talk) 21:37, 5 August 2021 (UTC)
Alternate names
[edit]It is clear from the RFC that User Datagram Protocol is what UDP refers to. The article mentions alternative mappings: Universal Datagram Protocol and Unreliable Datagram Protocol. Are these incorrect alternative names worth noting (and perpetuating)? --Kvng (talk) 14:29, 14 July 2010 (UTC)
- Unreliable Datagram Protocol mentioned in User_Datagram_Protocol#Attributes. Universal Datagram Protocol no longer found in article. ~Kvng (talk) 21:37, 5 August 2021 (UTC)
Beginnings/creation
[edit]Not sure what to do about this, but wikipedians might have some suggestions. UDP (like TCP) was in active development prior to the RFC that documented it was issued. So the 1980 date for its creation may confuse people who know the history of the Internet protocol development. In particular, the decision to split the original TCP design into three protocols was taken in 1977, three years before RFC768 froze its design. What was a purely virtual circuit model prior to that point was split into the IP layer (now IPv4) which carried host-to-host datagrams between gateways (now called routers) and two higher level protocols, UDP and TCP. This was the result of strong advocacy for support of a class of uses that could not accept the constraints imposed by reliable, exactly once, in-order delivery.
Not sure the best citation for this, but many Internet histories discuss this event. The packet formats and behavior of the three different protocols were implemented and in use soon after that at a number of sites, well before 1980. AdScientiam (talk) 19:21, 4 December 2017 (UTC)
Use of ARP
[edit]It says in the first paragraph of the lead "Prior communications are not required in order to set up communication channels or data paths." However would it not be necessary to use something like ARP to obtain a MAC address for the IP address used by UDP? Graham.Fountain | Talk 12:22, 5 August 2021 (UTC)
- That's too pedantic to deserve discussion in the lead but could be added to the body. Maybe in User_Datagram_Protocol#Attributes. ~Kvng (talk) 21:37, 5 August 2021 (UTC)
- No. A computer on one network can send UDP packets to a computer on another network without any prior communication. The sender forwards UDP to the nearest router which forwards it so it eventually arrives at a router on the destination network which delivers it to the destination. ARP might be needed if the computer had not recently been communicating with its router, but that does not involve end-to-end communication. Johnuniq (talk) 23:23, 5 August 2021 (UTC)
- However, if the destination is in the same subnet as the source, there are no routers involved and the source will need to have an ARP exchange directly with the destination before sending a UDP/IP packet. ~Kvng (talk) 16:32, 12 August 2021 (UTC)
- Now we're into semantics regarding what "Prior communications are not required" means. It's certainly true that UDP never requires prior communications. and it's true that the common example I mentioned involves no prior communication. The underlying packet delivery service may or may not exchange packets first. Johnuniq (talk) 00:42, 13 August 2021 (UTC)
- However, if the destination is in the same subnet as the source, there are no routers involved and the source will need to have an ARP exchange directly with the destination before sending a UDP/IP packet. ~Kvng (talk) 16:32, 12 August 2021 (UTC)
Start a discussion about improving the User Datagram Protocol page
Talk pages are where people discuss how to make content on Wikipedia the best that it can be. You can use this page to start a discussion with others about how to improve the "User Datagram Protocol" page.
- C-Class Computing articles
- Mid-importance Computing articles
- C-Class Computer networking articles
- High-importance Computer networking articles
- C-Class Computer networking articles of High-importance
- All Computer networking articles
- All Computing articles
- C-Class Internet articles
- Top-importance Internet articles
- WikiProject Internet articles