rfc928.txt

RFC 相关的技术文档

   would follow the same partitioning even on Multics, much less on some
   other operating system.  However, with NCP, because there is a
   distinguished "control link" over which Host-Host commands are sent
   in the NCP's Host-Host protocol, the Multics IMP-Host Protocol PI
   relegates such traffic to a Network Daemon process, which naturally
   is a key element in the architecture.  (Things would be more
   efficient, though, if there weren't a separate Daemon, because other
   processes then have to get involved with interprocess communication


Padlipsky                                                      [Page 16]



RFC 928                                                    December 1984
Introduction to H-FP


   to it; H-FP PI designers take note.)  To avoid traversing the Daemon
   for all traffic, though, normal reads and writes (i.e., noncontrol
   link traffic) are done by the appropriate user process.  By virtue of
   the distributed supervisor approach, then, there is a supervisor call
   interface to "the NCP" available to procedures (programs) within user
   processes. (The Daemon process uses the same interface, but by virtue
   of its ID has the ability to exercise certain privileged primitives
   as well.)

   If a native process (perhaps one meaning to do "User Telnet", but not
   limited to that) wanted to use the network, it would call the open
   primitive of "the NCP", do reads and writes, and so on.  An
   interesting point has to do with just how this interface works:  The
   reads are inherently asynchronous; that is, you don't know just when
   the data from the net are going to be available.  In Multics, there's
   an "event" mechanism that's used in the NCP interface that allows the
   calling process to decide whether or not it will go blocked waiting
   for input when it reads the net (it might want to stay active in
   order to keep outputting, but need to be prepared for input as well),
   so asynchrony can be dealt with.  In the version of Unix (tm) on
   which an early NFE was based, however, native I/O was always
   synchronous; so in order to deal with both input from the terminal
   and input from the net, that system's User Telnet had to consist of
   two processes (which is not very efficient of system resources).
   Similar considerations might apply to other operating systems
   integrating H-FP; native I/O and interprocess communication
   disciplines have to be taken into account in designing.  (Nor can one
   simply posit a brand new approach for "the network", because Telnet
   will prove to rely even more heavily on native mode assumptions.)

   The other aspect of NCP integration which we should at least touch
   on--especially because process-level protocols make no sense without
   it--is how "Well-Known Sockets" (WKSs) work. In broad terms, on
   Multics the Network Daemon initially "owns" all sockets.  For
   Well-Known Sockets, where a particular process-level protocol will be
   in effect after a successful connection to a given WKS, code is added
   to the Answering Service to call upon the NCP at system
   initialization time to be the process "listening" on the WKSs.  (This
   is a consequence of the fact that the Answering Service is/was the
   only Multics process which can create processes; strategies on other
   systems would differ according to their native process creation
   disciplines.)  How to get the "right kind of process" will be
   sketched in the discussions of the process level protocols, but the
   significant notion for now is that typically SOME sort of prior
   arrangement would be done by any networked Host to associate the
   right kind of process with a WKS.



Padlipsky                                                      [Page 17]



RFC 928                                                    December 1984
Introduction to H-FP


   Now, we don't expect that the foregoing will enable even the world's
   greatest system jock to go out and design the integration of an H-FP
   PI for a system that had never been networked (in the ARPANET style
   of networking) before. But we propose to stop there and turn to some
   comments on process level protocols, for two reasons: In the first
   place, it would take us much too far afield to go into significantly
   greater detail; and in the second place, because of the functional
   equivalence of H-FP and NCP combined with the number of operating
   systems which have integrated NCP and, for that matter, TCP/IP, which
   are also functionally equivalent to H-FP (used for offloading L II
   and L I), models are available in the ARPANET community and concerned
   H-FP PI implementors can follow them.

   Turning to Telnet integration, and returning to Multics as an
   example, we note that "User Telnet" is straightforward. "All you
   need" (for small values of "all") from an INBOARD User Telnet is a
   command that gives the user some sort of interface, converts between
   the native Multics character set and terminal discipline and the
   Network Virtual Terminal equivalents (and as Multics is very generic
   when it comes to I/O, that's not hard), and writes and reads "the
   net" (more accurately, calls upon the Host-Host protocol PI--or upon
   the H-FP PI to get at the H-HP--appropriately).  (One point that's
   not obvious:  make the Well-Known Socket "on the other side" a
   parameter, defaulting to the Telnet WKS, because you'll want to use
   the same command to get at other process-level protocols.)  If
   there's an OPE in play which offloads User Telnet, however, things
   can be even simpler: the inboard command just reads and writes the
   terminal and lets the OUTBOARD User Telnet PI handle the conversion
   to and from the Virtual Terminal form (presumably, from and to the
   desired local form).

   When it comes to the incoming ("Server") aspects of Telnet, life can
   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


Padlipsky                                                      [Page 18]



RFC 928                                                    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


Padlipsky                                                      [Page 19]



RFC 928                                                    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


Padlipsky                                                      [Page 20]



RFC 928                                                    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.





















Padlipsky                                                      [Page 21]