peer2peer network always receives messages with a timeout

[heckj]

I'm not 600% this is a fatal flaw, but it's an unintended discrepancy in the network providers.

For the WebSocket, only the "handshake" phase has an explicit timeout, and the ongoing process of receiving messages is not raced against a timeout. The idea being there may be extended periods of time (seconds, minutes, etc) where the connection is established, but nothing needs to be synced on the connection. With a timeout, the "waiting for a next message" on the connection would throw an error, and in the ongoing loop that would terminate the connection - potentially to see it attempt to reconnect if that was configured.

In the Peer2Peer provider, both the peering handshake process (both accepting a new connection and initiating a new connectIon) should use a timeout - we expect a timely handshake to establish the active connection, but there-after the ongoing loop - in either case - should require a timeout.

[alexjg]

FWIW the web socket server will send a ping (the web socket ping message that is) every so often (every 5s at the moment I think) and if the client does not respond with a pong within a timeout then the server closes the connection.

[heckj]

Yeah, I was recalling something like that as well. I added a to-do item for myself to create a test to validate everything is working as expected with #62 - I'm not entirely clear on if or how URLSessionWebSocketDataTask does pings, and if that connection is meant to be retained with a heartbeat, if I need to add something explicit to do so.

Then there's a broader question of would it be better to drop the connection while things are idle, and attempt to reconnect when it finds a change and wants to attempt to sync it. Right now that's not an option, but maybe it should be? At least with a configurable setting.