connection oriented vs connectionless

[rookie1010]

Hello,

I was going through the differences between UDP vs TCP and it states that with TCP and i have come across a couple of reasons why TCP is connection oriented and UDP is connection less. Are they all correct?

1. TCP involves handshaking at the begining of the transaction to negotiate paramaters (in this case, does the TCP peer send a BYE packet to signal the end of the transaction)
2. No state information is maintained and each datagram is handled independently of each other.


I understand connection being the handshaking between the two peers and negotiation of parameters. i guess at the end of the transaction they sign of by sending a packet such as BYE.

 

[jlazzaro]

1. TCP establishes a connection using a three-way handshake. Passive open occours when a server binds a port to open for future connections. Active open is performed via the client by sending a SYN, server replies with a SYN-ACK, client replies with an ACK which completes the acknowledgment.

Connection teardown involves a FIN, FIN-ACK, and RST.

2. UDP maintains no state information with no guarantees as and each datagram is handled independently of each other.

Wiki TCP
Wiki UDP

 

[rookie1010]

thanks for the reply,

i was looking at the TCP wiki, and it says

"
To establish a connection, TCP uses a three-way handshake. Before a client attempts to connect with a server, the server must first bind to a port to open it up for connections: this is called a passive open. Once the passive open is established, a client may initiate an active open. To establish a connection, the three-way (or 3-step) handshake occurs:

1. The active open is performed by the client sending a SYN to the server.
2. In response, the server replies with a SYN-ACK.
3. Finally the client sends an ACK back to the server.

At this point, both the client and server have received an acknowledgment of the connection.
"

when doing a passive open, is a connection estalished or is the passive open just a part of the establishment of the connection.

even with UDP, ports are bound to applications, correct and hence would passive open not be a feature of UDP?

could one not have a state-machine without setting up the connection

i guess the connection-oriented nature enables flow control and error control mechanisms and hence results in TCP being reliable.

With UDP, i guess since it is connection-less,

one can have a scenario of two seperate applications in client 1, sending packets to a single application on client 2 at the same time.

one can have application A on client 1 send packets to application Z on client 2,
followed in the next second by application B on client 1 sending packets to application Z on client 2, followed by application A on client 1 sending packets to application Z on client 2 again.

 

[mcmilljb]

I am confused. What are you wanting to know?

 

[spidey07]

Easy way to put it...

TCP handles retransmission and data flow with acknowledgment
UDP does not - the application layer has to handle this

by definition the difference between connection and connectionless.

 

[rookie1010]

thanks for the reply guys

with UDP, can one have the following scenario?

Two separate applications in client 1, sending packets to a single application on client 2 at the same time.

An application A on client 1 sending packets to application Z on client 2,
followed in the next second by application B on client 1 sending packets to application Z on client 2, followed by application A on client 1 sending packets to application Z on client 2 again.

 

[RebateMonger]

Originally posted by: rookie1010
An application A on client 1 sending packets to application Z on client 2,
followed in the next second by application B on client 1 sending packets to application Z on client 2, followed by application A on client 1 sending packets to application Z on client 2 again.

The applications can do whatever they wish. With UDP, THE APPLICATIONS will be responsible for determining whether data is being correctly received on both ends. To minimize overhead, they can just assume that data is getting through and not bother checking at all, if that's acceptable.

 

[mcmilljb]

Originally posted by: rookie1010
thanks for the reply guys

with UDP, can one have the following scenario?

Two separate applications in client 1, sending packets to a single application on client 2 at the same time.

An application A on client 1 sending packets to application Z on client 2,
followed in the next second by application B on client 1 sending packets to application Z on client 2, followed by application A on client 1 sending packets to application Z on client 2 again.

Yes that can happen. The reason that can happen is each application will bind with a port. Then the 2 open ports (1 for App A and 1 for App B) represent the applications to the destination App on client 2.

 

[rookie1010]

thanks for the replies,

so multiple applications can send packets to the same destination App.

does this mean that security wise UDP is more vulnerable?

 

[Nothinman]

does this mean that security wise UDP is more vulnerable?

A bit. With UDP the app receives a packet and has to determine where it came from and if it's supposed to use whatever data's in it or not. But with TCP the system checks the source, sequence number, etc to make sure that it's part of the correct stream.

 

[jlazzaro]

Originally posted by: Nothinman

does this mean that security wise UDP is more vulnerable?

A bit. With UDP the app receives a packet and has to determine where it came from and if it's supposed to use whatever data's in it or not. But with TCP the system checks the source, sequence number, etc to make sure that it's part of the correct stream.

on that same note, firewalls keep connection state tables for TCP sessions that can be closed immediately when a session is reset. since UDP has no reset mechanism, the session remains open until a timeout period has expired.

 

[mcmilljb]

Originally posted by: Nothinman

does this mean that security wise UDP is more vulnerable?

A bit. With UDP the app receives a packet and has to determine where it came from and if it's supposed to use whatever data's in it or not. But with TCP the system checks the source, sequence number, etc to make sure that it's part of the correct stream.

You're not thinking about it correctly. When the client receives the UDP packet. It knows where it came from because of the source IP address and port. Then the dest. port tells the client which app to pass the rest of the data up to the app. That's when the app is able to decide what to do with the packet. When you're using TCP/IP (even with UDP), it knows where the packet came from (source IP address and port give this information). TCP just spends time waiting on packets and arranging them into the correct order BEFORE passing up to the application.

 

[Nothinman]

Yea, I know how it works but the app still has to do it's own checking because that UDP packet could've come from anywhere since the kernel doesn't have a session with which to associate it.

 

[spidey07]

Originally posted by: mcmilljb

Originally posted by: Nothinman

does this mean that security wise UDP is more vulnerable?

A bit. With UDP the app receives a packet and has to determine where it came from and if it's supposed to use whatever data's in it or not. But with TCP the system checks the source, sequence number, etc to make sure that it's part of the correct stream.

You're not thinking about it correctly. When the client receives the UDP packet. It knows where it came from because of the source IP address and port. Then the dest. port tells the client which app to pass the rest of the data up to the app. That's when the app is able to decide what to do with the packet. When you're using TCP/IP (even with UDP), it knows where the packet came from (source IP address and port give this information). TCP just spends time waiting on packets and arranging them into the correct order BEFORE passing up to the application.

If you look at the packet structure of layer4 with UDP and TCP and their operation you'll see what nothingman is talking about.

Not that either is secure, UDP is inherently more insecure than TCP because of TCP's state machine. Neither are secure.

 

[mcmilljb]

Originally posted by: Nothinman
Yea, I know how it works but the app still has to do it's own checking because that UDP packet could've come from anywhere since the kernel doesn't have a session with which to associate it.

What checking though? The app knows where the packet came from the information stripped off the packet while it's at the TCP/IP layer. Think about about a basic DNS query. It does not care who sent the request until it is ready to send the reply. Maybe illustrate what you mean by checking.

 

[spidey07]

Originally posted by: mcmilljb

Originally posted by: Nothinman
Yea, I know how it works but the app still has to do it's own checking because that UDP packet could've come from anywhere since the kernel doesn't have a session with which to associate it.

What checking though? The app knows where the packet came from the information stripped off the packet while it's at the TCP/IP layer. Think about about a basic DNS query. It does not care who sent the request until it is ready to send the reply. Maybe illustrate what you mean by checking.

Look into the tcp/ip stack for more understanding. The entire stack (and it's associated protocols including UDP at layer4) covers the calls from the app level.

This can lead to more understanding of connection oriented vs. connectionless. A true socket is formed with TCP, not so with UDP where the app must handle the socket.

 

[mcmilljb]

Originally posted by: spidey07

Originally posted by: mcmilljb

Originally posted by: Nothinman
Yea, I know how it works but the app still has to do it's own checking because that UDP packet could've come from anywhere since the kernel doesn't have a session with which to associate it.

What checking though? The app knows where the packet came from the information stripped off the packet while it's at the TCP/IP layer. Think about about a basic DNS query. It does not care who sent the request until it is ready to send the reply. Maybe illustrate what you mean by checking.

Look into the tcp/ip stack for more understanding. The entire stack (and it's associated protocols including UDP at layer4) covers the calls from the app level.

This can lead to more understanding of connection oriented vs. connectionless. A true socket is formed with TCP, not so with UDP where the app must handle the socket.

Understanding of what? If you can't say what "checking" you're talking about then you have no idea what you're talking about. The only "checking" will be done if the app implements any features that would be normally done in TCP such as a connection like a state machine. There is no checking of where the UDP packet came from unless the app is programmed to do so. UDP and TCP are independent of IP, they only depend on the port identifiers, which represent traditionally processes on a source and destination. Just saying what you mean by checking or don't say there is checking.

 

[Nothinman]

The only "checking" will be done if the app implements any features that would be normally done in TCP such as a connection like a state machine.

Which pretty much has to be done if the app hopes to process packets from more than one host at a time.

There is no checking of where the UDP packet came from unless the app is programmed to do so.

Which is the point, the app has to do it since the kernel won't be doing it on it's behalf.

 

[spidey07]

Originally posted by: mcmilljb

Originally posted by: spidey07

Originally posted by: mcmilljb

Originally posted by: Nothinman
Yea, I know how it works but the app still has to do it's own checking because that UDP packet could've come from anywhere since the kernel doesn't have a session with which to associate it.

What checking though? The app knows where the packet came from the information stripped off the packet while it's at the TCP/IP layer. Think about about a basic DNS query. It does not care who sent the request until it is ready to send the reply. Maybe illustrate what you mean by checking.

Look into the tcp/ip stack for more understanding. The entire stack (and it's associated protocols including UDP at layer4) covers the calls from the app level.

This can lead to more understanding of connection oriented vs. connectionless. A true socket is formed with TCP, not so with UDP where the app must handle the socket.

Understanding of what? If you can't say what "checking" you're talking about then you have no idea what you're talking about. The only "checking" will be done if the app implements any features that would be normally done in TCP such as a connection like a state machine. There is no checking of where the UDP packet came from unless the app is programmed to do so. UDP and TCP are independent of IP, they only depend on the port identifiers, which represent traditionally processes on a source and destination. Just saying what you mean by checking or don't say there is checking.

I was trying to dumb it down for you to understand the difference between connection and connectionless. I suggest you look into the tcp/ip stack and differences from a stack level and a packet structure because I can't draw it out for you on a forum.

tcp - socket is handled by the stack
udp - socket is handled and checked by the app

 

[mcmilljb]

Originally posted by: Nothinman

The only "checking" will be done if the app implements any features that would be normally done in TCP such as a connection like a state machine.

Which pretty much has to be done if the app hopes to process packets from more than one host at a time.

There is no checking of where the UDP packet came from unless the app is programmed to do so.

Which is the point, the app has to do it since the kernel won't be doing it on it's behalf.

I don't consider that "checking". That's just processing of the information. Well you have to ask the kernel for the information instead of just being provided. I would consider "checking" if I want to see if a previous packet has been sent. The reason I say you don't have to "check" intially is because the application is going to request that information already when it's pulling out the data payload, then it's checking previous connections.

Do you think we see the same level now?

 

[mcmilljb]

Originally posted by: spidey07

Originally posted by: mcmilljb

Originally posted by: spidey07

Originally posted by: mcmilljb

Originally posted by: Nothinman
Yea, I know how it works but the app still has to do it's own checking because that UDP packet could've come from anywhere since the kernel doesn't have a session with which to associate it.

What checking though? The app knows where the packet came from the information stripped off the packet while it's at the TCP/IP layer. Think about about a basic DNS query. It does not care who sent the request until it is ready to send the reply. Maybe illustrate what you mean by checking.

Look into the tcp/ip stack for more understanding. The entire stack (and it's associated protocols including UDP at layer4) covers the calls from the app level.

This can lead to more understanding of connection oriented vs. connectionless. A true socket is formed with TCP, not so with UDP where the app must handle the socket.

Understanding of what? If you can't say what "checking" you're talking about then you have no idea what you're talking about. The only "checking" will be done if the app implements any features that would be normally done in TCP such as a connection like a state machine. There is no checking of where the UDP packet came from unless the app is programmed to do so. UDP and TCP are independent of IP, they only depend on the port identifiers, which represent traditionally processes on a source and destination. Just saying what you mean by checking or don't say there is checking.

I was trying to dumb it down for you to understand the difference between connection and connectionless. I suggest you look into the tcp/ip stack and differences from a stack level and a packet structure because I can't draw it out for you on a forum.

tcp - socket is handled by the stack
udp - socket is handled and checked by the app

The data is encoded and decoded like a stack. It's all handled by the TCP/IP stack until a point. For TCP, it creates a nice stream that only shows the data to the app. For UDP, the stack provides the payload just like TCP except you don't know any about it except what you can request information from the kernel about the packet. For a UDP application, it can request the information from the stack of where the packet came from. I consider that just part of the app request process because it does not have to request any of the information, but it is there if it wants it.