5

If UDP does not establish a connection as TCP does.. it seems the only way it could track connections is source ip/port and destination ip/port. Is this correct?

So, I guess there are special packets for Connection Refused and Connection Reset. Is that correct?

Also, is it true that my data may not be received in the order it was sent?

2
  • Are you asking about this because you are curious how NAT handles UDP?
    – Zoredache
    Jan 5, 2011 at 17:21
  • Not exactly. I would like to know,, but that is not the question. I am trying to get a handle on parts of networking that I don't understand. Jan 5, 2011 at 17:27

4 Answers 4

10

Your first para is correct. There is no connection, though some IP engines use source address/port and destination address/port to provide a synchronicity-based approximation to state.

Refusal is handled with ICMP, often ICMP port-unreachable (type 3 subtype 3).

Your last para is also correct; it's up to your application to ensure that UDP-transmitted data is correctly sequenced.

2
  • What about connection closed/reset? Does that not exist either? Jan 5, 2011 at 15:16
  • 4
    You can't speak of connection, because as you've pointed out, there isn't one, so it can't go away. "No listener on the remote end" is signalled by ICMP port-unreachable, as I said. If you were sending a series of UDP packets to a remote server, and the listener vanished, I would expect you to get an ICMP port-unreachable back, but that wouldn't mean any kind of connection had been reset.
    – MadHatter
    Jan 5, 2011 at 15:25
1

There is no connection in UDP. It is not a reliable protocol. If transmission reliability is desired, it must be implemented in the user's application. Have a look at this page.

Yes, packets may arrive out of order and may be lost. The application should take care of these things if needed.

0

UDP is also known as the unreliable data protocol. There is no tracking as such in UDP. You could use src and dst IP/Port combo for tracking but not sure what you would achieve out of it.

The answer to your second question, that data may not be received in order it was sent it, is correct. TCP uses the sequence numbers. If a packet is received out of sequence it is discarded. The client sends a acknowledgement to sender of the sequenced packet received, upon which the sender starts sending data from that point onwards. This could also include retransmission of some packets. This is how TCP provides data guarantee.

3
  • 2
    When I run nslookup it connects to a DNS server using UDP port 53. Somehow the OS has to know the response comes back to the correct instance of the nslookup program and not some other program. How does it do that? Jan 5, 2011 at 15:24
  • 1
    port pairs. local nslookup uses port x to send request, server answers to port x. as port x is in use only by one app / "connection" at a time, packets can be send to correct instance.
    – TomTom
    Jan 5, 2011 at 15:37
  • 1
    @TomTom I get it... there is no connection.. it is just that nslookup knows when it is done listening for data and then exits while the server just sends off data to the same port nslookup was using and hopefully nslookup will still be listening.. and if not then the server will never know. Jan 5, 2011 at 17:31
0

UDP is a datagram-oriented service. Each UDP packet should have (ideally!) its full context in the packet, as packets can be lost or re-ordered in transit.

TCP, on the other hand, is a stream-oriented protocol, providing a bi-directional stream between two end-points (this implies reliability and sequencing, whereas a datagram service doesn't, necessarily).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .