Re: [9fans] Re: some Plan9 related ideas

[Uriel <uriell@binarydream.org>]

I was reading old archives, and I'm probably a bit dense; but what is
the reason to use the same tag for the three messages?

Wouldn't that be able to break a server that expected tags not to be
reused until the corresponding Rmessage had been sent? Or I'm probably
misunderstanding how the tag is used...

And what are the kernel changes nemo mentioned?

I have to add that this is a big deal for connections with latencies 
of >100ms. 

I was also thinking of some library that would make it easier to add
fcp(1)-like functionality to other apps, but that is not very general.

uriel

On Tue, Aug 30, 2005 at 01:46:40PM -0400, Russ Cox wrote:
> I don't know whether the change is worth doing, but
> here is a simple way to do it.  Define that a client may
> send more than one message with the same tag, and
> in that case servers must process those messages
> sequentially.  This is not very hard to implement on the
> server side, and the single-threaded servers needn't
> change at all.
> 
> Now to implement the so-called batch RPC, you just
> send three messages in a row with the same tag:
> 
>   tag Topen fid name mode
>   tag Twrite fid offset data
>   tag Tclunk fid
> 
> and then wait for three responses to come back.
> Since the client has complete control over the choice of
> tags and fids, there is no information in the R messages
> needed to generate the T messages.  The various results
> are completely distinguishable: on success you get
> back Ropen, Rwrite, Rclunk,  If the Topen fails, then you'll
> get back Rerror, Rerror (unknown fid), Rclunk.  If the Twrite
> fails you'll get Ropen, Rerror, Rclunk.
> 
> I have no idea whether this is worth doing.  My gut reaction
> is no, but maybe someone will prove me wrong.  My point
> is only that the protocol need hardly change.
> 
> Russ