On 2018-08-17 14:13, Tom Herbert wrote: > On Fri, Aug 17, 2018 at 1:31 PM, Joe Touch <to...@strayalpha.com> wrote: > >> If you KNOW that the app keepalive will cause the TCP transmission, sure - >> but how do you KNOW that? You don't and can't. Even if you write to the TCP >> socket, all you know when the socket returns is that the data was copied to >> the kernel. You don't know for sure that you've triggered a TCP packet. > Actually, you do know that information. Application keepalives are > request/response messages sent in TCP data. When a response is > received to keepalive request over the TCP connection that is proof > that the keepalive was sent.
Yes, but the keepalive itself is a guarantee of nothing. It is the keepalive ACK that matters. > If the application keepalive was sent on > the socket, and no response is received before the application timer > expires, then the application declares the the connection dead and > most likely will just close the socket and try to reconnect. The fact > that an application keepalive request, or its response, might be stuck > in a TCP send buffer (e.g. peer rcv window is zero) versus the peer > host completely disappeared is irrelevant. To the application it's all > the same, a connection to a peer application has failed and action > needs to be taken. In that case it never mattered whether TCP had a keepalive or whether the app action interacted with that TCP keepalive. What mattered was that the app-app communication was maintained. Again, this reiterates my point - run keepalives at the layer that matter to you. Ignore how they affect other layers; they will (and should) take care of themselves. Joe
