This content is part of the series: Speaking UNIX Stay tuned for additional content in this series. If you want to be pedantic, UNIX® is a kernel, or the low-level software that arbiters access to a machine's resources, such as the file system, memory, and the processor. More colloquially, though, UNIX refers to the entire universe of software running atop the operating system. In fact, it's common to say, 'It's a UNIX machine,' to express the system's fundamental capabilities: a UNIX machine typically offers a shell interface, simultaneous access, strong security, and a wide variety of networked services. Frequently used acronyms • DNS: Domain Name System • FTP: File Transfer Protocol • HTTP: Hypertext Transfer Protocol • IMAP: Internet Message Access Protocol • POP: Post Office Protocol • SMTP: Simple Mail Transfer Protocol • TCP: Transmission Control Protocol • UDP: User Datagram Protocol Indeed, UNIX (the kernel, et al.) is often chosen specifically for its networking applications. FTP, POP, SMTP, and HTTP were all implemented initially on UNIX machines and continue to drive usage.

Inetd is often referred to as a 'super server.' Xinetd, a variant of inetd. Domus 3d Gratis Italiano. Best of all, it can turn virtually any script or program into a service.

UNIX systems also run services, often referred to as daemons, to synchronize with a central clock (the Network Time Protocol), exchange news postings (the Net News Transfer Protocol), resolve hostnames into IP addresses (DNS), and more. A partial but robust list of oft-used services can be found in /etc/services on most UNIX machines.

The file resembles. Some common entries found in /etc/services, the UNIX catalog of network services ftp 21/tcp fsp 21/udp fspd ssh 22/tcp ssh 22/udp telnet 23/tcp smtp 25/tcp mail Each entry in /etc/services lists the name of the service; the port number and protocol that the service uses (either TCP or UDP); and no, one, or more aliases for the service name. Each system daemon examines /etc/services to find the proper port and protocol to use to offer its service. For example, the daemon to process incoming e-mail looks up 'smtp' (the proper name) or 'mail' (one of the aliases) and listens for incoming TCP connections on port 25. Similarly, the remote login daemon searches for 'ssh' in the file and listens for incoming TCP connections on port 22. Ports and FSP Ports 22 and 25 are the canonical ports for Secure Shell (SSH) and SMTP, respectively, according to the Internet Assigned Numbers Authority (IANA). A systems administrator can relocate these canonical settings to other numbered port in each daemon's own configuration file to reduce the risk of attacks.

After all, if you cannot find a service, you can't attack it. As a further aside, the File Service Protocol (FSP) is an asynchronous transfer protocol for files. It enables simultaneous transfers, because a persistent connection isn't required.

However, FSP is rarely provided on modern systems. Briefly, TCP establishes a persistent connection between two machines to transfer data. Moreover, a TCP connection is reliable, meaning that the two machines cooperate to guarantee the delivery of a piece of data. By comparison, UDP is unreliable, meaning a datum may or may not arrive at its destination.

Hermione Trainer Akabur. The sending machine transmits the data and moves on. You can think of a port number as a unique address.

It directs traffic to a specific destination on the remote machine. If a machine's hostname is the equivalent of a city block, the port number is an individual street address. If a machine is central to your organization or if you simply operate a sole server, the system may run 5, 10, or even more daemons.

For instance, a server for a small company might run services to synchronize time with a world clock, serve Web pages, traffic e-mail, permit remote shell access, print pages, transfer files, connect to a database, monitor system stability, serve domain names, and share files via the Network File System (NFS). Such a configuration is not uncommon, largely because a daemon does not impose great overhead. Daemons are usually designed to sit idle and wait for requests. When a demand for service appears, the daemon wakes, reacts to and processes the request, and then returns to slumber. Nonetheless, a large contingent of dormant processes can affect system performance. To be sure, when you expect a service to be in great demand, such as sustained Web visits, a perennial daemon makes sense. Otherwise, the daemon may best be reconfigured to execute as needed.

But how can a system offer an always-on service yet launch the service as needed? The solution is a proxy service that anticipates a variety of incoming requests and launches the appropriate service on demand for subsequent processing. On UNIX and Linux® systems, the proxy is called inetd. Given a list of services, inetd watches those services' ports and protocols for requests. When activity occurs, inetd maps the incoming request to standard input ( stdin), standout output ( stdout), and standard error ( stderr) and launches the proper daemon. The service processes the data and terminates. Inetd keeps resource consumption to a minimum and makes daemons easier to write.