[DotGNU]VRS/SEE/Goldwater meeting results

[Stephen Compall]

Here's an unofficial summary of what went down. "Full" logs at 
<http://csserver.evansville.edu/~sc87/dotgnu/20021015-vrs-meet.log>

BTW, my apologies to the ObjC people, I meant to say FORTRAN or COBOL 
there...but really people, get some exceptions! ;)

--
Stephen Compall
Also known as S11001001
DotGNU `Contributor' -- http://dotgnu.org

If you'll think back a few years, the term "pirate" was formerly
applied to publishers that didn't pay the author.  But now it's been
turned completely around. It's now applied to members of the public
who escape from the control of the publisher. It's being used to
convince people that only a nasty enemy of the people would ever do
this forbidden copying. It says that "sharing with your neighbor is
the moral equivalent of attacking a ship."
        -- RMS, "Copyright and Globalization in the Age of Computer
                Networks"

Summary by Stephen Compall

Tuesday, October 15, 2002
Started logging at 20:48 UTC

THE CAST
********

alias: Ian Fung (VRS)
erica: Eric Altendorf (VRS)
ChrisS: Chris Smith (Goldwater/VRS)
S11001001: Stephen Compall (Network SEE)

DEPENDENCIES
************
Correct me if I'm wrong, but here are the programs discussed:

Goldwater: A multiprocess server handler that handles requests over
various network transports, and allows these processes to communicate
with each other as well.

VRS: A server designed to cleanly distribute services over peer
servers, that appear to the outside world as a "pseudoserver".

SEE: A collection of servers that handle various network transports,
publish webservices--and their stubs--to the outside world, as well as
offer auth to these services, which are kept persistent.

Read these for more background

Goldwater white paper; Inside Goldwater
<http://www.nfluid.com/gw.html>
<http://www.nfluid.com/igw.html>

Virtual Remote Server design
<http://www.nongnu.org/VRS/architecture.html>

The Network SEE informal design document, currently 2.0.1
<http://csserver.evansville.edu/~sc87/see-arch.txt>

WHAT SHALL WE TALK ABOUT?
*************************

how can GW make the SEE simpler?
VRS/SEE/GW comparison
what's the architecture for pluggable webservices?
how does network/plugin independence work in VRS/SEE/GW?

WHAT DID THEY SAY?
******************

First, S11 offers his idea for how requests get through the SEE to a
service:

 1. when a service is first requested, it starts up the VM as a
    separate process.

 2. after that, every time there is a new connection, the service will
    receive this on stdin, in a simple xml block: connectionID (for
    identity purposes only), readFilename, writeFilename. the service
    can use the connectionID to get identity information, but that's
    not defined right now, because there is no API from auth yet
    AFAIK. connectionID *can* be used as a session ID, but that is not
    imposed on the service

 3. the service, which continues to run, gets these XML blocks, and
    opens the first file for reading, and the second file for
    writing. These files are really FIFOs (where named pipes are
    supported in Windows...TODO research Windows named pipes)

 4. the XML connection notifications in 2 are just that: the service
    and the client share raw data, except what see*port adds and
    see*user takes away

 5. the data of the service is passed raw through the FIFOs, through
    see*port, which implements the network transport, back to the
    other machine, through see*user, and another FIFO set, and to the
    stub

erica said here that having a separate process for the VM would not
bring a significant modularity advantage, other than cross-language
ability, which could be easily solved w/ an IPC adaptor to start up
those special-language VMs.

S11 said that with this model, all you have to do to get PhpGroupWare
to work in this SEE model is write a wrapper around the php executable
to multiplex it (that is, accept multiple concurrent connections, and
stay persistent), where the wrapper embeds PHP and runs the script it
has loaded up for every request. 

erica says would it be fair to say that your proposal is roughly
similar to CGI? S11: This is somewhere between CGI and servlets:
whereas CGI starts up a VM for every request & every service, and
servlets only start 1 VM to serve all requests and services, this
model starts up a VM per service, but not per request.

SamB, who is lurking, asks why phpwrapper will not accept SOAP, so we
change it: it will accept SOAP, but just like any other HTTP POST: the
PHP app will throw an error if not expecting SOAP.

ChrisS says this model is just like the VRS model: VRS has network
servers, which are like see*ports.

 1. The networkServer decodes a message-queue name and data to send
    down that queue, which represents a request.

 2. The ServiceManager is then passed the webservice name to validate
    that it exists.  Assuming it is the VM is passed the name of the
    webservice to invoke and the request data.

S11 starts to have issues about this whole request/return thing. He
needs room to breathe on the network!

ChrisS: There's only a single request/return per connection as far as
HTTP is concerned, because that's what that protocol does.  SOAP
however is asynchronous (unless its over HTTP) so in the SOAP case
not.

**********************************************************************
At this point, S11001001 is installing the latest build of mozilla,
and it eats his poor AMD K6-2 533MHz, so he accidently clicks his
shaky mouse on the close button on X-Chat. At this time, ChrisS,
erica, and alias lay out the rest of the SEE design, VRS design, and
solve all GW issues, and set about implementing them. In fact, all the
important decisions about architecture are made in these few
minutes. Unfortunately, the rest of us will never know these
incredible ideas, so we have to reimplement. The productive period
ends when S11 returns....
**********************************************************************

ChrisS: so the VRS and SEE are not too different. The webservice
execution bit of VRS can be reduced to SEE.

alias mentions the distributed filesystem in VRS, wanting to use CODA
instead of the homegrown VDFS

S11 asks about implementing the GW IPC API for new languages. In
network-SEE v2, a language must be able to reach an XML parser and be
able to read/write files. If someone wants to use a new language to
write a GWServer, how hard is it?

ChrisS: Hmm. The in and out buffers are memory chunks. (describes GW
API)

You have the concept of FIFOs (pipes etc) in SEE. If we just consider
them generically as 'queues' for a moment and give each one a name.
You start goldwater up and it 'boots' the servers that you have told
it about.  Such servers would be things like the networkListeners, the
Resource Manager, the CM, the VM blaaa.  It then assigns a request
queue and a reply queue to each one.  Each GWService (like RM, VM etc)
has defined entry points, Goldwater stores these entry points in a
table along with the request queue name of the queue that gets you
there.  This table is in shared memory, so that all processes within
goldwater can instantly find out the name of the queue of the 'entry
point' it needs to send data to.  And that's kind of it really, other
than Goldwater monitors all processes in the application and restarts
anything that dies etc.

When something wants to send data to say the VM, it needs to know the
entry point.  Thats the name that you pass in the gw_svc_call.
Goldwater internally looks this name up in the table, and sends the
request data to the desired queue.

erica asks why the different modules that make up the VRS server have
to be different processes. Why can't they be threads? ChrisS says :the
Resource Manager is common in function to all network port managers,
so you should abstract it and threads take down everything if one
segfaults, and they can screw with each other's data. erica says
that's not a problem if the VM is stable. ChrisS points out that there
are multiple networkServers (port managers is the new term
now).... How does GW kill a runaway thread?  S11 claims that it can be
done, technically, in GNU/Linux, but not much else.

erica says "Hmmm.  Ok.  I guess I'm just coming from a background of
enterprise java, where we ran the EJB container and servlet container
in the same process, with many many threads serving many many requests
simulatneously, and I never had any problems with it." ChrisS says the
multiple process model is just a different architecture. S11: it's
alot like the monolithic/microkernel arguments. (BTW, the Network SEE
arch v2 is inspired by the Hurd :)

ChrisS addresses S11's question about running services handling
multiple requests: GW uses SysV message queues to send data to the
services. When this happens, the service wakes up to read the data and
send a response. Also, GW creates multiple instances of the service to
handle multiple concurrent requests (much like Apache).

   ChrisS: Now of course these IPC features are not available on
   windoze, so some alternative may need to be found - but whatever
   happens can be hidden under the hood.  The GW API does not have to
   changed.

   S11: just have them eat CPU: you can only do one thing on any given
   WindowsTM machine anyway

   erica: :-)

S11 finally brings up his fears about request/reply, where Net-SEEv2
allows any kind of net comm allowed by the principle of network
communication. SEE implements this through a "fast proxy", which is
the see*port.

ChrisS: the following bits are the same *functionally*:
1. see*port / network port manager *
2. VM - webservice execution engine
3. web service registration thingy (Service Manager in the VRS)

erica and ChrisS talk about the status of GW API for different
languages. C is "dead simple", C# is mostly pInvoked up, erica really
wants to get coding!

S11 offers a description of a model for registering webservices: it's
based on URL paths. The path is the identifier used externally and
internally, and you create a concrete directory structure to match the
path, sticking portable exes (or symlink to) along with stubs (same)
in the directory. VM registration works by symlinking/copying a VM in,
under a standard name, like "clr" so they can resolve on client and
server, and a clr.binfmt (e.g.) that describes the bytecodes the VM
accepts.

erica has problems building GW.

see SUMMARY

erica gets info about what to do to implement the Service Manager, and
ChrisS leaves.

SUMMARY
*******

ChrisS: What do you think we've achieved today?

erica: an agreement on the role that GW plays in the VRS architecture.
erica: an understanding that  VRS and SEE do seem mostly compatible.
 (ChrisS: They do don't they.  S11 is coming from a different angle to us.)