Because each service added to a multi-service server needs its own connection ports, a multi-service server needs to be able to multiplex over several connection ports.
A single-threaded, single-service non-concurrent server doesn't use multiplexing because it doesn't need them. A single-threaded, single-service concurrent server uses multiplexing because the server needs to be able to handle several sessions at the same time.
Given that a single-threaded, single-service, concurrent server already does multiplexing, modifying the server to handle additional possible connections on other ports should be a simpler task than adding multiplexing to a single-threaded, single-service non-concurrent server.
Most of the answers correctly noted the need for multiplexing and recognized that a concurrent server already provided it. A few answers had the correct reasoning but chose the wrong servers. A couple of answers tried to reason that state-management issues favored non-concurrent servers, but the arguments didn't seem too convincing.
One important requirement for successful multi-protocol servers is being able to separate the service-providing part from the protocol I-O part. If the two parts couldn't be separated, then the service would have to be re-implemented for each protocol, which defeats the purpose of having a multi-protocol server.
Inetd is a multi-service server (which also supports multiple protocols). It is structured as a boss, which is inetd itself, and a varing set of workers, each of which is a server handling a client. The interaction between Inetd and its worker servers is entierly through the three standard Unix I-O channels std-in, std-out, and std-err; that is, each worker server is designed to read and write those three chanels. It is inetd's responsibility to map the incoming Internet connections to a worker's standard I-O channels.
The model that remaps network connections to standard I-O channels is an important one for multi-protocol servers because it simple, clean, and general method for decoupling protocol I-O and the service itself.
There were one or two correct answers for this one. Many answers indicated that inetd was also a multi-protocol server, which was half the answer, but didn't indicate why that was interesting.
Because your protocol already implements reliability, the tunneling protocol need not provide it, and UDP would be apropriate choice. Even through it provides reliability itself, there a few reasons why TCP is not as good a choice as UDP.
First, because the higher-level protocol is reliable, TCP's reliability represents an expensive overhead that isn't needed; using UDP eliminates the overhead. But, you may be thinking to yourself, because TCP's reliable, then the higher-level protocol won't have to worry about anything, which brings us to the second reason: nested reliability protocols often interfere with each other. Most reliable protocols rely on some form of time-out and retransmit. While TCP is reliable, it is slow when being so (in the presence of packet loss). This slowness could, in turn, trigger the higher-level protocol's timeout and retransmit mechanisms, and it isn't too hard to imagine how an echoing effect can now bounce back and forth between the tunneling and tunneled protocols.
Many of the wrong answers appeared to be based on a misreading, assuming that the tunneled protocol was not itself reliable. In such a case using TCP is the correct answer; but, if the tunneled protocol is already reliable, then UDP is the way to go.
Applications that work through the Internet, such as mail delivery and DNS, represent security risks because they require traffic through a firewall in both directions. If such applications are spread out over a network, it becomes because there are multiple targets to attack, it's harder to secure each target, and it's harder to deal with the results of a successful attack.
Running a single copy of the application as an application-level gateway solves all these problems. By having only one copy, there is only one place where the attack may occur, and all attention on preventing an attack can be focused on one place. By isolating the host - in a DMZ, for example - the consiquence of a successful attack can be minimized.
This question was straight from the book (Section 19.8, page 245). A lot of answers tried to include a gateway's translation functions, which has some value in firewalls and spam filters, for example.
This page last modified on 9 May 2004.