> 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? > The TCP PSH flag is not defined for message delineation (neither is urgent pointer). We can't change that (many people have tried to add message semantics to TCP protocol but have always failed miserably). The fact is TCP is always going to be a stream based protocol. Period! :-) It is up to the application to interpret the stream and extract messages. Even if we could somehow apply the PSH bit to "help" in message delineation, we would need to change senders to use the PSH bit in that fashion for it to be of benefit to receivers.
> 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). > RPC messages can be of arbitrary size and with SOCK_SEQPACKET, messages can be sent or received in multiple calls. No HOL blocking since message are constructed on KCM sockets before starting to send on TCP sockets. Socket buffer limits are respected. KCM does not enforce a maximum message size, if an applications does have a maximum then that can be checked in the BPF code. >> 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? > Dave should be posting the basic TLS-in-the-kenel patches shortly, those will be a better context for discussion. Tom -- 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
