views:

128

answers:

5

I am getting confused between TCP being Connection oriented and UDP being connectionless so please somebody clarify this.

  • Every communication between two computers whether its TCP or UDP is via packets. There is no hard wire connection between two peers whether its TCP or UDP. Then why TCP is said to be connection oriented just because it retransmits the packets if no acknowledgement is received or it embeds sequence number inside the packets ?

  • Whats the actual meaning of connection ? Does the routers along the path between two communicating peers booked for some time to accept packets for that particular connection ?

EDIT

  • When do you say connection between two points established?

Thanks

+5  A: 

Yes, TCP embeds sequence numbers, and does a whole lot of other processing to "simulate" a dedicated point-to-point connection over a packet-oriented, connection-less network.

UDP does not; each datagram is delivered totally independently of any other datagrams.

unwind
+7  A: 

A connection is simply a virtual pathway between two endpoints. With TCP, you open up the connection and start sending data through. It's guaranteed to arrive at the other end in order (assuming the network doesn't fail). Then you close down the connection.

For the duration of the connection, the two ends talk to each other, acknowledging receipt of packets, to ensure there's no loss or duplication.

With UDP, it's slightly different. You basically just throw a packet out there with a destination address and it may or may not arrive - that's the U in UDP (unreliable).

You shouldn't be lulled into thinking the connection of TCP results in all packets taking the same physical path. They will be routed around problem areas if necessary.

As for your update, the connection is established after the following has happened:

  • a SYN packet has been sent from the initiator.
  • the responder has sent back a SYN-ACK packet.
  • the initiator has sent back another ACK packet.

This is the session establishment protocol for TCP. The packets themselves are normal packets with the SYN and/or ACK flags set in the header.

The seminal book on TCP (and other protocols) is Stevens, get yourself a copy of this if you want a dead-tree version - I've had this for ages. Or, of course, there's the Wikipedia stuff. Both of these are pretty heavy going for the casual enquirer, but well worth it if you're at all interested in going deeper - my own preference would be for the book, it ranks up there with Knuth on my bookshelf.

paxdiablo
+2  A: 

Routers have no knowledge of the connection. The connection is a TCP logical concept which adds the reliability of packet delivery that UDP lacks. However Routers are only interested in IP, the TCP, UDP whatever else are layers on top of IP. Routers route IP packets without any consideration to the high protocols that they contain.

AnthonyWJones
+4  A: 

I'll answer your second question first. The thing you wrote ("establishing a path") which happens in some network architectures (GSM voice calls, for instance) but not in the Internet is called circuit switching. With circuit switching, the network infrastructure itself is aware of a communication happening between the two endpoints. The TCP/IP stack, however, is designed to be packet switched. It means each packet is a separate piece of information that's delivered to the other endpoint and is unrelated to any other packet (like posting a message).

As a consequence, the lower level protocols in the IP stack do not guarantee that:

  • packets are received at the destination
  • packets are received in any particular order
  • packets are received at the destination just once

UDP in particular, does not try to solve these issues. On the other hand, TCP protocol has to get rid of these issues. It uses acknowledgements and packet sequence numbers to handle them. In TCP, a single packet is not unrelated to other packets. As a result, both parties should negotiate a simulated communication path built on the stateless IP. This negotiation is called a connection. It's basically establishing a relationship between the packets in a chain.

Mehrdad Afshari
+2  A: 

The two definitions from Wikipedia seem clear to me

In telecommunications, connectionless describes communication between two network end points in which a message can be sent from one end point to another without prior arrangement. The device at one end of the communication transmits data to the other, without first ensuring that the recipient is available and ready to receive the data. The device sending a message simply sends it addressed to the intended recipient.

...

A connection-oriented networking protocol is one that delivers a stream of data in the same order as it was sent, after first establishing a communication session.

I don't think I can improve on those definitions but let me attempt to explain it from socket programming perspective, understanding that socket is the programming interface for TCP/UDP. Specifically, if you program server sockets, say in Java, you would notice how this connection-oriented and connection-less nature of TCP and UDP respectively affects the programming model.

In a TCP-based client-server application, before any data communication is done, a connection between a client socket with a server socket, corresponding to that client socket, must be established. On the server, you would need to create a ServerSocket and then call accept() to get a Socket corresponding to a client's connection. One such socket is created to communicate with every connection from any particular remote client (which is initiated by instantiating the Socket class). You can refer to this code sample for the detail.

On the other hand, if you program UPD, your server socket is basically a DatagramSocket object which listens on a port and receives all datagrams sent to it as well as is able to send back datagrams to any particular client's socket. That is, one server socket serving all clients because there is no end-to-end connection between any client connection and the server. (Notice that there is also no "serverSocket#accept()" step necessary.) In other words, each client and server can just send datagrams around without having to care whether the other end-point is ready to receive the datagrams or not. You can refer to this code sample for the detail.

Buu Nguyen