00 Feature Request

This is the project for all Feature Requests except the ones ones that have been "vetted" (see Feature Requests Vetted) and ones concerning plugins. Please add Plugin Feature Requests to the respective plugin project - thanks.

FS#2192 - TCP connection reset logic flawed

Attached to Project: 00 Feature Request
Opened by Gary Smith (GarySmith) - Thursday, 19 January 2017, 09:54 GMT
Task Type Bug Report
Category Backend / Core
Status Assigned
Assigned To Dave (bdbcat)
Operating System All
Severity Critical
Priority Normal
Reported Version future version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No


From observation it appears that the TCP connection is disconnected five seconds (plus a few milliseconds) after receipt of the last message. 5s later the connection is re-established. On "busy" connections this is "ok" as the disconnection is continually delayed but it is a flawed approach for AIS reception or any other connection where the data flow may be sparse.

The 50% duty cycle on its own is questionable, but in areas of low activity the probability of missing a high percentage of messages appears to be guaranteed by syncing the 50% duty cycle with the AIS timing cycle. After a successful receipt of a message, the bulk of subsequent message receipts will occur during the "off" period (in low traffic areas).

Why is the TCP connection "manually" reset at all?

I have marked this as critical as I believe that it renders the reliance on AIS in low traffic areas as dangerous.
This task depends upon

Comment by sean d'epagnier (seandepagnier) - Wednesday, 25 January 2017, 02:39 GMT
This is a tough one. Tcp connections can "hang" where reconnecting them gives faster results.

Could it simply wait 60 seconds instead of 5 unless it receives gps sentences then it can revert to 5 seconds?

Can we eliminate the delay of 5 seconds deadtime completely?

Maybe udp will solve this for you?
Comment by Gary Smith (GarySmith) - Wednesday, 25 January 2017, 06:50 GMT
DUP, doesn't guarantee the delivery of the messages which is why I opted for using TCP, I also don't think that it should be used simply because TCP isn't working.

If you believe that you need to take care of a "TOP hang" scenario I would suggest that you increase the delay before disconnecting to 61 seconds. The extra second is to help avoid the"syncing" that I describe. But the off period before reconnecting should DEFINITELY be minimal - milliseconds.

Comment by sean d'epagnier (seandepagnier) - Sunday, 29 January 2017, 02:41 GMT
currently the tcp reconnect logic seems broken to me, it is only working correctly with gpsd