After having a look at PingManager, there are some interesting details I’d like to know more about:
It will attempt to ping the server three times in a row, with 1s between. Why is that needed, as opposed to just sending one ping? It’s not like the additional traffic will somehow add more pressure to the connection
By default, PingManager will ping the server every 30 minutes (with three pings), but it won’t perform any action if those pings time out / throw exceptions. I understand how this is useful to keep the connection running, but it is inconsisten w.r.t. the configuration: either you shouldn’t ping by default and let the client enable pinging and provide a handler, or you should have a default action that resets the connection when no handlers are registered by the client.
I think that it will (under certain circumstances and implementation dependent, of course).
For example If a TCP packet containing a single ping gets lost, sending another ping means that you possibly don’t have to wait until the TCP state machines ack timeout for the first ping packet kicks in.
I am sorry but I do not see what the problem with the current behavior is.
I’m not sure about that. TCP is full of black magic, and I don’t dare making predictions based on that any more. However, I’d rather like to make that number default to one, and be configurable for the paranoid folks like you
As I said: you are pinging but not doing anything on a ping failure. It would make more sense to have an auto-reconnect-resume attempt when you discover you are ping-timeouted; or not to ping at all by default.
