On Tue, Sep 22, 2015 at 2:14 AM, Thomas Martitz <ku...@rockbox.org> wrote: > Am 21.09.2015 um 00:29 schrieb Tom Herbert: >> >> Kernel Connection Multiplexor (KCM) is a facility that provides a >> message based interface over TCP for generic application protocols. >> The motivation for this is based on the observation that although >> TCP is byte stream transport protocol with no concept of message >> boundaries, a common use case is to implement a framed application >> layer protocol running over TCP. To date, most TCP stacks offer >> byte stream API for applications, which places the burden of message >> delineation, message I/O operation atomicity, and load balancing >> in the application. With KCM an application can efficiently send >> and receive application protocol messages over TCP using a >> datagram interface. >> > > > Hello Tom, > > on a general note I'm wondering what this offers over the existing SCTP > support. SCTP offers reliable message exchange and multihoming already. > Hi Thomas,
The idea of KCM is to provide a an improved interface that is usable with currently deployed protocols without invoking any change on the wire whatsoever. Deploying SCTP to replace TCP use cases would entail a major operations change for us, AFAIK hardware support is scant, and we probably still can't reliably use it on the Internet (you can Google why is SCTP not widely deployed). I would point out that two of the four limitations of TCP listed in RFC4960 should be addressed by KCM :-) > On a specific note, I'm wondering if the dup(2) familiy of system calls > isn't a lot more suitable/natural instead of overloading accept. > dup is to duplicate a file descriptor not a socket. Sockets operations on duplicated file descriptors operate on the same socket, need to contend for the socket lock, etc. This is a similar rationale as to why we need SO_REUSEPORT instead of just dup'ing listener fds. Thanks, Tom > Best regards. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
