get complicated on some systems for an inboard implementation.
However, fortunately for our purposes,
Multics' native mechanisms lend themselves readily to integration; an
awareness of the inboard issues will be useful even if in response to
a connection attempt on the Telnet WKS, the (Server) Host is
obligated to associate the connection (the actual logic is somewhat
more complex under the ARPANET Host-Host Protocol, which employs
paired simplex connections) with a process that is prepared to
translate between Telnet and native mode representations and
otherwise "look like" a local user process--that is, in particular
the connection becomes an I/O source/sink to the native command
processor on time-sharing systems. As indicated, process creation is
taken care of in Multics by having the Answering Service process
listen on the WKS. Because the Answering Service is in some sense
RFC928 December 1984
Introduction to H-FP
just another Multics process, it too does user I/O through the normal
system mechanisms. So while for local terminals the user I/O streams
are attached through a module called "ttydim" (where "dim" stands for
"device interface module"), NVTs are attached through a functionally
equivalent and identically invoked module called "nttydim" (the
Answering Service knows which DIM to use based on the symbolic
designator of the "line" on which it received the interrupt, as it
happens).
[The notion of "attaching" the streams bears a bit more explanation:
Attach is a primitive of the Multics generic I/O mechanism which
associates a stream name and a particular DIM (or I/O system
interface module in later terminology); the other I/O primitives
(read, write, etc.) are invoked with the stream name as a parameter
and an I/O "switch" causes the entry point corresponding to the
primitive to be invoked in whichever DIM the stream is currently
attached to. So a Server Telnet process starts life attached
through nttydim to a particular network connection, while a local
process starts life attached through ttydim to a particular physical
line, and both processes proceed indistinguishably (viewed from
outside the I/O switch, anyway).]
The pre-existing orderliness that makes things easy on Multics does
not, unfortunately, appear in all operating systems. Indeed,
delicate choices occasionally have to be made as to WHICH native
terminal to map to on systems that don't do generic I/O in native
mode, and it is likely that for some systems the particular mapping
to bring into play in Server Telnet might be determined by the
particular application program invoked. This issue can become very
touchy when the application "expects" a "data entry terminal", say.
The Server Telnet for such a system would naturally attempt to
negotiate the "DET" option with the corresponding User Telnet. But
the user might be at a physical terminal that isn't a member of the
DET class, so that User Telnet must either refuse to negotiate the
option or--and we would recommend this alternative strongly, as it
seems to be within the "spirit" of the protocol--offer some sort of
simulation, however crude, of the behavior of a DET. Also,
something sensible has to be done on systems where there is no clear
analog of the command processor expected to be managing the Server
process. (Say, when a "menu" of applications is always displayed on
an available terminal in native mode.)
A final Telnet integration issue (although other points could be
noted, we're not pretending to be exhaustive and this should be
enough to "give the flavor"): The Telnet Interrupt Process generic
function calls for particularly careful integration. Here, the
intent of the function is to virtualize what is called the "quit
RFC928 December 1984
Introduction to H-FP
button" on some systems. That is, the user wants the system to
interrupt his process (which may, for example, be in a loop) and get
back to the command processor (or "the system" itself). On native
character-at-a-time systems, the native mechanism is usually the
entering of a particular "control character"; on native
line-at-a-time systems, the native mechanism is usually the striking
of the "ATTN" or Interrupt button or the "Break" key (sometimes more
than once, to distinguish it from a communication to the executing
program). But the native mechanisms typically involve interrupt time
code, and Server Telnet typically wouldn't be executing at that
level, so the solution (omitting the intricacies of the interaction
with the NCP or the H-FP PI, which also get into the act) would be to
make use of--in the Multics case--a pre-existing INTRAprocess signal,
or to add such a mechanism (unless the architecture chosen has a
Server Telnet Daemon of some sort, in which case an INTERprocess
signal would be needed).
The extension of the foregoing to an outboard Server Telnet may not
be obvious, but we won't expend a great deal of time on it here.
Even if "the protocol" is being handled in an OPE, the Host-side
software must be able to associate an H-FP connection with the
command language interpreter of a user process and to respond
appropriately to an H-FP Signal command if it arrives, and the OPE
must know not only the desired character set but also the local
equivalents of Erase and Kill, at the minimum.
We'll skip FTP integration, on the grounds that this note is already
too lengthy, except to mention that in the OUTBOARD case it's still
going to be necessary to convey the name of the appropriate file and
directory to/from some appropriate Host-side code. (Similar problems
must be dealt with for outboard handling of "mail" if it's not part
of FTP.)
One other "integration" issue, which has been hinted at earlier and
about which not much can be said beyond some general guidelines: The
"top edge" of a Host-side H-FP protocol interpreter (i.e., the Host
user program interface, for
Hosts that are "doing real networking" rather than just using the OPE
to get at User Telnet and/or FTP and to offer Server Telnet and/or
FTP [and maybe "mail"], presumably in the "scenario-driven" fashion
sketched earlier) MUST BE APPROPRIATE TO THE HOST. In other words,
on Multics, where "everything" is closed subroutines, there would
presumably be a closed subroutine interface with event channels for
reads, pointers to buffers, and all that sort of thing, but on some
other style of operating system, the interface to the H-FP PI might
turn out to be "all" interprocess communication, or to "look like" a
RFC928 December 1984
Introduction to H-FP
device of some special class, or "all" system
calls/JSYSs/EOTs/Whatevers. We can't be much more specific, but we'd
be remiss to convey any impression that H-FP is a "free lunch". As
noted, an H-FP PI requires the same kind of integration as a generic
NCP--it's just smaller, and serves as insulation against changes (in
the offloaded protocols in general, or in the proximate comm subnet
in particular).
References
(References [1]-[3] will be available in M. A. Padlipsky's "The
Elements of Networking Style", Prentice Hall, 1985.)
[1] Padlipsky, M. A., "The Host-Front End Protocol Approach", MTR
3996, Vol. III, MITRE Corp., 1980.
[2] Padlipsky, M. A., "The Elements of Networking Style", M81-41,
MITRE Corp., 1981.
[3] Padlipsky, M. A., "A Perspective on the ARPANET Reference Model",
M82-47, MITRE Corp., 1982.
[4] Bailey, G., "Network Access Protocol", S-216,718, National
Security Agency Central Security Service, 1982.
[5] Day, J. D., G. R. Grossman, and R. H. Howe, "WWMCCS Host to Front
End Protocol", 78012.C-INFE.14, Digital Technology Incorporated,
1979.