Re: [PATCH] AFS filesystem for Linux (2/2)

[David Howells]

> The 'socket protocol' stuff already copes with UDP w/ congestion
> control + TCP. It will eventually do SCTP and IPv6 when we get down to
> it all.
> Fitting UDP w/ sequencing+acking as an extra protocol should be
> possible, and in fact support for sequencing is needed anyway for
> the security code in RPCSEC_GSS.

Interesting idea. What do you mean by an extra protocol exactly? An extra
IPPROTO_xxxx option as might be passed to socket()?

My RxRPC implementation currently does all the incoming message management and
routing in process context in a worker thread.

The following details have to be resolved wherever it is done:

 (*) RxRPC calls (operations) may be aborted or rejected.

 (*) RxRPC packets have to be ACK'd/NAK'd and maybe resent. ACK packets may
     ACK or NAK multiple data packets.

 (*) RxRPC packets have their own "connection number" and "channel number" and
     "call number" spaces on top UDP port numbers, thus require multi-tier
     routing.

 (*) An operation (a "call") may get challenged or may be challenged for
     security details in the middle of transmission or reception.

 (*) RxRPC packets may get merged together and placed into one UDP
     packet. They then have to be split and processed individually upon
     reception.

I don't see that there should be a problem with the first three (after all,
TCP does all of them). The fourth may be the trickiest, but that may also be
the one NFSv4 has to deal with.

> The nice thing about the SunRPC code is that it provides a generic
> engine for sending and receiving messages asynchronously. For the
> client, the SunRPC specific stuff is almost all in
> net/sunrpc/clnt.c. If you write a replacement for that in order to
> deal with the RxRPC quirks, you should still be able to make use of
> rpciod and the socket + auth code.

It's not entirely clear as to how to use it.

> Ditto for the server stuff: nobody forces you to use svc_process to
> interpret the RPC headers.
> 
>      > Furthermore, RxRPC allows for big binary blobs to be
>      > interpolated in the middle of packets (though if I understand
>      > it correctly it effectively encodes them as an XDR octet array
>      > of sorts).
> 
> The RPC layer doesn't worry too much about the contents of the data
> you send. We're already interpolating pages into our RPC messages...

That's useful. I also pass pages to my rxrpc receive data routine to copy into
directly from skbuffs, but I don't see that being a problem.

David