There are two potocols in transport layer.Someone can explain me about what are the tasks of those potocols..
"There are two potocols in tranceport layer."
There are actually many transport-layer protocols. I think you mean the two most common Transport protocols: TCP and UDP.
TCP is an end-to-end protocol because it is connection-oriented. One TCP establishes a connection to another TCP. TCP guarantees segment delivery.
UDP is a connectionless, best-effort, fire-and-forget protocol that sends a datagram and doesn't care whether or not it is received.
It is because the transport layer protocols abstract the lower levels (network layer, link layer, physical layer) and they work only considering the existence of the two final communicating entities, abstracting everything that is in the way.
Related
I wonder
which protocol is responsible for managing retransmission? the ethernet protocol or tcp or both?
I was attending a TCPIP course and it is not clear for me which protocol is responsible for managing retransmission
To answer your question, TCP handles retransmission of corrupt frames. Ethernet only detects it.
Systems communicating over Ethernet divide a stream of data into shorter pieces called frames. Each frame contains source and destination addresses, and error-checking data so that damaged frames can be detected and discarded; most often, higher-layer protocols trigger retransmission of lost frames. Per the OSI model, Ethernet provides services up to and including the data link layer.
So the “responsibility” is on TCP. Note that speaking of responsibilities is misleading. You can have UDP (OSI layer 4) over Ethernet (OSI layer 2) in which case the “responsibility” for handling missing data is on the application which may choose to NOT resend (I.e. video streaming in which it doesn’t make sense).
On other data link protocols the resending of frames can be built into the protocol itself.
In that sense, handling retransmissions would be more of a property or feature of the TCP protocol rather than a “responsibility”
As I understand it TCP is required for congestion control and error recovery or reliable delivery of information from one node to another and its not the fastest of protocols for delivering information.
Some routing protocols such as EIGRP and OSPF ride directly on top of IP. Even ICMP rides directly over IP.
Why is UDP even required at all? Is it only required so that developers/programmers can identify what application the inbound packet should be sent to based on the destination port number contained within the packet?
If that is the case then how is information gathered from protocols that ride directly on top of IP sent to the appropriate process when there is no port number information present?
Why are voice and video sent over UDP? Why not directly over IP?
(Note that I do understand thoroughly the use case for TCP. I am not asking why use UDP over TCP or vice versa. I am asking why use UDP at all and how can some protocols use directly the IP layer. Whats the added advantage or purpose of UDP over IP?)
Your question makes more sense in terms of why is UDP useful (than why is UDP required).
UDP is a recognized protocol by the Internet Assigned Numbers Authority. UDP can be useful if you want to write a network protocol that's datagram based and you want to play more nicely with Internet devices.
Routers can have rules to do things like drop any packet that doesn't make sense. So if you try and send packets using say an unassigned IP protocol number between hosts separated by one or more routers, the packets may well never get delivered as you've intended. The same could happen with packets from an unrecognized UDP protocol but that's at least one less door to worry about whether your packet can make it through.
Internet endpoints (like hosts) may do similar filtering too. If you want to write your own datagram based protocol and use a typical host operating system, you're more likely to need to write your software as a privileged process if not as a kernel extension if you're trying to ride it as its own IP protocol (than if you'll be using UDP).
Hope this answer is useful!
First of all, IP and UDP are protocols on the different layers, IP by definition is Internet layer when UDP is transport layer. Layers were introduced to simplify network protocols architecture and to separate concerns. Application layer protocols are supposed to be based on transport layer (with some exceptions).
Most popular transport protocols (in IP network) are UDP and TCP. While TCP is feature rich but with many tradeoffs UDP is very simple but gives a lot of freedom and so typically is a base for other protocols.
The main feature of UDP is multiplexing: ports that allow multiple protocol instances (aka sockets) to coexist on the same node. This means that implementing your own protocol over IP instead of UDP either you won't be able to have multiple instances of your protocol on the same machine or you'll have to implement multiplexing yourself.
There're other features like segmentation and checksum. These features are not mandatory.
And as was mentioned in another answer there're lots of middleware like routers, NATs and firewalls that can ruin the idea of a custom "right over IP" protocol, but it's more like a collateral damage than a feature of UDP.
Sorry for what is a stupid question.
Function of transport layer is reliable delivery of messages. UDP is inherently unreliable, why do we use it at Transport layer then?
Thanks
EDIT: Just to clarify, I have read the Wiki and other sources. My question is
UDP is Unreliable (I know why and the advantages and where it is used etc.) , why not use it(UDP) at some other layer, rather than Transport layer which implies reliability.
Sometimes it is more important that the data be sent quickly and without pauses than that the stream be reliable. DNS uses UDP because the transaction between a DNS server and client consists of only one packet each way. If the packet is lost, it will be re transmitted at the request of the client.
Similarly, streaming video often uses UDP as a transport protocol because the occasional loss of a packet is acceptable. It is preferable that the image quality suffer as a result of lost packets, rather than the video stream suffer jitter or pauses (lag) as a result of TCP synchronization.
Games also often use UDP, sacrificing engine accuracy for improved speed/user experience.
These and more examples can be found in the relevant portions of the wikipedia article.
EDIT
UDP is used at the transport layer because it is a transport layer protocol. It provides "provides end-to-end communication services for applications" (RFC1122).
Reliability services are optional for transport layer protocols.
... rather than Transport layer which implies reliability
There's more than one dimension within "reliability." It's interesting to note that UDP is reliable in that it provides a checksum to prevent against corruption.
Stream protocols like TCP create problems for latency-sensitive applications. For latency-sensitive apps, UDP's natural limitation (to shed traffic during congestion) is a huge boon.
why not use it(UDP) at some other layer
IP datagrams are designed to be small enough to make the next hop transit. UDP datagrams can span IP datagrams, so there's some value added there. But if TCP were a layer above UDP, it would be limited by UDP's semantics (TCP ports are bound to a connection, UDP datagrams are not).
The reason why UDP is used at the transport layer is because the way these layers are set up. UDP is inherently a protocol for transferring data from point A to point B, not as an application or at the hardware layer.
At the transport layer there is no assumption of reliability, but rather that UDP is a protocol for transferring data. Under the 7 layer style of networking, it falls in the interface between the network and session layers. The name Transport layer simply says what it does. Reference wikipedia for more information on the OSI model.
TLDR The reason UDP is in the transport layer is because it is a protocol for data transport, and is therefore in the transport layer. All protocols that deal with data transport fall under this category
Transport layer classes
Class 0 - Simple class
Class 1 - Basic error recovery class
Class 2 - Multiplexing class
Class 3 - Error Recovery and multiplexing class
Class 4 - Error detection and recovery class
I had a strange idea. I heard of software which from my understanding uses UDP to transfer files decreasing the overhead found in TCP packets.
If my app requires TCP and my LAN has software set up to communicate with another datacenter on the other side of the coast with software setup on their end. Would it be possible to send the actual data via UDP but than simulating TCP on both ends?
Does anyone have any ideas or information about such projects?
If you're asking if you can use UDP as a Layer 2, then the answer is yes, sort of. There are various protocols that allow you to create a tunnel to another network using a UDP transport, such as L2TP and even IPsec (with NAT traversal). You could also do it at the application layer.
If you're asking if TCP can be implemented in UDP, the answer is no. First, TCP packets and UDP packets have an incompatible format. Second, TCP and UDP have different protocol numbers (seen in the IP header) which means that TCP traffic destined for a UDP port would not be passed to the correct upper-layer protocol.
Both TCP and UDP are built on top of the IP, but the TCP uses different packet structure and at the layer-2 it is not possible to mimic the TCP using UDP packets.
Of course, if you have the control on both the source and destination, then it is possible to create a reliable UDP tunnel for the TCP packets. This would require some internal information (packet number, ack/nack flags) in the body of the UDP packet.
There is an interesting project http://udt.sourceforge.net/
It is a broadcast-capable reliable file transfer mechanism built on top the UDP.
PseudoTCP is a protocol which implements TCP algorithms on top of the UDP. It was introduced since the NAT traversal for TCP is much more complicated than UDP. But some P2P applications do need a reliable data transfer among nodes.
So far as I know, there are two PseudoTCP variations: Libjingle and Libnice.Libjingle is an open source library from google which was initially for gtalk. You could take a look at file sharing example from libjingle: https://developers.google.com/talk/libjingle/file_share. Recently, Chrome desktop also use PseudoTCP implementation from libjingle for reliable connections.
Yes, you can develop a protocol on UDP that simulates TCP. However, if you simulated TCP fully, it would technically have more overhead. Because TCP is implement as the packet and your simulated TCP is implemented in the body of the packet.
If you only need one or two features of TCP (such as basic ordering), then implementing it in UDP is useful.
Halo uses 2-3 (IIRC) UDP protocols that simulate different features of TCP, then full fledged TCP for initializing game-states. I Shot You First Networking, GDC publication
For example, in one case, they send 3 duplicate UDP packets to overcome packet loss.
If you control the software on both ends, and it is cost-effective to build your own protocol, then UDP can be versatile.
One way to do it now on Linux-3.18+ is to use Foo over UDP (FOU) which implements Generic UDP Encapsulation (GUE). Here's a good introduction to FOU, and the man page for ip-fou.
Or if you want an [open source] UDP based file transfer system there are things like UDT, UFTP, Tsunami-UDP, and even Google's QUIC (Now deprecated in favour of IETF QUIC).
Update: The QUIC protocol now has been standardised by the IETF which provides for secure reliable and unreliable transport over UDP as an alternative to TCP. There's a wide range of QUIC implementations available. There is also a growing set of protocol mappings on to QUIC such as HTTP/3, DNS over QUIC, etc
If my app requires TCP and my LAN has software setup to communicate
with another datacenter on the other side of the coast with software
setup on their end. Would it be possible to send the actual data via
UDP but than simulating TCP on both ends?
No. A UDP socket is in a different namespace from a TCP socket. You will be unable to write UDP at one end and send or receive TCP at the other end. TCP and UDP are peer protocols; both exist at the layer above IP. You can't use one to spoof the other.
Hmm, I believe so. You'd need to use a proxy at both ends, but it should be possible.
The biggest problem you are going to run into is that UDP is designed with the idea that you don't care if some of the packets don't ever make it to the other end.
Here's a link with some more info:
http://www.cyberciti.biz/faq/key-differences-between-tcp-and-udp-protocols/
IMHO, it's not a good idea to transmit files via UDP.
TCP's problems are in its algorithms, not its headers.
You certainly could implement the TCP algorithms on top of UDP. That would effectively be the same as tunneling TCP datagrams inside of UDP datagrams. But all this accomplishes is to add a few more bytes of overhead to each packet, and require another endpoint to unwrap the packets.
UDP itself is just thin shim on top of IP: its a convenient way to access IP packet switched networking without having to dive into kernels or receive special handling from routers. The main reason to implement reliable transport on top of UDP is to get away from TCP algorithms in favor of something more efficient. FileCatalyst was mentioned above as one company which does this, and my own company Data Expedition, Inc. does so as well.
So you could implement TCP algorithms on top of UDP, but you wouldn't want to.
You can simulate something like a connection over UDP, and you as well can add reliability checks and ordering and retransmission and so on. - but then, it still isn't TCP, it just acts the way.
Of course, one of the ends can be a kind of "hub" or "proxy" which does an adaption. Then you don't have a 2-end solution, but in fact a 4 end solution - one pair with "real" TCP and the other with the "self-knitted" "TCP" - which you put together with an appropriately crafted program.
This question already has answers here:
Difference between TCP and UDP?
(13 answers)
Closed 4 years ago.
What exactly is a TCP connection?
I understand there isn't a physical connection from the client to server. Is this connection just the client's socket being linked with the new socket created by the server after the three-way-handshake?
Thereafter once the "connection" is set up, the sockets on either ends of the connection then know where to send their packets.
How does this differ from the way UDP functions other than the initial handshake with TCP?
Is it that each server socket only has one client that sends packets to that particular socket?
What are some possible advantages of having a dedicated connection between hosts? My understanding of TCP and UDP is still very basic, so broad generalizations should suffice.
Let's break this up into parts. First of, the network is based in IP, which is a protocol that assigns an address to each network node, and which allows you to send small amounts of data (usually up to 64kB, but typically only 1500B) from one node to another.
That by itself isn't worth much yet, because we can't make any checks that the data actually arrived, and that it arrived in the right order. If we want an abstract mechanism to transmit arbitrary amounts of data and ensure that they arrived, we need another protocol on top of the network that handles this "transmission". And that's the purpose of TCP.
However, in parallel to TCP, there's another "transmission" protocol that doesn't do any checking at all and has no reliability, UDP. UDP is just a thin wrapper around raw IP packets, which adds a little bit of meta data (like a port number).
UDP is still useful, though, since there are many situations in which the data integrity is already handed off to an even higher protocol, so there's no need for a complex transmission protocol. This is for example used in virtual networking services, where another instance of TCP/IP is typically run over a UDP channel. (Making the channel use a reliable protocol like TCP can actually have disastrous consequences in that case due to resend cascades.)
So the term "TCP connection" refers to the application of the TCProtocol. The protocol is stateful, naturally, and typically proceeds in a SYN-ACK-data-FIN sequence, or SYN/RST in case of a rejected transmission; both peers maintain a status of the connection (handshake, established, closing, closed.) TCP also introduces the terms "server" and "client", the server being the peer that listen()s for an incoming connection.
The main difference between TCP and UDP sockets is that UDP is conectionless and doesn't use any confirmation that the other end received the data.
The Transmission Control Protocol (TCP) is one of the core protocols of the Internet Protocol Suite. TCP is one of the two original components of the suite, complementing the Internet Protocol (IP), and therefore the entire suite is commonly referred to as TCP/IP. TCP provides reliable, ordered delivery of a stream of bytes from a program on one computer to another program on another computer. TCP is the protocol that major Internet applications such as the World Wide Web, email, remote administration and file transfer rely on. Other applications, which do not require reliable data stream service, may use the User Datagram Protocol (UDP), which provides a datagram service that emphasizes reduced latency over reliability.1