0

In /etc/services, a service name can have multiple (transport protocol, port number) pairs. For example, The Linux Programming Interface says:

The /etc/services file consists of lines containing three columns, as shown in the following examples:

# Service name  port/protocol  [aliases]

http            80/tcp                  # Hypertext Transfer Protocol
http            80/udp
ssh             22/tcp                  # Secure Shell
ssh             22/udp
telnet          23/tcp                  # Telnet
telnet          23/udp
smtp            25/tcp                  # Simple Mail Transfer Protocol
smtp            25/udp

Which field(s) can be a key in the table?

The example shows a service name can correspond to more than one transport protocols.

Given a service name and a transport protocol, can they correspond to more than one port numbers? In other words, can a service listen at two ports in the same transport protocol?

Thanks.

Tim
  • 101,790

1 Answers1

4

The file is described in the services(5) manpage, and its usage in the related functions’ manpage. The latter shows that the following pairs are expected to be keys:

  • name and protocol;
  • port number and protocol.

Note that services can have aliases (which your example doesn’t illustrate). www for instance is typically an alias for http:

http            80/tcp          www             # WorldWideWeb HTTP

Regarding what services can do, /etc/services only provides a mapping, it doesn’t constrain anything. Thus, someone asking for http on TCP will be told that the corresponding assigned port is 80, but an HTTP dæmon can listen on any port it wants to (and is allowed to); likewise, someone asking for port 80 on TCP will be told that the corresponding name is http, but that doesn’t mean that a server listening on port 80 has to be an HTTP server. Furthermore, single processes can listen on multiple ports, and on BSDs and Linux since kernel 3.9, multiple processes can listen on the same port.

Stephen Kitt
  • 434,908
  • Thanks. "can a service listen at two ports in the same transport protocol?" – Tim Feb 13 '19 at 21:53
  • The key (uniqueness) requirement answers that, doesn’t it? – Stephen Kitt Feb 13 '19 at 21:54
  • Is it correct that a service can only listen at one port in a transport protocol, and a process can listen at two ports in the same transport protocol (so the process actually runs two services)? – Tim Feb 13 '19 at 21:56
  • Can a service have two ports in the same transport protocol for its listening purpose? – Tim Feb 13 '19 at 22:19
  • If a client asks for "http on TCP" then it will only ever get one response. The getservbyname() call will only return one value. If you list it multiple times in /etc/services then you will get undefined (implementation specfic) behaviour. – Stephen Harris Feb 14 '19 at 01:56
  • If "multiple processes can listen on the same port," then how can they know which of them a message received at the port should be delivered to? – Tim Feb 14 '19 at 06:08
  • For TCP connections, the processes are listening for incoming connections, not incoming messages. Messages are handled inside connections and go to the appropriate process. For UDP it’s not supposed to matter. In all cases, all the listeners are supposed to be equivalent — at least on Linux this is seen as a load-balancing and high-availability measure. – Stephen Kitt Feb 14 '19 at 06:49
  • @Tim, whoever call accept first, gets the connection. – 炸鱼薯条德里克 Feb 14 '19 at 09:21
  • @StephenKitt Thanks. Is it correct that two processes can't share the same socket, but can share the same port? Two connections can't share the same socket, but can share the same port? Is socket a per connection/process concept, while port isn't? – Tim Feb 14 '19 at 17:30
  • @Tim sockets are very generic, see socket(2). Like other file descriptions, they are shared with child processes, so multiple processes can share a socket. Connections are given new sockets, connected sockets, and those aren’t shared by connections, but can be shared by processes. – Stephen Kitt Feb 14 '19 at 17:38
  • You can see connection sharing in action with inetd: inetd accepts the connection, gets the connected socket, and passes that to its child process. The connected socket is open in inetd and the child which is started to handle with the connection. – Stephen Kitt Feb 14 '19 at 17:40
  • 1
    We’ve gone a long way from “which field(s) can be a key in the table in /etc/services?” at this point... – Stephen Kitt Feb 14 '19 at 17:43
  • Thanks and apology. I'd appreciate if you could also consider https://unix.stackexchange.com/questions/500714/internet-domain-socket-vs-transport-protocol-tcp-udp-socket-and-port – Tim Feb 14 '19 at 21:41
  • @炸 "whoever call accept first, gets the connection." Once a process accepts and thus gets a connection, can another process listening on the same port accept and get a second connection (possibly from the same or different peer port)? – Tim Feb 15 '19 at 02:14
  • @StephenKitt you said "Connections are given new sockets, connected sockets, and those aren’t shared by connections, but can be shared by processes." (1) Regarding relations between sockets and connections, Tanenbaum's Computer Networks says "A socket may be used for multiple connections at the same time. In other words, two or more connections may terminate at the same socket. Connections are identified by the socket identifiers at both ends", (2) Regarding relations between socket and processe, If two processes can share a socket, they can create two connections on the socket at will. – Tim Feb 15 '19 at 21:39
  • @Tim I bow to your superior knowledge. – Stephen Kitt Feb 15 '19 at 21:53
  • Please don't mock me. Look, here are the posts created after your comment https://unix.stackexchange.com/questions/500714/linuxs-internet-domain-socket-transport-protocols-tcp-udps-socket-and-port and https://stackoverflow.com/questions/54717531/tcps-socket-vs-linuxs-tcp-socket – Tim Feb 15 '19 at 21:56
  • I’m not mocking you. You’re stating what you believe to be facts, and your mind seems set, so let’s leave it at that. – Stephen Kitt Feb 16 '19 at 10:08