The Client-Server Model

 

Client-Server Processes

 

A server is a process that provides services.  A client is a process that uses services. These terms are also casually used to refer to the servers on which server processes and client processes run.  Commonly client-server processes operate over a network. 

There are innumerable client-server processes - everything from well-known processes such as telnet connections to applications written internally.  A system that provides services of one kind will probably be a client for other services.  Servers may provide access to devices such as printers, disks and storage arrays or to software services such as name services or file systems

.

inetd: inetd is a daemon that monitors the network connection for requests for services to be started on demand, and starts those services as they are requested.   It is started by the script /etc/rc2.d/S72inetsvc, and uses the configuration file /etc/inet/inetd.conf. 

 

Well known services: These services may be of two kinds: "well known" services, and rpc services. Well-known services are services that are widely used and cross-platform. Each of these services is always assigned the same, well-known, "port number" (one of 1-1024), such as port 23 for telnet.  A port number is a reference to a program sent over the network. . "Well known" services are listed in /etc/services by their assigned port numbers, which are controlled by ICANN (Internet Corporation for Assigned Names and Numbers).

 

RPC: The rpc services are less well known; they may be Sun software or widely available Unix utilities; but they may also be software from a small company, or even software written at the site at which it runs.  The rpc services do not have assigned port numbers, so at boot time, the kernel assigns an EPHEMERAL port number to each of these programs, thus "registering" that service. Processes that start at boot from start scripts request port number assignment from the kernel directly. Programs that start on demand are registered by the daemon inetd when it starts. These ports are said to be dynamically bound to the service.  Thus every program that can be started over the network has a port number associated with it by the time boot has finished. Well known services get the same number every time. Rpc services may get different numbers every time.  Rpc services are listed in /etc/rpc by program number, and their program number is associated with a port number in a table in RAM that is set up at boot time and monitored by a daemon called rpcbind.  It is possible for more than one process to list the same port number: in that case, they are running as child processes of a single parent that uses the port.

 

Starting services:  Programs requested over the network, both well-known and rpc, are started in one of two ways.  They may be started at boot time, from start scripts, like sendmail (well known) or mountd (rpc).  Services that start at boot request their own port numbers from the kernel.  From that time on, the service monitors its own port number and answers service requests.  Services such as telnet (well known) or rup (rpc) may also be started on-demand by the daemon inetd when requested.  A program which must be started on demand, whether it is well known or rpc, must be listed in the file /etc/inet/inetd.conf, which gives the startup information necessary for inetd to start the program, including the full path to the command and all options.  Inetd knows the programs it has to start because at boot time, it reads the file /etc/inet/inetd.conf and "registers" the programs listed therein, making sure each has a port number associated with it. 

 

On the client system, when a request for a well-known program is issued by a user, the kernel assigns the outgoing request a random port for the source port and uses the well known port number as the destination port. When that request for a well known service arrives at the server, inetd on the server looks in /etc/inet/services to find the name of the program associated with that port, then uses the information from /etc/inet/inetd.conf to start the appropriate daemon, which then provides the service (if the processes starts on request) or passes control of the service to an already-running program (if the process starts at boot time).  For example, if inetd gets a request on port 23, it looks in /etc/services and sees that port 23 is associated with telnet.  In /etc/inet/inetd.conf, the line beginning with telnet contains the command necessary to start the telnetd daemon.  A socket is then created, and takes over control of the process. Packets are sent between the well known port on the server and the randomly assigned port on the client.

 

This only works for well known services, like ftp or telnet, which always are assigned the same ports on every operating system.  For rpc services the client host sends a request with a program number from the file /etc/rpc to the destination host on port 111, which

is the port associated with the daemon rpcbind. Inetd passes the request to rpcbind, which looks in the file /etc/rpc for the program name and program (NOT port!) number, then checks the table in RAM to see if there is a port number mapped to that program number.  If there is, rpcbind passes the port number back to inetd, which sends the associated port number back to the client computer, which then sends a request for the service to that port. Inetd then starts the appropriate service from /etc/inetd.conf (if the processes starts on request) or passes control of the service to an already-running program (if the process starts at boot time).   Some rpc services are listed in /etc/inetd.conf by number and not name.  These are services added in Solaris 2.5.1 or later, and they are listed by number because they will not be present in Solaris 2.5.0 /etc/rpc files.  They must be listed by number for backwards compatibility. 

 

Preventing services from starting: You can prevent services from being offered on your system (finger!) by commenting out the appropriate line in /etc/inet/inetd.conf and restarting inetd. This does not prevent you from requesting services, since the kernel assigns a random port to the outgoing request...not a specified port. Note that changes to /etc/inet/inetd.conf must be followed by killing and restarting the daemon inetd.  Its start|stop script is /etc/init.d/inetsvc.

 

Port numbers are also crucial in handling security for systems connected to the Internet.

 

A group of local area networks under the control of one authority is called an Autonomous System. The Autonomous System will be connected to the internet via a heavily secured computer called a gateway, which is any system that transmits packets between the Internet and an Autonomous System. The gateway may be configured to accept only certain packets from the Internet. The software used for this configuration is a firewall. Firewalls may be set up so that any packets directed to port 23 are discarded – thus users within the Autonomous System can telnet to each other, but never outside the Autonomous System, and no one outside can telnet in. Port numbers are also used in setting up NAT translators for private networks. When a host on the private network generates a packet, the gateway picks it up, and adds the source port and the private IP address of the system to a table along with a port number chosen by the gateway. The packet is then repackaged with the IP address of the gateway as its source IP and the port number assigned to the system in the gateway’s NAT table as its source port number. When a packet is sent in return, the gateway then uses the destination port number, along with its NAT table, to direct the packet to the correct port on the correct originating host.

 

Monitoring services: rpcinfo is used to monitor the rcp services.  With no options, it

identifies the rpc programs registered on the local host. With

            -p <host> - it identifies the rpc services registered on the host listed. Output includes the registered port for the service.

 

            -d <program> <version>  - unregister the specified version of the specified

                        program.

 

Acronyms:

IANA – Internet Assigned Numbers Authority – the organization that oversees IP address and port number uses, under the direction of ICANN.

ICANN – Internet Corporation for Assigned Names and Numbers. A new, non-profit, international organization that oversees assignment of IP addresses and of domain names.

RPC – Remote Procedure Call – a program which calls on the counterpart program on another host.

TI-RPC – Transport Independent Remote Procedure Call – The type of RPC protocols used by SVR4.  They allow applications written with this protocol to run on any Operating system, so that applications can exchange data across heterogenous environments. 

TLI – Transport Layer Interface – An API for OSI Transport and Session layers.

Definitions:

 

arbitrary/ephemeral port – a port of number greater than or equal to 32768, which the kernel randomly assigns to an exiting datagram generated by client process, or which is assigned to an rpc server.

port – an address space on a disk: designates the program resident at that address space.

privileged – ports from 1 to 1024 which provide the "well known services." Root owns all these processes. 

rpc call – a request to run a specific rpc application. The kernel on the client sends a request to the kernel on the server.

rpc services – services which are not "well known", and which are started via the daemon rpcbind (port 111).  They have the format rpc.xxx (where xxx) is some number) in the file /etc/inetd.conf, and are listed in /etc/rpc.  They are assigned "ephemeral" ports at boot time (those greater than 32768).

socket– BSD interface between the transport layer and a program.

"true" environment – one in which only the services requested are started.

"well known" services – published, established, widely used services, registered with ICANN.  In /etc/inetd.conf, they start with in.xxx  where xxx is a the service name.

 

Commands:

rpcinfo – RPC information and management utility.

            no options  - identify the rpc programs registered on the local host.

            -p <host> - identify the rpc services registered on the host listed. Output includes

                        the registered port for the service.

            -b <program>  <version>  - identify servers on the network running the

specified version of the specified program.

            -u <server>  <program> - identify all versions of the specified program running

                        on the specified server.

            -d <program> <version>  - unregister the specified version of the specified

                        program.

            -t  <server>  shows rpc information for tcp programs.

netstat  -a   - shows established connections and ports in use. Swind is the send buffer size, and Rwind is the advertised reception window size. 

 

 

Files:

/etc/init.d./inetsvc  - start script for inetd

/etc/init.d/rpc - start script for rpcbind

/etc/inet/inetd.conf  - file which starts services invoked upon request. 

format:

service-name                endpoint                                protocol                 no/wait        uid of owner                program                 args

 

service name – service listed in /etc/services OR /etc/rpc, in the format

 name|program number/version for rpc services.

endpoint:  socket type (stream, dgram, raw, seqpacket) or tli.

protocol:  from /etc/inet/protocols  (for well known services). For rpc, the value is "rpc/*" or "rpc/<netid>," where the list implied by * is found in the file /etc/netconfig.

wait status:  "wait" means: if a program is requested, but is already running, wait til the first one stops running to start the next.  "no wait"means start multiple instances. UDP services must all be "no wait;" TCP can be "no wait."

uid – the user identification number to use as the process owner. For "well known" services, this value must be 0 (root), and thus they are described as "privileged."

program – if inetd provides the service, the word "internal". Otherwise the absolute path to the command that provides the service requested.

args –the command plus all options.

 

/etc/inet/services – contains the well known services. Format:

service name            port/protocol

service name – the name of the service

port – the well known port number assigned to that service by IANA.

protocol – the protocol, such as tcp or udp used by the service.

/etc/rpc – contains the rpc services. Format:

service name            program number            aliases

service name – the name of the service

program number – the number assigned to the program

aliases – other names by which the service is known.

/etc/init.d/rpc – Run level 2 start script, which begins rpcbind and registers rpc services.

/etc/init.d/inetsvc – Run level 2 start script which begins inetd.

Misc:

Protocol stack for rpc applications                  ISO/OSI layer

XDR                                                                presentation

TI-RPC                                                            session

TLI-API (SVR4)/Sockets API(BSD)                 session

TCP/UDP                                                        transport

IP                                                                     internet

 

Services started at boot time by start scripts:

sendmail, NIS, mount, nfs

Services started on demand by /etc/inetd.conf:

telnet, ftp, wall, rup

Hosted by www.Geocities.ws

1