Re: [Tapioca-devel] Ideas on the plumbing protocol

[Eric L. G. <er...@ba...>]

On Sat, 7 Jul 2001, Richard Fish wrote:
> On Fri, 6 Jul 2001, Eric Lee Green wrote:
> > 1. The actual low level network communication widget just
> >  sends stdin/stdout across the network, encrypting it via a stream cipher
> > (I suggest RC4, since OpenSSL does RC4 just fine).
> >
> > 2. At each end, there is a multiplexor for the multiple inputs
> > (stdout, stderr, various named pipes), and a de-multiplexor that
> > takes a stream coming from the other end and turns it back into the
> > multiple streams, sending those streams wherever.
>
> Sounds good.  Saves us from having to open a second socket for
> stderr/control.  And since we are talking about some kind of protocol
> between the MP and DMP, that can also incorporate a close command that
> causes a particular channel to close.

My biggest thing is keeping anything that actually touches the actual
network socket as simple as possible, so there's less chance of buffer
overflows, memory leaks (since this thing is long-running and persistent)
and such. When I got into it, I saw that I was going to need something
that was multi-threaded in order to handle the write part of
de-multiplexing (writers can block if the program at the other end of the
pipe is not ready for input yet, and that was not acceptable). I did *not*
want the thing sucking on the socket to be multi-threaded (at least not on
Unix), for reliability reasons. If they had to be seperate processes, I
figured they might as well be separate programs too.

I've started layout out the class heirarchy in .h files and thinking about
how it all fits together, and yes, I've got a CLOSE command for i/o
channels in there, and some other stuff. I'm still laying out the packet
format, but I think I have one that will allow the actual network pieces
to be extremely simple and reliable and easy to audit for security, while
allowing the seperate mux/demux that actually handles connections to do
fancy stuff like propogate selected environment variables, run simple
'recipes' telling it what pipes to open and what commands to start up with
each of them (sort of like scripts, but much simpler so that an
interpreter is easy to write for them for Windows), etc.

> > than writing from scratch. Sigh. Oh well, time to crack the Stroustrup.
>
> Yes, Stroustrup (Special Edition) is now my bible.  I discovered that C++
> has changed a bit in the last few years.  Either that, or my knowledge of
> C++ wasn't quite correct to begin with!
>
> For example, the C declaration "NULL" is now passe.  You initialize
> pointers with "0", not NULL.  It's a hard habit for me to break.
>
> Namespaces are also new, and something I haven't used.

Yeah. I made it to page 135 of Stroustrup V3 today. I think part of the
deal is that we programmed in Python for 2 years, and thus know more about
object-oriented programming than the last time you programmed in C++. You
probably treated it a lot like "C" with some extra syntactic sugar last
time, though you're right, namespaces are new, they weren't in Stroustrup
version 2.  I'm impressed with some of the STL classes, like hash tables,
growable vectors, real strings (as vs. arrays of chars) that aren't
succeptible to buffer overflows when you concatenate them together, etc. I
smell some cross-breeding with Java here... Stroustrup V2 didn't have this
fancy stuff.

-- 
Eric Lee Green                             mailto:er...@ba...
               BadTux: http://www.badtux.org
  GnuPG public key at http://badtux.org/eric/eric.gpg