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