Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #2]

[David Howells <dhowells@redhat.com>]

Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> > message transmission.  You yourself defined RDM to be a datagram service.
> > RxRPC is not, in my opinion, a datagram service, and neither is it a stream
> > service.
> 
> Message is what I should have said.

socket(2) also says datagram...

> Which is just fine, does it need to be one or the other. SOCK_DGRAM an be
> both connection oriented or connectionless.

Is SOCK_DGRAM ever connection-oriented?  Over an AF_INET socket it isn't really
so.  Yes, you can use connect() to point a UDP socket at a particular target,
but you haven't really made a connection.

> > Well, I suggest SOCK_RPC, not SOCK_RXRPC.  There's no particular reason
> > such a flow type has to be limited to RxRPC.
> 
> Other RPC types use normal socket types.

They do?  Examples please.  I didn't think Linux, at least, has any other RPC
socket families, though I could be wrong as I haven't made a thorough study of
them.

> > I'd say that that precludes applicability on two points: firstly, RxRPC is
> > not a datagram layer by the definition I provided in a previous email; and
> > secondly, RxRPC *does* provide some ordering guarantees.
> 
> So you want SOCK_SEQPACKET perhaps then ?

Perhaps; but I think that's wrong also.  You yourself defined SEQPACKET to be a
datagram service, and FC6 socket(2) agrees.  The POSIX definition, however
disagrees[*]: it claims that SEQPACKET is a stream-based service that permits
record markers to be embedded in the stream.  I can see how the two can be two
views of the same thing, but it looks like in either case the two flows are
independent at the socket level - which is not so for RxRPC as requests,
replies and ACKs are obviously not independent.

Furthermore:

 (1) The message flow in RxRPC is not completely ordered as seems to be
     required in SEQPACKET: packets going into the Tx socket need not come out
     of the Rx socket in the same order.  The only ordering is over the packets
     of a particular operation (as labelled by the control data).

 (2) The RxRPC sockets don't actually require a formal connection.  Even at the
     protocol level, there is no connection negotiation and no disconnection.
     A virtual connection more or less springs up spontaneously when the first
     data packet on it arrives.  Virtual connections are really only ways of
     avoiding having to set up the security for every call.

     I have made my client sockets use connect(), but that's just a convenience
     and I need to make it possible to avoid doing that to make it useful to
     the kernel.  It's similar to SOCK_DGRAM sockets in this respect.

David

[*] There has been discussion on this.