There are two main connection protocols: TCP and UDP, and the latter is a “connectionless” protocol, so how is data transferred if there is no established connection between sender and recipient?
In: 1
It isn’t connectionless in that there isn’t a connection between A and B. It’s connectionless in that the two endpoints don’t handshake with each other before data comes in.
If you have a UDP protocol, you just send UDP packets to the recipient and hope they get them. Essentially, all the logic of ensuring the data got to the other end is left up to the application level rather than part of the network protocol.
It’s not that kind of connection – there is still a data path between the sender and receiver. It’s just that from the point of view of the sender, udp is like shouting into the dark – there is no acknowledgement or reply. By “connection”, they mean “no back and forth conversation”.
What we mean by an “established connection” for TCP, is that we implement measures to ensure that the other side is receiving the data. This typically involves waiting for replies and using numbers to keep track of the order data should be sent and received.
UDP simply dispenses with this overhead. It simply sends the data to the destination. In the event that we’re actually waiting for a response and don’t get one, we just send the request again.
To be clear, there is a logical path between sender and receiver in both, the “established connection” for things like TCP are just the steps we’re taking to provide assurance that data is being sent and received over that path.
The application have to manage the connection by itself rather than letting the operating system do it in a driver. This is when it thinks it can outperform TCP with something similar.
The nature of data transfer that fits UDP often doesn’t need reliable delivery, because the new data will override and correct the item that was received before. This could be the a measurement of a sensor, or the position of a player’s avatar in a virtual world. Or a transmission of a live sound signal intended for listening not to make a copy. The sender keeps transmitting without waiting for an answer.
It’s a misnomer as many people have explained here so I won’t repeat.
Some fields like to give stupid names and define stupid things. It’s like they are gatekeeping new people interested in that field
My understanding is that UDP is a way of taking packets of data and attaching an address so that there isn’t a connection made, but it gets to where it’s going.
Sort of like mailing a letter versus calling someone on the phone (connection).
The TCP protocol is basically “hey? Did you get my packet? Yes? Okay, next one. No? Okay, I’ll send that one again.” It’s a constant back-and-forth that makes sure every packet was sent and received.
UDP is a little different. You’re shooting the packets at the recipient without confirming that each individual packet was received.
UDP isn’t really connection-less, it just doesn’t verify the connection.
TCP protocol has a handshake that establishes a connection, something like:
– Hey Remote System, Sender here, I have some data for you
– Remote System here, ready and waiting for your data
– Ok, here’s your data
– Thank you Sender, I got got your data
In UDP, Sender just sprays data at Remote System, and whatever happens to it happens to it, not Sender’s problem
To answer this question, you need to know what a “connection” really is. All a connection is is an agreement between two computers that if any packets get dropped or corrupted while they’re traveling across the internet, the sender resends the packets. This is done by a handshaking algorithm. In UDP, there is no agreement. If a packet gets lost, the sender doesn’t have to resend the packet.
Latest Answers