Messages in this thread | | | Subject | Re: [PATCH] AFS filesystem for Linux (2/2) | Date | Fri, 04 Oct 2002 18:29:42 +0100 | From | 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |