Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!hc!lanl!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.unix.questions
Subject: Re: Inter-machine networking on System V
Message-ID: <9637@smoke.BRL.MIL>
Date: 9 Feb 89 21:20:30 GMT
References: <446@thirdi.UUCP> <11181@ulysses.homer.nj.att.com> <9598@smoke.BRL.MIL> <7645@chinet.chi.il.us> <9605@smoke.BRL.MIL> <7666@chinet.chi.il.us>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 24

In article <7666@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes:
>Would you multiplex a single stream in user code otherwise or open
>two virtual circuits?  Does this require a process per stream at the
>remote end?  What about file descriptors > 2?  

As I said, at that point it's getting more complex than I would recommend
dealing with in user mode.  In fact, a lot of this stuff cannot be done
properly without cooperation of the system object allocator (e.g. UNIX
kernel).  In fact, most existing UNIX implementations can't do it right
without really radical kernel modification!  Streams provide the
foundation for doing a good job of this, but the original discussion was
about portable approaches.  Streams are unfortunately not universal, and
OSF seems determined to keep it that way.

User-mode multiplexing is not unheard of; it's how our Blit-descendant
terminals operate in layers mode on 4BSD-based systems.  But context
switch overhead is excessive.

If you have multiple virtual circuit capability, use it.  Somewhere
in the underlying implementation there will very likely be code that
multiplexes the circuits onto a single physical link anyway.  The idea
is to take advantage of the work that somebody else has already invested
in figuring out the optimal way to implement such things, rather than
doing it yourself.