Return-Path: <braam_at_cs.cmu.edu>
Received: from localhost (braam_at_localhost)
	by carissimi.coda.cs.cmu.edu (8.8.7/8.8.7) with SMTP id IAA01665;
	Thu, 30 Jul 1998 08:51:22 -0400
X-Authentication-Warning: carissimi.coda.cs.cmu.edu: braam owned process doing -bs
Date: Thu, 30 Jul 1998 08:51:22 -0400 (EDT)
From: "Peter J. Braam" <braam_at_cs.cmu.edu>
X-Sender: braam_at_carissimi.coda.cs.cmu.edu
To: Stewart Allen <stewart_at_neuron.com>
cc: linux-coda_at_cs.cmu.edu
Subject: Re: RPC2:  what group at CMU maintains it ?
In-Reply-To: <Pine.LNX.3.96.980730015322.5210B-100000_at_flex.neuron.com>
Message-ID: <Pine.LNX.3.96.980730080702.1662A-100000_at_carissimi.coda.cs.cmu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Stewart,

There are some slides on our WWW site with an overview.  The overview
depicts somewhat more clearly what the protocol layering is - in the
absence of multi- and multicast rpcs (which complicate things of course). 
The later chapters in the manual also describe some of this.  I am working
on a longer protocol description and hopefully I will have time to
reorganize some of the messy C code. 

RPC2 is very stable - we run 15 fileservers and several dozen clients of
it, and while there are problems they are very rare (practically all Coda
development is done in Coda, all my email arrives in Coda etc).   The
implementation is really one of a research project not reflecting or
respecting the protocol.  I and Robert discussed this at length and in
then we understood that RPC2 even with multicast and multi rpc's can be
nicely layered, but probably only for the second implementation.

We have been thinking about a Java implementation since we have a few
programs for which this would be very useful.  However, a full
implementation is not necessary in the first instance. Let me clarify
that.  Multi rpc's and multicast rpcs are really for the
fileserver/cache manager only and even then just for optimizations.
Reliability of transmission is not an issue for some of the tools which
use RPC2, since they run over Unix domain sockets.  Side effects are
needed for some, not for others.

Finally it is probably easier to modify the stub generator we already have
(written in C) to produce Java code than to write a new one in Java.

So if I were to work on this I would first 

1. deal with marshalling packets
2. build a socket listener thread that can wake up a sleeping thread when
a reply arrives
3. build a small client

If you get here, we should talk in detail, since from here onwards the
threading issues become more delicate.

4. build a thread that can accept and process a binding and run
***_ExecuteRequest and use that for a small server.  It is probably
advantageous to have a binding thread running by itself and treat it as a
subsystem. 

5. Code a small TCP based side effect for simple bulk transfers, or port
our UDP based sliding window protocol. 

After this a fuller implementation with retransmission properties and
multi rpcs and multicast would be in place.  Robert and I designed a much
cleaner way to do this with waitobjects that form packets and timers based
on the particular form of the RPC which is being made.

They key thing I'm trying to convey is that a full Java implementation of
RPC2 is a very challenging undertaking, but the good news is that a
partial implementation will be extremely useful to us, for tools like the
advice server, repair, volutil and filcon - all of which could benefit
from some graphical utilities which would be easier constructed with Java.

Good luck, let me know how things are progressing.

- Peter -

On Thu, 30 Jul 1998, Stewart Allen wrote:

> 
>  Peter,
> 
>  Greetings. My name is Stewart Allen. Jim Doyle and I had the pleasure
>  of working together in a previous life where much hacking was done :)
>  I write code because I derive great pleasure from solving problems.
>  Since I write a lot of code, it could be concluded that I have a lot
>  of problems (but that's another story :).
> 
>  Jim brought Coda to my attention a while back and I have been following
>  it peripherially ever since. Though I like what CODA is doing, my first
>  experiences did not meet with much success. It reminds me a lot of DFS.
>  
>  This got me to thinking that I would like to work on CODA, but I
>  basically dropped C/C++ as of Oct. 95 and I code in a Java world.
>  Not because I don't like C/C++, I just find that I get things done
>  about 20 times faster in Java. I'm a very impatient person.
> 
>  Anyway, it started as a technical challenge. I got antsy a couple of
>  nights ago, followed the LWP threads for a few days, had a vision of
>  pure-java Coda, was slightly burnt out on the projects I was working on
>  and decided to begin laying hands on code.
> 
>  Best place to start: the basics. 
> 
>  Long story short: I think this could lead to something cool.
> 
>  Where we stand: I've only got the basics implemented as Jim stated.
>  I am making swift progress, though. I find that the RPC2 docs (which
>  I printed at the expense of a couple of trees) is not doing me as much
>  good as I had hoped; I'm working from the C code/headers in many cases
>  and using the ctest/stest programs against my engine. If you have more
>  high-level details that aren't in the Coda source, please let me know.
> 
>  Where we are going: how stable is the RPC2 source? I anticipate that
>  if I were not getting married in 3 weeks, I would have this thing
>  banged out by the end of August :)
> 
>  -stewart
>