httportmap implements a similar portmapper functionality as the traditional system portmap daemon. A portmapper enables applications to listen on any available port number instead of a specific, assigned port.
As a brief overview, a portmapper allows known applications to listen on any available port, instead of assigning a dedicated port to each application. All applications have an assigned name. An application instance starts listening on any available port, and simply registers its name and the port that it's listening on, with the portmapper. An application that wants to to connect to another application's port asks the portmapper which port the other application listens on, then connects to it.
httportmap is an improvement over the traditional system portmapper, that dates back to SunOS 2.0, in several ways:
httportmap uses HTTP
for its implementation, instead of a binary RPC-like mechanism.
To see a list of applications running on the server, open
“http://server/portmap” in a
modern browser that supports XML stylesheets.
Application names use the Internet domain naming scheme for their namespace. The traditional portmapper requires applications to be officially assigned a numerical identifier that the application is known by. With httportmap, applications do not require an identifier assignment, or an explicit addition to a system configuration file. By custom, applications register with httportmap using a domain name, that may take the form of a hostname or an email address. Applications use the application's owner Internet domain namespace, for identification.
Applications may use standard port numbers, or
AF_UNIX domain pathnames for applications running
on the same host.
Applications may selectively choose exclusivity. Registering the same application more than once may be allowed or disallowed; it's the application's choice. Exclusivity is on a per-userid basis. An application registers both its name and its system userid with the portmapper, and exclusivity is enforced on a per-userid level. Different userids may register the same exclusive service, separately.
There's an internal socket connection between the application and the portmapper service. The connection gets established when the first portmapper object gets instantiated, as described later. The portmapper service saves each connecting application's userid and groupid when the application connects to the portmapper, and that determines the service exclusivity. A process's changed userid does not get reflected by any services that get registered subsequently, the portmapper continues to use the process's original userid.
Additionally, with one exception,
an application that uses fork() cannot use the
portmapper for several reasons. LibCXX uses an internal
socket connection to the portmapper, which gets
inherited by a forked process, and multiple processes attempting to use
the same internal connection does not work.
Although it's theoretically possible for multiple processes to share the same internal portmapper connection, this is impractical. Each individual portmapper object's destructor sends a message to the portmapper, deregistering any services that the object had registered, so any kind of sharing must include controlled scope and lifetime of each process's individual portmapper object.
Additionally, the portmapper maintains an association between each process ID, and its executable pathname, as described in the section called “Advertising executable's pathname”. If one of the application's processes terminates, and another process gets the same process id, and registers its own, different executable pathname, the portmapper disables the original registration.
Exception: forking before the first portmapper object instantiation is fine.