On 2018-08-17 09:05, Tom Herbert wrote: > On Fri, Aug 17, 2018 at 7:40 AM, Joe Touch <to...@strayalpha.com> wrote: > >> ... >> It's not subtle. There's no way to know whether keepalives at a higher level >> have any desired affect at the lower level at all - except using Wireshark >> to trace the packets sent. > I don't think that's necessarily true. RFC1122 states: > > "Keep-alive packets MUST only be sent when no data or acknowledgement > packets have been received for the connection within an interval."
That's Sec 4.2.3.6. and it's talking about what TCP does inside TCP. It's not talking about actions by layers above TCP. For all TCP knows, a user might have tried to send data that's been hung up in the OS. There's simply no specific way to know that anything above TCP causes TCP to do anything per se; even if an upper layer protocol does a TCP_SEND() directly, TCP might stall that data because of other things going on. > So if an application is performing keepalives by sending and receiving > keepalive messages over the connection then that is enough to supress > TCP keepalives. That may or may not be true, but it's for TCP to decide for itself. If the data isn't getting down to TCP in a way that causes TCP to send data before a TCP keepalive timer expires, TCP will - and should - send a keepalive. If the data does cause that timer to be reset, then that's for TCP to know. > For instance, if the period of application sending > keepalives on a connection is less then the one for TCP keepalives, > then there should be no TCP keepalives ever sent on the connection (if > Wireshark is showing otherwise then that might be a bug in the > implementation). Consider an app that writes 1GB to TCP every day. If TCP sends that out slowly (for whatever reason), it's possible no TCP keepalives will ever be sent. An app that thinks it's doing TCP a favor by sending an app keepalive every 1.9 hrs (just under the 2 hour default config) would simply be causing TCP to do unnecessary work. However, if that 1GB goes out in 10 seconds, then TCP would have sent its own keepalives just fine. It didn't need the app's help. So the app didn't help at all; at best, it does nothing and at worst it hurts. Joe
