Posts: 69
Threads: 11
Joined: Jun 2019
Reputation:
0
2021-06-04, 09:05 AM
(This post was last modified: 2021-06-04, 08:09 PM by rszemeti.)
I have two raspberry pi with networking over WiFi. Both run SignalK
One of them is supposed to pull data from the other, over SignalK by websocket, fixed IP.
About half the time it does ... but, often it doesn't, (depending on the order in which the network comes up) with an error about "unable to connect" shown in the status line for that data source.
Is there some way to get SignalK to keep re-trying the connection if it doesn't get it first time? I would have expected it to try and reconnect the source from time to time, but it doesn't seem to.
Posts: 69
Threads: 11
Joined: Jun 2019
Reputation:
0
I think I need a "tcp" connection rather than a WebSocket connection as it appears from some other threads that tcp offers an auto-reconnect, and I guess WebSocket doesn't. I have tcp enabled on the server, but when I check the ports, I can't see a listening tcp socket other than 3000 for admin and the NMEA0183 port ... what port is SignalK supposed to use for tcp connections?
Posts: 1,162
Threads: 98
Joined: Mar 2016
Reputation:
69
bluetooth has a reputation of not being very good on raspberry pi's, maybe try wifi instead?
Posts: 330
Threads: 5
Joined: Mar 2018
Reputation:
24
2021-06-04, 04:41 PM
(This post was last modified: 2021-06-04, 04:42 PM by tkurki.)
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.
Posts: 69
Threads: 11
Joined: Jun 2019
Reputation:
0
I never mentioned anything about bluetooth!! I am using WiFi ... the network is "up" and even after several hours the "main" server has not managed to connect to the data source server, although it is now up and ready.
This is nothing to do with "flaky network issues" ... the various devices on the network all boot when power is applied, if the data source is not available when SK initially tries to connect, it simply gives up. Any robust system should st least try and reconnect the device should it go missing (the individual device may have been disconnected , temporarily powered down for example.) ... after several hours it still says "connect EHOSTUNREACH 10.10.10.161:3000" ...
Posts: 1,162
Threads: 98
Joined: Mar 2016
Reputation:
69
(2021-06-04, 09:05 AM)rszemeti Wrote: I have two raspberry pi with networking over bluetooth.
(2021-06-04, 06:50 PM)rszemeti Wrote: I never mentioned anything about bluetooth!!
That first sentence confused things a little ...  
Posts: 69
Threads: 11
Joined: Jun 2019
Reputation:
0
(2021-06-04, 07:36 PM)PaddyB Wrote: (2021-06-04, 09:05 AM)rszemeti Wrote: I have two raspberry pi with networking over bluetooth.
(2021-06-04, 06:50 PM)rszemeti Wrote: I never mentioned anything about bluetooth!!
That first sentence confused things a little ...
Doh! And this is why they don't let me mess with important things 
Anyway, right corrected and back to where we were ... how do I configure SK to reliably sort itself out and connect up the various bits?
Posts: 69
Threads: 11
Joined: Jun 2019
Reputation:
0
2021-06-05, 02:10 AM
(This post was last modified: 2021-06-05, 02:14 AM by rszemeti.)
(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.
Posts: 330
Threads: 5
Joined: Mar 2018
Reputation:
24
(2021-06-05, 02:10 AM)rszemeti Wrote: 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 ..
Oh. Quite right, that is a clear bug. It had escaped my attention, even if there is an issue for it https://github.com/SignalK/signalk-js-client/issues/90.
Please add your comments there to underline the need for this. By commenting you'll also subscribe to updates on the issue, so you'll be notified when it is fixed.
Posts: 330
Threads: 5
Joined: Mar 2018
Reputation:
24
Hmm. Strike that, in my local test setup everything works: no matter if the master server is up or down when the client server starts it connects automatically.
You can debug the client's behavior by entering signalk-js-sdk/* in Server / Server Log debug value and check Remember debug setting to keep the value over restarts.
How recent is your server - when did you last update it?
|
