[NCLUG] I was hacked!

[John L. Bass]

Hi Mike,

Portmapper is/was the correct design to provide connection services for hundreds
of cross architecture RPC/XDR (RFC1831/RFC1832) applications. The WKS port
approach (common practice for more than 5 years before RPC's) would have been
a disaster to administer, even with an inetd to front end the WKS ports. It
would have been crazy to assign IP ports to a large number of RPC application
servers. Sun's approach of hiding registered program numbers behind portmapper
was absolutely the correct thing to do. The IP port space is 16 bits, the
registered program space is 32 bits. The 14 bits or so available for WKS port
assignments is not enough to cover the possible demand for RPC applications
developers over the technology lifetime.  Thus, your position, modified as below,
is even further from the mark.

I took the comment as an unjustified (clueless) slam on the Sun developer that
developed Portmapper. At the time RPC's were proposed to be the core foundation
for all distributed multiprocessing, and a lot of energy was put into making
the interfaces work across all architectures and bit formats - and a large group
of vested interest parties worked thru the standards processes.  There are many
applications that were split between workstations and big iron computational
workhorses using RPC's (and XDR).  There are many still doing RPC/XDR distributed
applications development today, with XDR still the prefered way of handling cross
architecture data transparently.

This idea of loosely coupled multiprocessing was largely dismissed by non-Sun
UNIX companies who started building shared memory "multi-processor" machines.
This made made RPC's a "less interesting technology" than it might have been.
With people again building loosely coupled multiprocessor systems (AKA clusters)
RPC's (with XDR) are still be an interesting part of the cluster solution to
integrate older applications and architectures into clusters (mixing i86 with
PA Risc, Mips, PPC etc).

Anyway, not a flame war - just a historical correction for those clueless
about RPC/XDR and real world uses for architecture independent multi-processing.
While home Linux machines may not need portmapper for other than NFS/NIS,
RPC/XDR is a valuable tecnology resource for many companies that have to
support mixed architecture missions - and Portmapper is a critical component
of that service.

John

	> By "inetd" I presumed that Mike meant "well-known service" ports.
	> Inetd doesn't really do anything except make writing daemons easier...
	> Because portmapper uses a WKS port, it's present form is unlikely to
	> pre-date them.  ;-)

	 Yes, that's what I meant. I had to insert "and their ilk" in there because
	I knew it wasn't the perfect analogy and my brain was fogged (still is)

On Thu, Jan 04, 2001 at 02:30:39PM -0700, Mike Loseke wrote:
> Yep, if you aren't running Sun(tm) services like NFS or NIS then you
>shouldn't need portmapper at all. It's basically someone at Sun's weird
>idea of getting around inetd (and it's ilk) by re-implementing it using
>registered numbers that aren't ports. :-P