|
|
The OSI Transport Layer :
To understand the functionality of this layer you would need to understand the concept of client/server. In a nutshell client is the
consumer and server is the provider. When you launch your web-browser and try to access a website, by typing in its url, your machine
becomes a client (joining the milieu of million other clients craving for information). The information which the client seeks is provided
by the server.
If the client seeks to have a webpage then the request has to be catered to by a webserver, if the client seeks download a file then the
request maybe catered to by a ftp server, if the client seeks to access a database the request maybe catered to by a database server
(ex a sybase server). The two prerequisites for the client to obtain the information it seeks is that it should be aware of the type of
information it seeks and exact resource from where it seeks to obtain the information.
Let me explain this with an example, lets say you launch your mail client (Microsoft outlook if you belong to common genre) the first
thing that's gonna happen is a hunt for your mail server. While configuring the client you would need to specify the mail server's IP address.
Once the client is able to reach the server dumps your mail from the server to your pc (would be a quick process if you are the anti-social
kind who hardly gets mails).
Mail server like any other server runs a software application, the purpose of this application is to authenticate users and allow them access
to their mails. To do this job faithfully it would be required that the server is available 24*7 to cater to the needs of the users/clients
(some chaps like to check their mail at 4 am) so the server never sleeps. In fact it continuously listens for requests regardless of whether
there are any requests or not. This listening part happens at the software level and yeah this functionality resides at the transport layer.
In technical terms the server is said to be listening on a port. A port is nothing but a file pointer. It is only logical because all
the incoming requests need buffering (say 1000 clients accessing the mail server at the same instance of time). All the requests are
buffered in a file and the server continuously checks the file for requests.
Unless we are talking about a multithreaded server, the requests would be catered on FIFO (First In First Out) basis. Mail servers are
mostly multithreaded in that they can cater to several requests at a time. Well there is a difference between having only one service
personnel catering to the customers at the ticket counter and having 100 service personnel, that's the difference between a single threaded
server and multithreaded server. Now like I said the server application is designed to be listening continuously on a port and yet again I
would like to remind you that a port is nothing but a file pointer. In the case of a mail server the applications running are SMTP and POP3.
SMTP is the application which takes care of allowing the users to access their mail either by directly checking it on the server or by
downloading the mails to the individual clients.
SMTP listens on port 23 in accordance with the standards. POP3 is the application which takes care of receiving mails, say when you send
a mail to your friend your mail would initially get into the POP3 buffer of your mail server and from there it would be sent to the POP3
buffer of you friend's mail server. When your friend accesses his mail-server to read his mails he is first authenticated by the server
(Remember the username and password screen) and then the SMTP application interfaces with the POP3 buffer interface and obtains the mails
for the your friends and either dumps it his local pc or allows him to read it on the server itself. POP3 listens on port 110 according
to standards.
The IETF, IEEE, ISO, NIC and ANSI are some of the organization involved in standards creation. Standards are important because it
ensures that a set of rules are in places so the different players (manufacturers) play the game with the same rules (it usually
avoids chaos). SMTP, POP3, HTTP, FTP, TFTP, NTP and DNS are examples of popular applications which we use on day to day basis
everything time we log onto the internet. Now like I said these are all application so I am talking about Layer7, Layer6 and Layer5
of the OSI layer.
But all the server applications need to listen for request from the users that is when they make use of the layer4 of the OSI layer.
I mentioned that ports are entities defined at the transport layer (layer 4). If the client wants to access a certain application on
the server it should access it on the correct port.
Lets say a server is running HTTP, FTP and SMTP/POP3 (We are talking high capacity server here), so there are 4 server applications
running on the same machine. HTTP listens on port 80, FTP listens on port 21, SMTP listens on port 23 and POP3 listens on port 110.
If you want to access a webpage on this server your machine will send a request to this server on port 80 so that the HTTP application
comes into picture, if you want to access mails then your machine would send a request to the server of port 23/110 so the SMTP and
POP3 application caters to your request.
These popular application have been assigned fixed ports to ensure that clients are able to access the required services on these ports.
No matter where the web-server is being installed (America, Australia or Antarctica for that matter) it would listen on port 80 for
HTTP requests. The web-server can obviously be designed to listen on a different port but then it would be one heck of a job to tell
the whole world that "hey if you want to access my webpage you need to send your request on port 343434"
Then there are several other servers designed for use within an office or within a community, in which case the port on which these servers listen is decided by the designer and is advertised to the users/clients. For example in my office we have a server called the Beacon server which listens to request on port 14007 and replies by feeding back a GUI. The concept of ports is an important entity of the transport layer. We have already discussed the application, presentation and session layer, the actual user data comes from the application layer and is wrapped up by the presentation and session layer to complete the user part of the packet.
So let's get it clear, packet is the whole or the end product and the packet comprises of the user part, the transport layer information, the network layer information, the link layer information and the physical layer information. The user part comprises of the application layer information (mostly the user data), the presentation layer information (to facilitate comprehension on the other end) and the session layer information (to ensure the right information goes to the right session). I would like to consider the transport layer, network layer, link layer and physical layer as the machine part because it does not contain any user data. One thing transport, network and link layer have in common is that they all have an addressing schema.
The addressing part in transport layer is handled by port numbers, the addressing part in the network layer is handled by IP address
in most cases and the addressing part at the link layer is handled by the link address (ex mac address, dlci, vpi/vci). The transport
layer functionality is three fold
Addressing (fulfilled by the concept of ports)
Transport (duh obviously, handled by protocols like TCP, UDP, RTP et al)
Error correction
I have already explained the part of addressing; let me get on to the concept of transport. In general there are two kinds of transport
possible reliable and unreliable. Depending on the application the transport required may vary. For example SMNP which is a network
management application uses unreliable transport whereas HTTP uses reliable transport. TCP (Transmission control protocol) defines the
protocol for reliable transport and UDP (User datagram protocol) defines the protocol for unreliable transport. SNMP uses UDP at the
transport layer whereas HTTP uses TCP at the transport layer. There is also a concept of real time transport and RTP (Real-time transport
protocol) defines the protocol for real-time transport.
Lets us take it one at a time starting with TCP.
Continue to: TCP/IP Explained
|
|
|
|
|
|
|
|
