>>>>> " " == David Howells <dhowells@cambridge.redhat.com> writes:
> There appears to be more to it than that. RxRPC has sequencing
> and ACKing windows and things that I don't think SUNRPC has
> (basically it tries to do some of TCP itself). I've attached
> the struct definitions for the RxRPC header and the ACK packet
> body from my RxRPC implementation for your reference.
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.
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.
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...
Cheers,
Trond
-
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/
This archive was generated by hypermail 2b29 : Mon Oct 07 2002 - 22:00:46 EST