Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #3]
David Howells <[EMAIL PROTECTED]> wrote: > > - recvmsg not supporting MSG_TRUNC is rather weird and really ought to be > > fixed one day as its useful to find out the sizeof message pending when > > combined with MSG_PEEK > > Hmmm... I hadn't considered that. I assumed MSG_TRUNC not to be useful as > arbitrarily chopping bits out of the request or reply would seem to be > pointless. But why do I need to support MSG_TRUNC? I currently have things arranged so that if you do a recvmsg() that doesn't pull everything out of a packet then the next time you do a recvmsg() you'll get the next part of the data in that packet. MSG_EOR is flagged when recvmsg copies across the last byte of data of a particular phase. I might at some point in the future enable recvmsg() to keep pulling packets off the Rx queue and copying them into userspace until the userspace buffer is full or we find that the next packet is not the logical next in sequence. Hmmm... I'm actually overloading MSG_EOR. MSG_EOR is flagged on the last data read, and is also flagged for terminal messages (end or reply data, abort, net error, final ACK, etc). I wonder if I should use MSG_MORE (or its lack) instead to indicate the end of data, and only set MSG_EOR on the terminal message. MSG_MORE is set by the app to flag to sendmsg() that there's more data to come, so it would be consistent to use it for recvmsg() too. David - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #3]
David Howells <[EMAIL PROTECTED]> wrote:
> > > - recvmsg not supporting MSG_TRUNC is rather weird and really ought to be
> > > fixed one day as its useful to find out the sizeof message pending when
> > > combined with MSG_PEEK
> >
> > Hmmm... I hadn't considered that. I assumed MSG_TRUNC not to be useful as
> > arbitrarily chopping bits out of the request or reply would seem to be
> > pointless.
>
> But why do I need to support MSG_TRUNC? I currently have things arranged so
> that if you do a recvmsg() that doesn't pull everything out of a packet then
> the next time you do a recvmsg() you'll get the next part of the data in that
> packet. MSG_EOR is flagged when recvmsg copies across the last byte of data
> of a particular phase.
Okay... I've rewritten my recvmsg implementation for RxRPC. The one I had
could pull messages belonging to a call off the socket in the wrong order if
two threads both tried to pull simultaneously.
Also:
(1) If there's a sequence of data messages belonging to a particular call on
the receive queue, then recvmsg() will keep eating them until it meets
either a non-data message or a message belonging to a different call or
until it fills the user buffer. If it doesn't fill the user buffer, it
will sleep unless it is non-blocking.
(2) MSG_PEEK operates similarly, but will return immediately if it has put any
data in the buffer rather than waiting for further packets to arrive.
(3) If a packet is only partially consumed in filling a user buffer, then the
shrunken packet will be left on the front of the queue for the next taker.
(4) If there is more data to be had on a call (we haven't copied the last byte
of the last data packet in that phase yet), then MSG_MORE will be flagged.
(5) MSG_EOR will be flagged on the terminal message of a call. No more
messages from that call will be received, and the user ID may be reused.
Patch attached.
David
diff --git a/net/rxrpc/Makefile b/net/rxrpc/Makefile
index 3369534..f12cd28 100644
--- a/net/rxrpc/Makefile
+++ b/net/rxrpc/Makefile
@@ -17,6 +17,7 @@ af-rxrpc-objs := \
ar-local.o \
ar-output.o \
ar-peer.o \
+ ar-recvmsg.o \
ar-security.o \
ar-skbuff.o \
ar-transport.o
diff --git a/net/rxrpc/af_rxrpc.c b/net/rxrpc/af_rxrpc.c
index b25d931..06963e6 100644
--- a/net/rxrpc/af_rxrpc.c
+++ b/net/rxrpc/af_rxrpc.c
@@ -385,217 +385,6 @@ out:
}
/*
- * receive a message from an RxRPC socket
- */
-static int rxrpc_recvmsg(struct kiocb *iocb, struct socket *sock,
-struct msghdr *msg, size_t len, int flags)
-{
- struct rxrpc_skb_priv *sp;
- struct rxrpc_call *call;
- struct rxrpc_sock *rx = rxrpc_sk(sock->sk);
- struct sk_buff *skb;
- int copy, ret, ullen;
- u32 abort_code;
-
- _enter(",,,%zu,%d", len, flags);
-
- if (flags & (MSG_OOB | MSG_TRUNC))
- return -EOPNOTSUPP;
-
-try_again:
- if (RB_EMPTY_ROOT(&rx->calls) &&
- rx->sk.sk_state != RXRPC_SERVER_LISTENING)
- return -ENODATA;
-
- /* receive the next message from the common Rx queue */
- skb = skb_recv_datagram(&rx->sk, flags, flags & MSG_DONTWAIT, &ret);
- if (!skb) {
- _leave(" = %d", ret);
- return ret;
- }
-
- sp = rxrpc_skb(skb);
- call = sp->call;
- ASSERT(call != NULL);
-
- /* make sure we wait for the state to be updated in this call */
- spin_lock_bh(&call->lock);
- spin_unlock_bh(&call->lock);
-
- if (test_bit(RXRPC_CALL_RELEASED, &call->flags)) {
- _debug("packet from release call");
- rxrpc_free_skb(skb);
- goto try_again;
- }
-
- rxrpc_get_call(call);
-
- /* copy the peer address. */
- if (msg->msg_name && msg->msg_namelen > 0)
- memcpy(&msg->msg_name, &call->conn->trans->peer->srx,
- sizeof(call->conn->trans->peer->srx));
-
- /* set up the control messages */
- ullen = msg->msg_flags & MSG_CMSG_COMPAT ? 4 : sizeof(unsigned long);
-
- sock_recv_timestamp(msg, &rx->sk, skb);
-
- if (skb->mark == RXRPC_SKB_MARK_NEW_CALL) {
- _debug("RECV NEW CALL");
- ret = put_cmsg(msg, SOL_RXRPC, RXRPC_NEW_CALL, 0, &abort_code);
- if (ret < 0)
- goto error_requeue_packet;
- goto done;
- }
-
- ret = put_cmsg(msg, SOL_RXRPC, RXRPC_USER_CALL_ID,
- ullen, &call->user_call_ID);
- if (ret < 0)
- goto error_requeue_packet;
- ASSERT(test_bit(RXRPC_CALL_HAS_USERID, &call->flags));
-
- switch (skb->mark) {
- case RXRPC_SKB_MARK_DATA:
- _debug("recvmsg DATA #%u { %d, %d }",
- ntohl(sp->hdr.seq), skb->len, sp->offset);
-
- ASSERTCMP(ntohl(sp->hdr.seq), >=, call->rx_data_recv
Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #3]
David Howells <[EMAIL PROTECTED]> wrote:
> > - Why does rxrpc_writable always return 0 ?
>
> Good point. That's slightly tricky to deal with as output messages don't
> remain queued on the socket struct itself. Hmmm...
Okay, I've fixed that by changing it to:
static inline int rxrpc_writable(struct sock *sk)
{
return atomic_read(&sk->sk_wmem_alloc) < (size_t) sk->sk_sndbuf;
}
All the rest of the sk_wmem_alloc management should be automatic through my
use of sock_alloc_send_skb() to allocate Tx buffers.
I notice that AF_UNIX effectively divides sk_sndbuf by four before doing the
comparison. Any idea why (there's no comment to say)? I presume it's so that
we show willingness to accept any chunk of data up to 3/4 of sk_sndbuf in size
if we flag POLLOUT, rather than the app finding POLLOUT is set, but it can
only send one byte of data.
I've still got a problem with this, though, and I'm not sure it's easy to
solve. An RxRPC socket may be performing several calls at once. It may have
sufficient space on the *socket* to accept more Tx data, but it may not be
possible to do so because the ACK window on the intended call may be full. So
POLLOUT could be set, and we might still block anyway:-/
This is unlike SOCK_STREAM sockets for TCP or AF_UNIX, I think, because each
of those has but a single transmit queue:-/
I'm not sure there's a lot I can do about that, but there are a few
possibilities:
(1) Always send data in non-blocking mode if we know there are multiple calls
and we don't want to get stuck. We'll get a suitable error message, but
there's no notification that the Tx queue is has been unblocked. I could
add such a notification (it shouldn't be hard), there are two immediately
obvious ways of doing it:
(a) Raise a one-shot pollable event to indicate that one of the
in-progress calls' Tx queues have come unstuck. This'd require
trying the non-stuck calls individually to find out which one it was.
(b) Queue a message for recvmsg() to grab that says a Tx queue has become
unstuck. This would permit the control message to indicate the call.
(2) Require a separate socket for each individual call. This is a very
heavyweight way of doing things, as it would require socket inodes and
other stuff per call. On the other hand it would permit a certain amount
more flexibility. The real downside is that I wouldn't want to be doing
this for the in-kernel AFS filesystem, but maybe that could bypass the
use of sockets.
(3) Allow the app to nominate which call on a socket it wants a poll() on
that socket to probe next.
David
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #3]
Alan Cox <[EMAIL PROTECTED]> wrote: > - recvmsg not supporting MSG_TRUNC is rather weird and really ought to be > fixed one day as its useful to find out the sizeof message pending when > combined with MSG_PEEK Hmmm... I hadn't considered that. I assumed MSG_TRUNC not to be useful as arbitrarily chopping bits out of the request or reply would seem to be pointless. > - RXRPC_MIN_SECURITY_LEVEL reads into rx->min_sec_level and then if it is > invalid reports an error but doesn't restore the valid level Fixed. > - Why does rxrpc_writable always return 0 ? Good point. That's slightly tricky to deal with as output messages don't remain queued on the socket struct itself. Hmmm... One thing I'd like to be able to do is pass the sk_buffs I've set up to UDP directly rather than having to call the UDP socket's sendmsg. That'd eliminate a copy. But I decided to get it working right first, then look at cute optimisations like that. Such a thing would also be useful for the AFS filesystem: it could pass skbuffs it has preloaded to AF_RXRPC, which would then hand them on to UDP. > - rxrpc_process_soft_ACKs doesn't itself limit and check acns->nAcks is > always below RXRPC_MAXACKS, as this is a stakc variable it ought to be > paranoid about it. I think its ok from the caller check but its very hard > to prove... nAcks is a uint8_t. If that can exceed RXRPC_MAXACKS (255) then I suspect I'll have more pressing worries. I could put a check in there, but the compiler would give me a warning:-/ > It needs a lot more eyes/review due to the complexity and network > exposure though - not your fault, whoever designed RXRPC's 8) It's not an entirely insane protocol:-) Actually, part of the problem is Linux itself. David - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #3]
Alan Cox <[EMAIL PROTECTED]> wrote: > > (*) SOCK_RPC has been removed. AF_RXRPC sockets now simply ignore the > > "type" argument to socket(). > > This is also incorrect Sigh. And what would you have me do? There *isn't* an appropriate SOCK_xxx constant available, and you won't let me add one that is. Maybe I should just pick SOCK_DCCP and have done with it; it's as appropriate as DGRAM, RDM, SEQPACKET or STREAM - except that would be silly. I assert that RAW and PACKET are both even less appropriate than any of the other choices. Let me explain again why I think each choice is incorrect. You gave me four choices, which you and POSIX classify thus: ConstantYour Service type POSIX Service Type === === === SOCK_DGRAM DatagramDatagram SOCK_RDMDatagramDatagram SOCK_SEQPACKET DatagramStream (maybe Datagram) SOCK_STREAM Stream Stream A datagram service by definition (as can be found on various websites), transfers a piece of data from one place to another with no dependence on and no regard to any other pieces of data that the service is asked to transport. At its simplest level (SOCK_DGRAM), that's _all_ it does. SOCK_DGRAM makes no assertions about whether the datagram will get there, and requires no report that it did get there. Furthermore, no ordering at all is imposed on the sequence in which the far side sees any such pieces of data. SOCK_RDM is a step up from that. Again, like SOCK_DGRAM, it presents a datagram service to the application. But unlike SOCK_DGRAM, it will attempt to report the success or failure of the attempt to transfer the data. This may involve exchanging further packets with the peer behind the scenes, but ultimately, all it does is to transfer one piece of data from one peer to another; the added value is that the sender can attempt to determine whether this worked. Furthermore, as for SOCK_DGRAM, no ordering at all is imposed on the sequence in which the far side sees any such pieces of data. SOCK_SEQPACKET can be considered a step up from SOCK_RDM. It can be considered to provide a reliable datagram service to the application (as SOCK_RDM), but one in which the datagrams are guaranteed to be seen by the receiver in precisely the same order as they are sent by the sender, with no datagrams being lost from the sequence. In this model, SOCK_SEQPACKET would be seen as providing two independent, independently ordered streams of datagrams, one in each direction. SOCK_STREAM is a data streaming service in which data is guaranteed to come out of the receiver in precisely the same order as it was put into the transmitter. Furthermore, SOCK_STREAM can be seen as providing two independent, independently ordered streams of data, one in each direction. SOCK_SEQPACKET can also be considered to provide a streaming service (similar to SOCK_STREAM) in which record boundaries are maintained. Data is guaranteed to come out of the receiver in precisely the order as it was put in to the transmitter, but the receiver will break off and flag MSG_EOR at points in the data flow that correspond to those at which the sender flagged a record boundary. In this model, SOCK_SEQPACKET would be seen as providing two independent, independently ordered streams of data and record markers, one in each direction. In effect, SOCK_STREAM and SOCK_SEQPACKET can each be viewed as a pair of independent, symmetric unidirectional services, one for each direction: ++ ++ || +-+ || ||->| Tx Stream |->|| | Local | +-+ | Remote | | Socket | | Socket | _||___||_ || || || +-+ || ||<-| Rx Stream |<-|| || +-+ || ++ ++ SOCK_SEQPACKET can give the appearance of being an ordered, reliable datagram service simply by the application using it assuming that the record boundaries delimit separate datagrams. SOCK_DGRAM and SOCK_RDM, on the other hand, can be viewed as being a pair of independent unidirectional asymmetric services, one that spits out packets and one that collects datagrams. ++ +--+ ++ || |Tx|-- || || +--+ \|| ||/ \ || || / +--+ \ || ||->+--->|Tx|>|| | Local | \ +
Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #3]
Ok quickly going over the code that hasn't made the list - recvmsg not supporting MSG_TRUNC is rather weird and really ought to be fixed one day as its useful to find out the sizeof message pending when combined with MSG_PEEK - RXRPC_MIN_SECURITY_LEVEL reads into rx->min_sec_level and then if it is invalid reports an error but doesn't restore the valid level - Why does rxrpc_writable always return 0 ? - rxrpc_process_soft_ACKs doesn't itself limit and check acns->nAcks is always below RXRPC_MAXACKS, as this is a stakc variable it ought to be paranoid about it. I think its ok from the caller check but its very hard to prove... It needs a lot more eyes/review due to the complexity and network exposure though - not your fault, whoever designed RXRPC's 8) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #3]
Alan Cox <[EMAIL PROTECTED]> wrote: > Some of them don't seem to be making it through to the list and are > dropped each time btw Yeah. It's a size issue. The fifth patch is a third of a megabyte. The patches at the URLs should now be updated (I'd forgotten to do that before sending the emails). David - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #3]
> These patches together supply secure client-side RxRPC connectivity as a Linux > kernel socket family. Only the transport/session side is supplied - the > presentation side (marshalling the data) is left to the client. Copies of the > patches can be found here: Some of them don't seem to be making it through to the list and are dropped each time btw - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #3]
> (*) SOCK_RPC has been removed. AF_RXRPC sockets now simply ignore the "type" > argument to socket(). This is also incorrect NAK - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #3]
These patches together supply secure client-side RxRPC connectivity as a Linux kernel socket family. Only the transport/session side is supplied - the presentation side (marshalling the data) is left to the client. Copies of the patches can be found here: http://people.redhat.com/~dhowells/rxrpc/01-crypto-kernel-buff.diff http://people.redhat.com/~dhowells/rxrpc/02-move-skb-generic.diff http://people.redhat.com/~dhowells/rxrpc/03-timers.diff http://people.redhat.com/~dhowells/rxrpc/04-keys.diff http://people.redhat.com/~dhowells/rxrpc/05-af_rxrpc.diff The userspace access methods make use of the control data passed to/by sendmsg() and recvmsg(). See the three simple test programs: http://people.redhat.com/~dhowells/rxrpc/klog.c http://people.redhat.com/~dhowells/rxrpc/rxrpc.c http://people.redhat.com/~dhowells/rxrpc/listen.c I've attached the current in-kernel documentation to this message. TODO: (*) Make fs/afs/ use it and delete the current contents of net/rxrpc/ (*) Make certain parameters (such as connection timeouts) userspace configurable. (*) Make userspace utilities use it; librxrpc. (*) Userspace documentation. (*) KerberosV security. Changes: (*) SOCK_RPC has been removed. AF_RXRPC sockets now simply ignore the "type" argument to socket(). (*) I've add a facility whereby calls can be made to destinations other than the connect() address of a client socket by making use of msg_name in the msghdr struct when using sendmsg() to send the first data packet of a call. Indeed, a client socket need not be connected before being used so. (*) I've also added a facility whereby client calls may also be made on server sockets, again by using msg_name in the msghdr struct. In such a case, the server's local transport endpoint is used. David == RxRPC NETWORK PROTOCOL == The RxRPC protocol driver provides a reliable two-phase transport on top of UDP that can be used to perform RxRPC remote operations. This is done over sockets of AF_RXRPC family, using sendmsg() and recvmsg() with control data to send and receive data, aborts and errors. Contents of this document: (*) Overview. (*) RxRPC protocol summary. (*) AF_RXRPC driver model. (*) Security. (*) Example client usage. (*) Example server usage. OVERVIEW RxRPC is a two-layer protocol. There is a session layer which provides reliable virtual connections using UDP over IPv4 (or IPv6) as the transport layer, but implements a real network protocol; and there's the presentation layer which renders structured data to binary blobs and back again using XDR (as does SunRPC): +-+ | Application | +-+ | XDR | Presentation +-+ |RxRPC| Session +-+ | UDP | Transport +-+ AF_RXRPC provides: (1) Part of an RxRPC facility for both kernel and userspace applications by making the session part of it a Linux network protocol (AF_RXRPC). (2) A two-phase protocol. The client transmits a blob (the request) and then receives a blob (the reply), and the server receives the request and then transmits the reply. (3) Retention of the reusable bits of the transport system set up for one call to speed up subsequent calls. (4) A secure protocol, using the Linux kernel's key retention facility to manage security on the client end. The server end must of necessity be more active in security negotiations. AF_RXRPC does not provide XDR marshalling/presentation facilities. That is left to the application. AF_RXRPC only deals in blobs. Even the operation ID is just the first four bytes of the request blob, and as such is beyond the kernel's interest. Sockets of AF_RXRPC family are: (1) created as any type, but 0 is recommended; (2) provided with a protocol of the type of underlying transport they're going to use - currently only PF_INET is supported. The Andrew File System (AFS) is an example of an application that uses this and that has both kernel (filesystem) and userspace (utility) components. == RXRPC PROTOCOL SUMMARY == An overview of the RxRPC protocol: (*) RxRPC sits on top of another networking protocol (UDP is the only option currently), and uses this to provide network transport. UDP ports, for example, provide transport endpoints. (*) RxRPC supports multiple virtual "connections" from any given transport endpoint, thus allowing the endpoints to be shared, even to the same remote endpoint. (*) Each connection goes to a par
Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #2]
David Miller <[EMAIL PROTECTED]> wrote: > David we're not looking for a precise match, so please stop > discussing this in those terms. We're looking for something > close enough. But we don't have one that's close. Let me recap: according to Alan's definitions, all (presumably all non-RAW) network services must either be datagram services or stream services, and must be selectable from DGRAM, RDM, SEQPACKET or STREAM. RPC is neither. Also, why does DCCP have its own type? According to Alan's logic that's superfluous. > The more and more I read Alan's arguments and your resistence to > his logic, Which is flawed... > the more I side with Alan. He's definitely right on all the basic counts > here. Well, perhaps *you* can explain why he's right then... But, since you insist, I'll just remove any restrictions on the type and drop SOCK_RPC. Type 0 will serve just as well since there's only one choice to be had anyway, and that's all there's likely to be. David - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #2]
Alan Cox <[EMAIL PROTECTED]> wrote: > O> No, it's not. SOCK_DGRAM is an unreliable, unidirectional datagram passing > > service. > > Thats funny UDP receives and sends packets. I meant that the protocol ships a datagram from one peer to another, but there's no tie at the protocol level to any datagrams going the other way. David - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #2]
From: David Howells <[EMAIL PROTECTED]> Date: Mon, 19 Mar 2007 15:41:38 + > Alan Cox <[EMAIL PROTECTED]> wrote: > > > So use SOCK_DGRAM, its clearly near enough. > > No, it's not. SOCK_DGRAM is an unreliable, unidirectional datagram passing > service. David we're not looking for a precise match, so please stop discussing this in those terms. We're looking for something close enough. The more and more I read Alan's arguments and your resistence to his logic, the more I side with Alan. He's definitely right on all the basic counts here. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #2]
O> No, it's not. SOCK_DGRAM is an unreliable, unidirectional datagram passing > service. Thats funny UDP receives and sends packets. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #2]
Alan Cox <[EMAIL PROTECTED]> wrote: > > > 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. > > SunRPC is implemented in user space and uses the existing TCP/IP layer > and socket types, even though it is using them in an RPC manner and > viewed at the RPC layer they are RPCs SunRPC is not then a suitable analogy. There is no socket interface that provides SunRPC as far as I know, so your example is invalid. Yes, SunRPC is built on top of something else, SOCK_DGRAM, SOCK_STREAM or whatever, but that's like saying TCP is a datagram service rather than a stream service because it's built on a datagram service (IP). What a protocol uses out the back is pretty much irrelevant - what is relevant is what the protocol in question actually appears to provide to anyone using it. > > 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. > > So use SOCK_DGRAM, its clearly near enough. No, it's not. SOCK_DGRAM is an unreliable, unidirectional datagram passing service. David - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #2]
> > 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. SunRPC is implemented in user space and uses the existing TCP/IP layer and socket types, even though it is using them in an RPC manner and viewed at the RPC layer they are RPCs > 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. So use SOCK_DGRAM, its clearly near enough. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #2]
Alan Cox <[EMAIL PROTECTED]> 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. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #2]
> 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. > Interestingly, searching for SOCK_RDM definitions with google shows there's > some disagreement as to what it represents. Some seem to thing it's > connection > oriented and some that it's connectionless, and some seem to think it's > ordered, and some not. Which is just fine, does it need to be one or the other. SOCK_DGRAM an be both connection oriented or connectionless. > > > > independent and possibly simultaneous RxRPC calls. From the digging > > > around that I did in the kernel socket code a while ago I don't see a > > > cleaner way of implementing it than a new SOCK_RXRPC. > > 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. > 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 ? > > What does AIX do out of interest ? > > I've no way to find out what AIX does, but I suspect it simply doesn't. Perhaps someone with AIX boxes around (say @ibm.com) could answer ? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #2]
Alan Cox <[EMAIL PROTECTED]> wrote: > > IMHO the problem with classifying RxRPC as a "reliable datagram" > > socket is that even an atomic unidirectional communication isn't a > > single datagram, it's at least 3; there is shared connection state > > Thats fine. Any *reliable* protocol sends more than one packet per > message you send. RDM is for reliable messages I'm not arguing with that. Why I think RDM is the wrong thing to use is that there seems to be a perception that RDM involves a unidirectional, single 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. Interestingly, searching for SOCK_RDM definitions with google shows there's some disagreement as to what it represents. Some seem to thing it's connection oriented and some that it's connectionless, and some seem to think it's ordered, and some not. > > independent and possibly simultaneous RxRPC calls. From the digging > > around that I did in the kernel socket code a while ago I don't see a > > cleaner way of implementing it than a new SOCK_RXRPC. Well, I suggest SOCK_RPC, not SOCK_RXRPC. There's no particular reason such a flow type has to be limited to RxRPC. > I disagree entirely. That's your prerogative. > I've still seen no evidence you need a new type for this. Conversely, you haven't shown that any of the existing types are suitable either. Strictly, the "type" parameter for RxRPC family sockets is completely irrelevant as only one flow type is supported anyway; but still, I'd like to get it right. Looking at the socket(2) manpage, I see the definition of the SOCK_RDM to be: Provides a reliable datagram layer that does not guarantee ordering. 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. > What does AIX do out of interest ? I've no way to find out what AIX does, but I suspect it simply doesn't. The way OpenAFS does things is that it has an RxRPC library that can be compiled either in userspace or in kernel space. Userspace AFS utilities use the userspace-compiled library, which simply uses a UDP socket as its kernel interface; the kernel code uses the same library, but compiled for existence within the kernel. David - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #2]
> IMHO the problem with classifying RxRPC as a "reliable datagram" > socket is that even an atomic unidirectional communication isn't a > single datagram, it's at least 3; there is shared connection state Thats fine. Any *reliable* protocol sends more than one packet per message you send. RDM is for reliable messages > independent and possibly simultaneous RxRPC calls. From the digging > around that I did in the kernel socket code a while ago I don't see a > cleaner way of implementing it than a new SOCK_RXRPC. I disagree entirely. I've still seen no evidence you need a new type for this. What does AIX do out of interest ? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #2]
On Mar 16, 2007, at 10:11:41, Alan Cox wrote: I know what they are; and I don't think that what's available covers it. and use a proper standard socket type. Assuming that that list is exhaustive... SOCK_RDM seems to match perfectly well here. The point isn't to enumerate everything in the universe the point is to find "works like" parallels good enough to avoid more special casing. IMHO the problem with classifying RxRPC as a "reliable datagram" socket is that even an atomic unidirectional communication isn't a single datagram, it's at least 3; there is shared connection state and security context on both sides which pertains to a collection of independent and possibly simultaneous RxRPC calls. From the digging around that I did in the kernel socket code a while ago I don't see a cleaner way of implementing it than a new SOCK_RXRPC. Cheers, Kyle Moffett - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #2]
> I know what they are; and I don't think that what's available covers it. > > > and use a proper standard socket type. > > Assuming that that list is exhaustive... SOCK_RDM seems to match perfectly well here. The point isn't to enumerate everything in the universe the point is to find "works like" parallels good enough to avoid more special casing. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #2]
Alan Cox <[EMAIL PROTECTED]> wrote: > So your messages are neither reliable not unreliable, nor ordered, nor > unordered. If you look at the LHS of each of your list of mappings again, you'll see you've made an assumption there in considering it to be an exhaustive list. You've assumed a service must be either a datagram service or a stream service; I content that RxRPC is neither. Let me explain. RxRPC is not a datagram service because: A datagram is, to quote the Internet's Request for Comments 1594, "a self-contained, independent entity of data carrying sufficient information to be routed from the source to the destination computer without reliance on earlier exchanges between this source and destination computer and the transporting network. An RxRPC operation fails the "without reliance on earlier exchanges" bit, and I'd argue that it possibly fails the "self-contained" and "independent" bits too. RxRPC does use a datagram service as its transport, but it takes a minimum of three packets to complete an operation: a request from the client, a reply from the server and a final ACK from the client. The second and third packets are dependent on the first to give them meaning. Looking at RxRPC from a client app point of view, you have to issue a request packet and then await for the reply _associated_ with it (as marked by the control data). In the server app, you receive a request message, and then have to make a reply _associated_ with that request. Furthermore, you can have several operations in progress simultaneously on a socket. They are ordered with respect to themselves only; they are not ordered with respect to each other. RxRPC is also not a streamed data service because it doesn't have a stream of data (either continuous [STREAM] or broken [SEQPACKET]) of indefinite length. It has operations, each of which follows a sequence of discrete phases (request, secure, secured, reply, final ACK). Each operation is independent of the other operations, and may overlap temporally with those others. So, to summarise, I think this is a "new" type of flow model because: (1) It has discrete components (operations) rather than a flow. (2) The discrete components may overlap temporally (are unordered with respect to each other). (3) Each discrete component consists of a sequence of phases, first in one direction then the other and then back again rather than discrete independent messages (are ordered with respect to themselves). (4) It is reliable. It also has security features, but I don't think that needs to be part of the definition, even though negotiating it does require the use of extra packets of special types. > Until you work out what your messages actually are I know what they are; and I don't think that what's available covers it. > and use a proper standard socket type. Assuming that that list is exhaustive... > And "but there are higher layers" isn't relevant here, this is true for > Appletalk as well and it doesn't have to go inventing new types for > everything as you seem to. The fact that there are higher layers is irrelevant. David - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #2]
On Fri, 16 Mar 2007 14:23:13 + David Howells <[EMAIL PROTECTED]> wrote: > Alan Cox <[EMAIL PROTECTED]> wrote: > > > If your messages are datagrams and unreliable -> SOCK_DGRAM > > Nope. > > > If your messages are datagrams and reliable -> SOCK_RDM > > Nope. > > > If your messages are datagrams, reliable and ordered -> SOCK_SEQPACKET > > Nope. > > > If your messages are streams of bits, reliable and ordered -> SOCK_STREAM > > Nope. So your messages are neither reliable not unreliable, nor ordered, nor unordered. NAK Until you work out what your messages actually are and use a proper standard socket type. And "but there are higher layers" isn't relevant here, this is true for Appletalk as well and it doesn't have to go inventing new types for everything as you seem to. Alan - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #2]
Alan Cox <[EMAIL PROTECTED]> wrote: > If your messages are datagrams and unreliable -> SOCK_DGRAM Nope. > If your messages are datagrams and reliable -> SOCK_RDM Nope. > If your messages are datagrams, reliable and ordered -> SOCK_SEQPACKET Nope. > If your messages are streams of bits, reliable and ordered -> SOCK_STREAM Nope. David - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #2]
> Sockets of AF_RXRPC family are: > > (1) created as type SOCK_RPC; There is no such socket type and please don't invent one If your messages are datagrams and unreliable -> SOCK_DGRAM If your messages are datagrams and reliable -> SOCK_RDM If your messages are datagrams, reliable and ordered -> SOCK_SEQPACKET If your messages are streams of bits, reliable and ordered -> SOCK_STREAM - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #2]
On Fri, Mar 16, 2007 at 12:50:08PM +, David Howells wrote: > (*) Make fs/afs/ use it and delete the current contents of net/rxrpc/ Having this done would be a really useful use case for getting the code merged.. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #2]
These patches together supply secure client-side RxRPC connectivity as a Linux kernel socket family. Only the transport/session side is supplied - the presentation side (marshalling the data) is left to the client. Copies of the patches can be found here: http://people.redhat.com/~dhowells/rxrpc/01-crypto-kernel-buff.diff http://people.redhat.com/~dhowells/rxrpc/02-move-skb-generic.diff http://people.redhat.com/~dhowells/rxrpc/03-timers.diff http://people.redhat.com/~dhowells/rxrpc/04-keys.diff http://people.redhat.com/~dhowells/rxrpc/05-af_rxrpc.diff The userspace access methods make use of the control data passed to/by sendmsg() and recvmsg(). See the three simple test programs: http://people.redhat.com/~dhowells/rxrpc/klog.c http://people.redhat.com/~dhowells/rxrpc/rxrpc.c http://people.redhat.com/~dhowells/rxrpc/listen.c I've attached the current in-kernel documentation to this message. TODO: (*) Make it possible for the client socket to be used to go to more than one destination. (*) Make fs/afs/ use it and delete the current contents of net/rxrpc/ (*) Make certain parameters (such as connection timeouts) userspace configurable. (*) Make userspace utilities use it; librxrpc. (*) Userspace documentation. (*) KerberosV security. David == RxRPC NETWORK PROTOCOL == The RxRPC protocol driver provides a reliable two-phase transport on top of UDP that can be used to perform RxRPC remote operations. This is done over sockets of AF_RXRPC family, using sendmsg() and recvmsg() with control data to send and receive data, aborts and errors. Contents of this document: (*) Overview. (*) RxRPC protocol summary. (*) AF_RXRPC driver model. (*) Security. (*) Example client usage. (*) Example server usage. OVERVIEW RxRPC is a two-layer protocol. There is a session layer which provides reliable virtual connections using UDP over IPv4 (or IPv6) as the transport layer, but implements a real network protocol; and there's the presentation layer which renders structured data to binary blobs and back again using XDR (as does SunRPC): +-+ | Application | +-+ | XDR | Presentation +-+ |RxRPC| Session +-+ | UDP | Transport +-+ AF_RXRPC provides: (1) Part of an RxRPC facility for both kernel and userspace applications by making the session part of it a Linux network protocol (AF_RXRPC). (2) A two-phase protocol. The client transmits a blob (the request) and then receives a blob (the reply), and the server receives the request and then transmits the reply. (3) Retention of the reusable bits of the transport system set up for one call to speed up subsequent calls. (4) A secure protocol, using the Linux kernel's key retention facility to manage security on the client end. The server end must of necessity be more active in security negotiations. AF_RXRPC does not provide XDR marshalling/presentation facilities. That is left to the application. AF_RXRPC only deals in blobs. Even the operation ID is just the first four bytes of the request blob, and as such is beyond the kernel's interest. Sockets of AF_RXRPC family are: (1) created as type SOCK_RPC; (2) provided with a protocol of the type of underlying transport they're going to use - currently only PF_INET is supported. The Andrew File System (AFS) is an example of an application that uses this and that has both kernel (filesystem) and userspace (utility) components. == RXRPC PROTOCOL SUMMARY == An overview of the RxRPC protocol: (*) RxRPC sits on top of another networking protocol (UDP is the only option currently), and uses this to provide network transport. UDP ports, for example, provide transport endpoints. (*) RxRPC supports multiple virtual "connections" from any given transport endpoint, thus allowing the endpoints to be shared, even to the same remote endpoint. (*) Each connection goes to a particular "service". A connection may not go to multiple services. A service may be considered the RxRPC equivalent of a port number. AF_RXRPC permits multiple services to share an endpoint. (*) Client-originating packets are marked, thus a transport endpoint can be shared between client and server connections (connections have a direction). (*) Up to a billion connections may be supported concurrently between one local transport endpoint and one service on one remote endpoint. An RxRPC connection is described by seven numb
Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation
David Howells <[EMAIL PROTECTED]> wrote: > These patches together supply secure client-side RxRPC connectivity as a Linux > kernel socket family. Only the transport/session side is supplied - the > presentation side (marshalling the data) is left to the client. The patches can also be downloaded from: http://people.redhat.com/~dhowells/rxrpc/01-crypto-kernel-buff.diff http://people.redhat.com/~dhowells/rxrpc/02-move-skb-generic.diff http://people.redhat.com/~dhowells/rxrpc/03-timers.diff http://people.redhat.com/~dhowells/rxrpc/04-keys.diff http://people.redhat.com/~dhowells/rxrpc/05-af_rxrpc.diff David - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] [RFC] AF_RXRPC socket family implementation
These patches together supply secure client-side RxRPC connectivity as a Linux kernel socket family. Only the transport/session side is supplied - the presentation side (marshalling the data) is left to the client. The userspace access methods make use of the control data passed to/by sendmsg() and recvmsg(). See the three simple test programs: http://people.redhat.com/~dhowells/rxrpc/klog.c http://people.redhat.com/~dhowells/rxrpc/rxrpc.c http://people.redhat.com/~dhowells/rxrpc/listen.c I've attached the current in-kernel documentation to this message. TODO: (*) Make it possible for the client socket to be used to go to more than one destination. (*) Make fs/afs/ use it and delete the current contents of net/rxrpc/ (*) Make certain parameters (such as connection timeouts) userspace configurable. (*) Make userspace utilities use it; librxrpc. (*) Userspace documentation. (*) KerberosV security. David == RxRPC NETWORK PROTOCOL == The RxRPC protocol driver provides a reliable two-phase transport on top of UDP that can be used to perform RxRPC remote operations. This is done over sockets of AF_RXRPC family, using sendmsg() and recvmsg() with control data to send and receive data, aborts and errors. Contents of this document: (*) Overview. (*) RxRPC protocol summary. (*) AF_RXRPC driver model. (*) Security. (*) Example client usage. (*) Example server usage. OVERVIEW RxRPC is a two-layer protocol. There is a session layer which provides reliable virtual connections using UDP over IPv4 (or IPv6) as the transport layer, but implements a real network protocol; and there's the presentation layer which renders structured data to binary blobs and back again using XDR (as does SunRPC): +-+ | Application | +-+ | XDR | Presentation +-+ |RxRPC| Session +-+ | UDP | Transport +-+ AF_RXRPC provides: (1) Part of an RxRPC facility for both kernel and userspace applications by making the session part of it a Linux network protocol (AF_RXRPC). (2) A two-phase protocol. The client transmits a blob (the request) and then receives a blob (the reply), and the server receives the request and then transmits the reply. (3) Retention of the reusable bits of the transport system set up for one call to speed up subsequent calls. (4) A secure protocol, using the Linux kernel's key retention facility to manage security on the client end. The server end must of necessity be more active in security negotiations. AF_RXRPC does not provide XDR marshalling/presentation facilities. That is left to the application. AF_RXRPC only deals in blobs. Even the operation ID is just the first four bytes of the request blob, and as such is beyond the kernel's interest. Sockets of AF_RXRPC family are: (1) created as type SOCK_RPC; (2) provided with a protocol of the type of underlying transport they're going to use - currently only PF_INET is supported. The Andrew File System (AFS) is an example of an application that uses this and that has both kernel (filesystem) and userspace (utility) components. == RXRPC PROTOCOL SUMMARY == An overview of the RxRPC protocol: (*) RxRPC sits on top of another networking protocol (UDP is the only option currently), and uses this to provide network transport. UDP ports, for example, provide transport endpoints. (*) RxRPC supports multiple virtual "connections" from any given transport endpoint, thus allowing the endpoints to be shared, even to the same remote endpoint. (*) Each connection goes to a particular "service". A connection may not go to multiple services. A service may be considered the RxRPC equivalent of a port number. AF_RXRPC permits multiple services to share an endpoint. (*) Client-originating packets are marked, thus a transport endpoint can be shared between client and server connections (connections have a direction). (*) Up to a billion connections may be supported concurrently between one local transport endpoint and one service on one remote endpoint. An RxRPC connection is described by seven numbers: Local address } Local port } Transport (UDP) address Remote address } Remote port } Direction Connection ID Service ID (*) Each RxRPC operation is a "call". A connection may make up to four billion calls, but only up to four calls may be in progress on a connection at any one time. (*) Calls are
Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation
YOSHIFUJI Hideaki <[EMAIL PROTECTED]> wrote:
> This sockaddr_rxrpc{} should NOT include sockaddr_in{} directly.
> Please use sockaddr_storage{} (or sockaddr{}, maybe), and make it
> sure to align on 64-bit word.
How about this then:
struct sockaddr_rxrpc {
sa_family_t srx_family; /* address family */
u16 srx_service;/* service desired */
u16 transport_type; /* type of transport socket
(SOCK_DGRAM) */
u16 transport_len; /* length of transport address */
struct sockaddr srx_sa[0]; /* address of transport endpoint */
};
Then whoever wants to use it must follow it immediately with an address of the
appropriate type. The length given to connect or bind would then be the
combined length of the two addresses.
Someone could then set one up on the stack by this sort of thing:
int zebra(int fd)
{
struct {
struct sockaddr_rxrpc srx;
struct sockaddr_in sin;
} sa;
...
if (connect(fd, (struct sockaddr *) &sa, sizeof(sa)) < 0)
...
...
}
David
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation
YOSHIFUJI Hideaki <[EMAIL PROTECTED]> wrote:
> Because it is protocol (such as ipv4 or ipv6) dependent.
Hmmm... I had thought of RxRPC being very transport dependent, being rather
tied to UDPv4, though probably simply extensible to UDPv6. However, as long
as the transport-layer header is removed on received packets before the main
part of the code sees them, there shouldn't be any problem supporting non-UDP
protocols, apart from, possibly, network error (ICMP) handling.
Some of the AFS operations, however, only deal in IPv4 addresses. I believe
there is work afoot to deal with this, but I as far as I know it hasn't been
dealt with yet.
Currently RxRPC is *only* available over UDPv4 in OpenAFS as far as I know.
> You cannot use different sturcture for one address family.
> You could use union, maybe.
I am using a union:
struct sockaddr_rxrpc {
sa_family_t srx_family;
u16 srx_service;
u16 transport_type;
u16 transport_len;
union {
sa_family_t family;
struct sockaddr_in sin;
struct sockaddr_in6 sin6;
} transport;
};
I can add the alignment restrictor to the union though.
> Another option would be to introduce new transport protocol such as
> dccp or sctp, no?
It's not my choice. My code must interoperate with the other RxRPC/AFS
implementations that are already out there and have been around for many
years.
David
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation
In article <[EMAIL PROTECTED]> (at Fri, 09 Feb 2007 12:31:23 +), David
Howells <[EMAIL PROTECTED]> says:
> YOSHIFUJI Hideaki <[EMAIL PROTECTED]> wrote:
>
> > and make it sure to align on 64-bit word.
>
> The first part of sockaddr_rxrpc is exactly 64 bits; then comes the transport
> address, so that's okay.
>
> > This sockaddr_rxrpc{} should NOT include sockaddr_in{} directly.
> > Please use sockaddr_storage{} (or sockaddr{}, maybe),
>
> Why can't I include sockaddr_in and sockaddr_in6 in sockaddr_rxrpc, btw?
Because it is protocol (such as ipv4 or ipv6) dependent.
You cannot use different sturcture for one address family.
You could use union, maybe.
> > > That won't work. That would then make the address larger than the maximum
> > > size (ie: sizeof(struct sockaddr_storage)).
> >
> > sockaddr{}, then...
>
> But that's not big enough to hold a sockaddr_in6...
struct sockaddr_rxrpc {
...
union {
struct sockaddr rxrpc_sa;
struct sockaddr_in rxrpc_sin;
struct sockaddr_in6 rxrpc_sin6;
} __attribute__((__aligned(8)__));
};
Another option would be to introduce new transport protocol such as
dccp or sctp, no?
--yoshfuji
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation
YOSHIFUJI Hideaki <[EMAIL PROTECTED]> wrote:
> and make it sure to align on 64-bit word.
The first part of sockaddr_rxrpc is exactly 64 bits; then comes the transport
address, so that's okay.
> This sockaddr_rxrpc{} should NOT include sockaddr_in{} directly.
> Please use sockaddr_storage{} (or sockaddr{}, maybe),
Why can't I include sockaddr_in and sockaddr_in6 in sockaddr_rxrpc, btw?
> > That won't work. That would then make the address larger than the maximum
> > size (ie: sizeof(struct sockaddr_storage)).
>
> sockaddr{}, then...
But that's not big enough to hold a sockaddr_in6...
David
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation
In article <[EMAIL PROTECTED]> (at Fri, 09 Feb 2007 10:31:34 +), David
Howells <[EMAIL PROTECTED]> says:
> YOSHIFUJI Hideaki <[EMAIL PROTECTED]> wrote:
>
> > This sockaddr_rxrpc{} should NOT include sockaddr_in{} directly.
> > Please use sockaddr_storage{} (or sockaddr{}, maybe), and make it
> > sure to align on 64-bit word.
>
> That won't work. That would then make the address larger than the maximum
> size (ie: sizeof(struct sockaddr_storage)).
sockaddr{}, then...
--yoshfuji
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation
YOSHIFUJI Hideaki <[EMAIL PROTECTED]> wrote:
> This sockaddr_rxrpc{} should NOT include sockaddr_in{} directly.
> Please use sockaddr_storage{} (or sockaddr{}, maybe), and make it
> sure to align on 64-bit word.
That won't work. That would then make the address larger than the maximum
size (ie: sizeof(struct sockaddr_storage)).
David
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation
From: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
Date: Fri, 09 Feb 2007 01:55:39 +0900 (JST)
> In article <[EMAIL PROTECTED]> (at Thu, 08 Feb 2007 16:32:11 +), David
> Howells <[EMAIL PROTECTED]> says:
>
> > (2) A local address can optionally be bound:
> >
> > struct sockaddr_rxrpc srx = {
> > .srx_family = AF_RXRPC,
> > .srx_service= 0, /* we're a client */
> > .transport_type = SOCK_DGRAM, /* type of transport socket */
> > .transport.sin_family = AF_INET,
> > .transport.sin_port = htons(7000), /* AFS callback */
> > .transport.sin_address = 0, /* all local interfaces */
> > };
>
> This sockaddr_rxrpc{} should NOT include sockaddr_in{} directly.
> Please use sockaddr_storage{} (or sockaddr{}, maybe), and make it
> sure to align on 64-bit word.
This is correct.
David, we should make the suggested changes in order to support IPv6
(and theoretically other address families as the transport) cleanly.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation
In article <[EMAIL PROTECTED]> (at Thu, 08 Feb 2007 16:32:11 +), David
Howells <[EMAIL PROTECTED]> says:
> (2) A local address can optionally be bound:
>
> struct sockaddr_rxrpc srx = {
> .srx_family = AF_RXRPC,
> .srx_service= 0, /* we're a client */
> .transport_type = SOCK_DGRAM, /* type of transport socket */
> .transport.sin_family = AF_INET,
> .transport.sin_port = htons(7000), /* AFS callback */
> .transport.sin_address = 0, /* all local interfaces */
> };
This sockaddr_rxrpc{} should NOT include sockaddr_in{} directly.
Please use sockaddr_storage{} (or sockaddr{}, maybe), and make it
sure to align on 64-bit word.
--yoshfuji
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] [RFC] AF_RXRPC socket family implementation
These patches together supply secure client-side RxRPC connectivity as a Linux kernel socket family. Only the transport/session side is supplied - the presentation side (marshalling the data) is left to the client. The userspace access methods make use of the control data passed to/by sendmsg() and recvmsg(). See the two simple test programs: http://people.redhat.com/~dhowells/rxrpc/klog.c http://people.redhat.com/~dhowells/rxrpc/rxrpc.c I've attached the current in-kernel documentation to this message. TODO: (*) Server support. (*) Make it possible for the client socket to be used to go to more than one destination. (*) Make fs/afs/ use it and delete the current contents of net/rxrpc/ (*) Make certain parameters (such as connection timeouts) userspace configurable. (*) Make userspace utilities use it; librxrpc. (*) Userspace documentation. David == RxRPC NETWORK PROTOCOL == The RxRPC protocol driver provides a reliable two-phase transport on top of UDP that can be used to perform RxRPC remote operations. This is done over sockets of AF_RXRPC family, using sendmsg() and recvmsg() with control data to send and receive data, aborts and errors. OVERVIEW RxRPC is a two-layer protocol. There is a session layer which provides reliable virtual connections using UDP over IPv4 (or IPv6) as the transport layer, but implements a real network protocol; and there's the presentation layer which renders structured data to binary blobs and back again using XDR (as does SunRPC): +-+ | Application | +-+ | XDR | Presentation +-+ |RxRPC| Session +-+ | UDP | Transport +-+ AF_RXRPC provides: (1) Part of an RxRPC facility for both kernel and userspace applications by making the session part of it a Linux network protocol (AF_RXRPC). (2) A two-phase protocol. The client transmits a blob (the request) and then receives a blob (the reply), and the server receives the request and then transmits the reply. (3) Retention of the reusable bits of the transport system set up for one call to speed up subsequent calls. (4) A secure protocol, using the Linux kernel's key retention facility to manage security on the client end. The server end must of necessity be more active in security negotiations. AF_RXRPC does not provide XDR marshalling/presentation facilities. That is left to the application. AF_RXRPC only deals in blobs. Even the operation ID is just the first four bytes of the request blob, and as such is beyond the kernel's interest. Sockets of AF_RXRPC family are: (1) created as type SOCK_RPC; (2) provided with a protocol of the type of underlying transport they're going to use - currently only PF_INET is supported. The Andrew File System (AFS) is an example of an application that uses this and that has both kernel (filesystem) and userspace (utility) components. == RXRPC PROTOCOL SUMMARY == An overview of the RxRPC protocol: (*) RxRPC sits on top of another networking protocol (UDP is the only option currently), and uses this to provide network transport. UDP ports, for example, provide transport endpoints. (*) RxRPC supports multiple virtual "connections" from any given transport endpoint, thus allowing the endpoints to be shared, even to the same remote endpoint. (*) Each connection goes to a particular "service". A connection may not go to multiple services. A service may be considered the RxRPC equivalent of a port number. AF_RXRPC permits multiple services to share an endpoint. (*) Client-originating packets are marked, thus a transport endpoint can be shared between client and server connections (connections have a direction). (*) Up to a billion connections may be supported concurrently between one local transport endpoint and one service on one remote endpoint. An RxRPC connection is described by seven numbers: Local address } Local port } Transport (UDP) address Remote address } Remote port } Direction Connection ID Service ID (*) Each RxRPC operation is a "call". A connection may make up to four billion calls, but only up to four calls may be in progress on a connection at any one time. (*) Calls are two-phase and asymmetric: the client sends its request data, which the service receives; then the service transmits the reply data which the client receives. (*) The data blobs are of indefinite size, the end of a phase is mark
