Welcome to Linux Knowledge Base and Tutorial
"The place where you learn linux"
Traveller''s Lunchbox

 Create an AccountHome | Submit News | Your Account  

Tutorial Menu
Linux Tutorial Home
Table of Contents
Up to --> Networking

· TCP-IP
· IP Addressing
· Pseudo Terminals
· Network Services
· Network Standards
· Subnet Masks
· Routing and IP Gateways
· The Domain Name System

Glossary
MoreInfo
Man Pages
Linux Topics
Test Your Knowledge

Site Menu
Site Map
FAQ
Copyright Info
Terms of Use
Privacy Info
Disclaimer
WorkBoard
Thanks
Donations
Advertising
Masthead / Impressum
Your Account

Communication
Feedback
Forums
Private Messages
Recommend Us
Surveys

Features
HOWTOs
News
News Archive
Submit News
Topics
User Articles
Web Links

Google
Google


The Web
linux-tutorial.info

Who's Online
There are currently, 222 guest(s) and 1 member(s) that are online.

You are an Anonymous user. You can register for free by clicking here

  
Linux Tutorial - Networking - TCP-IP - Network Services
  Pseudo Terminals ---- Network Standards  


Network Services

In the discussion above, I used the telnet command as an example of one of the programs that use TCP/IP. However, there are many others which provide additional services such as transferring files, electronic mail, networking printing, and access to remote filesystems. Other products, such as database applications may have one central machine containing all the data and access is gained from the other machines via TCP/IP. Often this access is invisible to the user who just sees the "front end" of the database.

This configuration, where one machine contains the data or resource that an other machine uses is very common in computer networking. The machine with the resource that it is providing to other machines is referred to as the server, because it is serving the resource to the other machine. The machine that is using the resource is called the client. This model, where one machine is the server and the other is the client is referred to as a client-server model.

Another common network model is the peer-to-peer model. In this model, there is no one central machine that has all the resources. Instead, all machines are on equal status. Often times, these two models sort of blend together. In Linux networks, it is possible to have multiple servers, each providing many of the same resources. In can also happen that multiple machines all have resources that the others need so everyone is acting as both a client and a server, similar to peer-to-peer, which is common in Microsoft Windows networks.

On Linux systems, there are dozens of resources available. Many of which are well-known such as telnet, others, such as ntp are more obscure. Like calling into a large office building with a central switchboard, our server needs to know what numbers are associated with which programs in order to make the proper connection. In the same regard, you need to know what office you want to reach before you call. In some cases you can call and say you want a particular extension. In other cases, you say you want a particular office. In a office building there is a list of available "services", called a phone book. On a Linux system the phone book is the file /etc/services.

The /etc/services file contains a list of what services a particular machine may have to offer. The concept of a service is slightly different than the concept of a resource. A machine may provide many resources in the form of login shells that it provides to remote users, however all of them are accessing the machine through the one service: telnet.

In addition to what service the machine provides, /etc/services also lists the port. To understand the idea of a port, think about this as being the telephone number. When I call in to a machine (say using telnet), I am connected to the telnet program on the other side through a particular port. This is as if I were calling a large office building with a single switchboard. When I reach that switchboard, I tell the operator which office or person I want to talk to. In the ancient history of telephones, that operator had to make the connection between the incoming line and the office herself.

A port can also be thought of as the socket that the operator plugs the phone lines into. Like in that office building, there may be a set of these sockets, or ports, that are directly connected to a specific person (i.e. service). These are well-known ports. There may be offices with their own operator (maybe just a receptionist) who passes the incoming phone call to the right person or may even pick someone themselves to take the call (such as when you call a government agency with a generic question and there is no one person responsible for that area).

On a Linux system using TCP/IP, the principle is the same. There are dozens of services that one can connect to, but only one way into the system, that's through your network interface card. In order for you to be able to connect to the right service, there has to be something like an operator to make the connection for you. This is the program /etc/inetd. This is the "Internet Daemon" and often referred to as a "super server" since it is inetd's responsibility to wait for requests to access the other servers on your system and pass you along.

Like in our office building, you may know what number you want, that is, which port. When you make the connection to inetd, your process tells it what port you want to connect to and inetd makes the connection. On the other hand, you may have a program that does not have a well-known port. Therefore a new port needs to get created.

The inetd daemon "listens" for the connections. You can say that it is listening on multiple ports in the sense that it manages all the ports. However, it is inetd that makes the connection between the incoming connection and the local port, and therefore to the local server. This mechanism saves memory since you don't need to start up the servers you aren't going to use. This is similar to having a central switchboard and not requiring every office to have their own. You can see how this looks graphically here:

Image - Graphical representation of the inetd daemon (interactive)

Normally, inetd is started during system start up from a script under /etc/rc.d. When it starts, inetd reads its configuration file (/etc/inetd.conf) to obtain the necessary information to start the various servers. It then builds the logical connection between the server and its respective port. Kind of like laying the cable from the central switchboard to the various offices. Technically it creates a socket, which is bound to the port for that server.

When inetd gets a connection request (the phone rings) for a connection-based port, it "accepts" the incoming call which creates a new socket. That is, there is a logical connection between the incoming request and the server. Inetd can now continue to listen on the original port for addition incoming calls.

If the port is connection-less (UDP), the behavior is dependent on entries in the /etc/inetd.conf file. If inetd is told to wait (there is a wait in the fourth column), then the server that was called must process the incoming message before inetd can go on. If told not to wait (there is a nowait in the fourth column), inetd will continue to process incoming requests on that port. If you look in /etc/inetd.conf you see that almost exclusively TCP ports are no wait and UDP ports are wait.

Note that the inetd will start the program listed in /etc/inetd.conf based on the port requestion (which is listed in /etc/services). However, if the appropriate program is already running, there is no need for inetd to start it. Therefore, you may have an entry in /etc/services, but not in /etc/inetd.conf. Services that are not started by inetd are usually referred to as "stand-alone" services. You may have case (like HTTP or FTP) where the program (i.e. the service) is already running, there is no entry in /etc/services. This is because such services us well-known ports and typically nothing else is going to try to use them. However, if you have a "non-standard" program using a special port, then it needs to write an entry in /etc/services to ensure that other programs do not inadvertently use that port.

 Previous Page
Pseudo Terminals
  Back to Top
Table of Contents
Next Page 
Network Standards


MoreInfo

Test Your Knowledge

User Comments:


You can only add comments if you are logged in.

Copyright 2002-2009 by James Mohr. Licensed under modified GNU Free Documentation License (Portions of this material originally published by Prentice Hall, Pearson Education, Inc). See here for details. All rights reserved.
  
Show your Support for the Linux Tutorial

Purchase one of the products from our new online shop. For each product you purchase, the Linux Tutorial gets a portion of the proceeds to help keep us going.


Login
Nickname

Password

Security Code
Security Code
Type Security Code


Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Help if you can!


Amazon Wish List

Did You Know?
The Linux Tutorial welcomes your suggestions and ideas.


Friends



Tell a Friend About Us

Bookmark and Share



Web site powered by PHP-Nuke

Is this information useful? At the very least you can help by spreading the word to your favorite newsgroups, mailing lists and forums.
All logos and trademarks in this site are property of their respective owner. The comments are property of their posters. Articles are the property of their respective owners. Unless otherwise stated in the body of the article, article content (C) 1994-2013 by James Mohr. All rights reserved. The stylized page/paper, as well as the terms "The Linux Tutorial", "The Linux Server Tutorial", "The Linux Knowledge Base and Tutorial" and "The place where you learn Linux" are service marks of James Mohr. All rights reserved.
The Linux Knowledge Base and Tutorial may contain links to sites on the Internet, which are owned and operated by third parties. The Linux Tutorial is not responsible for the content of any such third-party site. By viewing/utilizing this web site, you have agreed to our disclaimer, terms of use and privacy policy. Use of automated download software ("harvesters") such as wget, httrack, etc. causes the site to quickly exceed its bandwidth limitation and are therefore expressly prohibited. For more details on this, take a look here

PHP-Nuke Copyright © 2004 by Francisco Burzi. This is free software, and you may redistribute it under the GPL. PHP-Nuke comes with absolutely no warranty, for details, see the license.
Page Generation: 0.07 Seconds