> > 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));
>>>>> " " == David Howells <[email protected]> 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