(2021-06-04, 04:41 PM)tkurki Wrote: Please don't share information you don't know, even as a guess. Others reading your posts will get the wrong impression and assume that WebSocket connections don't have a reconnection mechanism, which they do.
A problem you may be facing is that the network connection may go down, but on TCP (and WebSocket, that works on top of TCP) level it just appears that the other end has gone silent. The network connection takes long or for ever to timeout and inform the application about it.
Neither Signal K over WebSocket nor Signal K over TCP offer *connection timeout* - so that if the other end goes idle the client severs the connection and reconnects, to make sure the connection is ok. We should implement idle connection timeout as well as server heartbeat (sending a heartbeat message regularly even if there is no data to send).
You asked for "reliable". Your choice of BT is a poor match for that. Neither SK over Ws nor SK over TCP will solve your flaky network issues nor replicate the full data stream on the other Pi over disconnects.
Sorry, I should have said WiFi, not bluetooth, I have WiFi connection ...
The problem I have is that if it does not connect on the first attempt (eg the source machine has not woken up yet) it *never* connects .. I've been waitign 4 hours now and it still says "connect EHOSTUNREACH 10.10.10.161" ... but the network is up and the source host is alive and ready for connections, the main server is simply not trying to reconnect.
This is a big problem, I cannot be certain the exact timing with which the devices on the network will appear and if the main SignalK box does not find the data sources first time, it seems to just give up and not try again ...
It is not a problem of "flaky network issues" ... but even if it was a robust system should try and restore connections if they fail, not just stop and give up. I worked a lot with industrial control systems .. you always assume the network will at some point fail in some way and you want the devices to automatically connect when the network is available again, you don't want to send people around the factory to reset devices ... same on the boat, if for any reason the network fails for a short while, you want everything to reconnect when it comes up.
The current situation seems to be sub-optimal.