> 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/
This archive was generated by hypermail 2b29 : Mon Oct 07 2002 - 22:00:46 EST