RFC 928 (rfc928) - Page 2 of 21
Introduction to proposed DoD standard H-FP
Alternative Format: Original Text Document
RFC 928 December 1984
Introduction to H-FP
NCP and do it outboard: the only thing that really matters in the
Host is associating sockets with processes, and if we had common
implementations of all the bit-diddling stuff in the IMPs, we
wouldn't have disputes over the interpretation of the spec and we'd
also save a lot of Host CPU cycles!"
As far as the author knows, that incident was the beginning of what
came to be called "Network Front-Ends" and, more recently, "Outboard
Processing Environments." (The name change, by the way, was
motivated by a desire to prevent further confusion between NETWORK
Front Ends--always conceived of as distributed processing mechanisms
for the offloading of intercomputer networking protocols from
Hosts--and traditional communications front-ends, which have no
connotation of bearing protocol interpreters invokable by Host-side
programs.) At least, the idea was original to him and he later was a
principal designer and the primary author of the first Host-Front End
Protocol. So, on the one hand, the present document might be marred
for some readers by undertones of parental pride, but on the other
hand, if you like primary sources....
The evolution of the outboard processing idea has been dealt with
elsewhere [1]. For present purposes, it should suffice to observe
that some half-a-dozen implementors of "NFE's" of various sorts are
known to the author to have met with success. The topic of why use
an explicit protocol in the first place (as opposed to emulating a
device, or devices, already known to the Host/operating system)
deserves a word or two here, however. ([2] deals with it in more
general terms.) The crucial consideration is that in the general
case you wind up "not doing real networking" if you attach a Host to
a network by known device emulation, where real networking is taken
to mean what has been called "resource sharing" in the ARPANET
literature, and what appears to be dubbed "open system
interconnection" in the ISO literature: Operating systems' built-in
assumptions about known devices--whether terminals, terminal
controllers, or RJE stations--tend to get in the way of the sort of
process-process and eventually procedure-procedure communications
that serve as the basis for applications more interesting than simple
remote login. To those unfamiliar with the outboard processing
approach, the premise that the way to attach is via an explicit
protocol may be difficult to accept, but to those who have done it,
it makes almost perfect sense.
To those, by the way, who have worked in intercomputer networking
from the perspective of inboard (Host-side) implementations of
protocol suites, the outboard processing idea often seems to lead to
less than optimal results, especially as to maximizing throughput.
And it is difficult to argue that if a given Host were well and truly
Padlipsky