fix: delegate starting receiver loops to caller

[silenium-dev]

fixes #68

[devgianlu]

The reason why the receiver isn't started is that there might be messages that arrive immediately after connection and if there's no listener then they'll be lost.

You'll need to call ReceiveMessage or ReceiveRequest and read from the channel they return. Or find an actual fix?

[silenium-dev]

Maybe we could start the ping loop on the first ReceiveMessage/ReceiveRequest call? Because it shouldn't be started either, if there's no receiver that could process the pongs.
Or we even could open the websocket connection on the first call, instead of immediately on creation.

[devgianlu]

Maybe we could start the ping loop on the first ReceiveMessage/ReceiveRequest call? Because it shouldn't be started either, if there's no receiver that could process the pongs.

That makes sense, but I believe that the server will close the connection if we don't ping it.

Or we even could open the websocket connection on the first call, instead of immediately on creation.

This makes even more sense, but we must be careful to the fact that the connection will be nil.

Because connection can fail, I don't think delegating it to the Receive* methods is feasible. Instead it should probably be handled by the caller (outside of NewDealer) through an exported Connect method, but we must deal with nil conn pointers and the reconnectLock (which should probably be named connMu).

All of the above also applies to the Accesspoint.

[silenium-dev]

I'm going to reopen this when I've implemented the proper fix

[silenium-dev]

I'm unsure whether to move Accesspoint.Connect() out of Session as AudioKeyProvider and Spclient depend on it.
Nothing internal depends on Dealer, so moving Connect() out of Session seems ok.

[silenium-dev]

It seems like the dealer ping timings are a bit too tight, it sends a ping every 30s, but also has a timeout of 30s, which can cause some network latency related reconnects, but that's only a guess, because it only happens on the 5th ping (after 150s) and I'm still looking into it

[silenium-dev]

Seems to be fixed by setting the time that the pong can be behind to pingInterval + timeout.
lastPong is now reset on reconnect to prevent a reconnect loop.

[devgianlu]

I'm unsure whether to move Accesspoint.Connect() out of Session as AudioKeyProvider and Spclient depend on it.
Nothing internal depends on Dealer, so moving Connect() out of Session seems ok.

I see, I guess this is ok because the accesspoint is required to complete authentication so it has to be always started.

Seems to be fixed by setting the time that the pong can be behind to pingInterval + timeout. lastPong is now reset on reconnect to prevent a reconnect loop.

Sure, this makes sense.

[devgianlu]

Thanks!

[devgianlu]

Had to implement a couple of fixes, looks better now.