From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 4 Oct 2002 13:24:14 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 4 Oct 2002 13:24:14 -0400 Received: from dell-paw-3.cambridge.redhat.com ([195.224.55.237]:8190 "EHLO executor.cambridge.redhat.com") by vger.kernel.org with ESMTP id ; Fri, 4 Oct 2002 13:24:09 -0400 To: trond.myklebust@fys.uio.no Cc: David Howells , linux-kernel@vger.kernel.org Subject: Re: [PATCH] AFS filesystem for Linux (2/2) In-Reply-To: Message from Trond Myklebust of "Fri, 04 Oct 2002 19:04:36 +0200." <15773.51748.415514.975150@charged.uio.no> User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Fri, 04 Oct 2002 18:29:42 +0100 Message-ID: <27594.1033752582@warthog.cambridge.redhat.com> From: David Howells Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > 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