> We (TCP stack) compete with QUIC, based on UDP, which has no issues like > that. We need to allow TCP sessions being signaled of a non temporary > network disruption. >
Eric, can you provide some detail on this statement? I don't understand why QUIC wouldn't have this same issue. Seems like it is still connection oriented just like TCP, so if the application does a read expecting data from a peer and reverse reachability is lost, the the read on the socket hang just like reading a TCP would. If this is true, then the TCP solution would might actually be a better since it allows a means for a third party (presumably a daemon monitoring the network) to signal the application via closing specific TCP sockets. I don't see how this could work in UDP especially if these are unconnected sockets. What am I missing? Thanks, 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
