Hello, On Fri, Nov 20, 2015, at 22:21, Tom Herbert wrote: > 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.
I am a bit struggling seeing a real need to come up with a new socket type and subsystem for that. It looks like you want to solve the same problem that PACKET_FANOUT does? TCP has TCP-PSH flag which could help delimit messages and a way to improve FANOUT like PACKET_FANOUT would solve this same problem, too? A propoer fallback has to be in user space anyway but messages could maybe simply be flagged with an skb->mark and fanout could push it to the correct FANOUT-subsocket. > In order to delineate message in a TCP stream for receive in KCM, the > kernel implements a message parser. For this we chose to employ BPF > which is applied to the TCP stream. BPF code parses application layer > messages and returns a message length. Nearly all binary application > protocols are parsable in this manner, so KCM should be applicable > across a wide range of applications. Other than message length > determination in receive, KCM does not require any other application > specific awareness. KCM does not implement any other application > protocol semantics-- these are are provided in userspace or could be > implemented in a kernel module layered above KCM. For me this still looks a little bit like messages could be delimited by TCP PSH flag, where we might need to have some more fine grained control over and besides that just adding better fanout semantics to TCP, no? Do kcm sockets still allow streaming unlimited amounts of data? E.g. if you want to pass a data stream attached to a rpc message? I think not allowing streaming is a major shortcoming then (even though this will induce head of line blocking). > Future support: > > - Integration with TLS (TLS-in-kernel is a separate initiative). This is interesting: Regarding the last week's discussion about better OOB support in TCP e.g. for SOCKET_DESTROY, do you already have a plan to handle TLS alerts and do CHANGE_CIPHER on the socket synchronously? Thanks, Hannes -- 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
