Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S262292AbSJDQME>; Fri, 4 Oct 2002 12:12:04 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S262293AbSJDQME>; Fri, 4 Oct 2002 12:12:04 -0400
Received: from dell-paw-3.cambridge.redhat.com ([195.224.55.237]:41980 "EHLO
	executor.cambridge.redhat.com") by vger.kernel.org with ESMTP
	id <S262292AbSJDQMC>; Fri, 4 Oct 2002 12:12:02 -0400
To: trond.myklebust@fys.uio.no
Cc: David Howells <dhowells@cambridge.redhat.com>,
       Jan Harkes <jaharkes@cs.cmu.edu>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] AFS filesystem for Linux (2/2) 
In-Reply-To: Message from Trond Myklebust <trond.myklebust@fys.uio.no> 
   of "Fri, 04 Oct 2002 18:03:15 +0200." <15773.48067.804268.678391@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 17:17:35 +0100
Message-ID: <27452.1033748255@warthog.cambridge.redhat.com>
From: David Howells <dhowells@cambridge.redhat.com>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 4187
Lines: 95


> > I would if I could, but RxRPC is a sufficiently different
> > protocol to make that impractical:-/
> 
> How badly does it differ? If you are talking only about a couple of
> differences in the RPC headers, then that is something that can easily
> be overcome...

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.

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).

David


struct rxrpc_header
{
	u32	epoch;		/* client boot timestamp */

	u32	cid;		/* connection and channel ID */
#define RXRPC_MAXCALLS		4			/* max active calls per conn */
#define RXRPC_CHANNELMASK	(RXRPC_MAXCALLS-1)	/* mask for channel ID */
#define RXRPC_CIDMASK		(~RXRPC_CHANNELMASK)	/* mask for connection ID */
#define RXRPC_CIDSHIFT		2			/* shift for connection ID */

	u32	callNumber;	/* call ID (0 for connection-level packets) */
#define RXRPC_PROCESS_MAXCALLS	(1<<2)	/* maximum number of active calls per conn (power of 2) */

	u32	seq;		/* sequence number of pkt in call stream */
	u32	serial;		/* serial number of pkt sent to network */

	u8	type;		/* packet type */
#define RXRPC_PACKET_TYPE_DATA		1	/* data */
#define RXRPC_PACKET_TYPE_ACK		2	/* ACK */
#define RXRPC_PACKET_TYPE_BUSY		3	/* call reject */
#define RXRPC_PACKET_TYPE_ABORT		4	/* call/connection abort */
#define RXRPC_PACKET_TYPE_ACKALL	5	/* ACK all outstanding packets on call */
#define RXRPC_PACKET_TYPE_CHALLENGE	6	/* connection security challenge (SRVR->CLNT) */
#define RXRPC_PACKET_TYPE_RESPONSE	7	/* connection secutity response (CLNT->SRVR) */
#define RXRPC_PACKET_TYPE_DEBUG		8	/* debug info request */
#define RXRPC_N_PACKET_TYPES		9	/* number of packet types (incl type 0) */

	u8	flags;		/* packet flags */
#define RXRPC_CLIENT_INITIATED	0x01		/* signifies a packet generated by a client */
#define RXRPC_REQUEST_ACK	0x02		/* request an unconditional ACK of this packet */
#define RXRPC_LAST_PACKET	0x04		/* the last packet from this side for this call */
#define RXRPC_MORE_PACKETS	0x08		/* more packets to come */
#define RXRPC_JUMBO_PACKET	0x20		/* [DATA] this is a jumbo packet */
#define RXRPC_SLOW_START_OK	0x20		/* [ACK] slow start supported */

	u8	userStatus;	/* app-layer defined status */
	u8	securityIndex;	/* security protocol ID */
	u16	_rsvd;		/* reserved (used by kerberos security as cksum) */
	u16	serviceId;	/* service ID */

} __attribute__((packed));


struct rxrpc_ackpacket
{
	u16	bufferSpace;	/* number of packet buffers available */
	u16	maxSkew;	/* diff between serno being ACK'd and highest serial no received */
	u32	firstPacket;	/* sequence no of first ACK'd packet in attached list */
	u32	previousPacket;	/* sequence no of previous packet received */
	u32	serial;		/* serial no of packet that prompted this ACK */

	u8	reason;		/* reason for ACK */
#define RXRPC_ACK_REQUESTED		1	/* ACK was requested on packet */
#define RXRPC_ACK_DUPLICATE		2	/* duplicate packet received */
#define RXRPC_ACK_OUT_OF_SEQUENCE	3	/* out of sequence packet received */
#define RXRPC_ACK_EXCEEDS_WINDOW	4	/* packet received beyond end of ACK window */
#define RXRPC_ACK_NOSPACE		5	/* packet discarded due to lack of buffer space */
#define RXRPC_ACK_PING			6	/* keep alive ACK */
#define RXRPC_ACK_PING_RESPONSE		7	/* response to RXRPC_ACK_PING */
#define RXRPC_ACK_DELAY			8	/* nothing happened since received packet */
#define RXRPC_ACK_IDLE			9	/* ACK due to fully received ACK window */

	u8	nAcks;		/* number of ACKs */
#define RXRPC_MAXACKS	255

	u8	acks[0];	/* list of ACK/NAKs */
#define RXRPC_ACK_TYPE_NACK		0
#define RXRPC_ACK_TYPE_ACK		1

} __attribute__((packed));
-
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/