TCP timeout after network glitches

[singletone]

I have several 132's and love them.  I have recently been stuck with a somewhat unstable network that causes disconnects several times a day.  Because the TCP ports only have one socket, they will have to time out for the period set in SETCTO =??.  Has anyone found a way to reconnect instantly?  I was thinking I could alternate between ports 3 and 4 but it would be nice if the ports had multiple sockets capability even if it was just 2-3 sockets.

[Jan]

You're absolutely right. Under normal circumstances, when the client disconnects from the encoder, the port is available immediately for reconnect. In unstable networks when the connection is not terminated correctly (no disconnect is detected), the encoder releases the port after elapsing the timeout specified by SETCTO= command (16 minutes by default). The timeout counts from the last reception of incoming data.

The encoder supports multiple sockets (connections) on the port but that option is disabled in current software. It is now limited to one connection per one port to simplify the socket handling. I'll give you more info soon.

[Jan]

It has been decided to implement a new option to the Port 3 and Port 4 settings (when the RDS encoder acts as a TCP server). That option, if enabled, will allow a new client connection to be established although another connection already exists on the same port. That connection will be closed by the RDS encoder so only the new connection will remain.

Reasons for this solution:
Any TCP host can unambiguously detect dead (half-open) connection only by sending some data to that connection. Otherwise no error is given by the TCP protocol. The RDS encoder naturally only receives data and does not send any data without receiving a query (which cannot be received from dead connection). Sending some empty message (keep-alive message) at regular intervals would violate with all standard RDS encoder communication protocols.

Related information: www.google.com/search?q=tcp+half+open+connection

[singletone]

Thank you Jan.  This will be great for the Sonicwall VPN since I learned they "renegotiate" the tunnel every few hours.  During this time, it produces the half open problem.  Please let me know how to implement when ready.

[Jan]

Interesting information about that VPN solution 
A link to the update will be first published here for testing.

[Jan]

OK, so the update is here:

http://pira.cz/rds/p132fwup.zip

For now, it is an unofficial (testing) version, but seems to be stable. We would welcome any reports.

The documentation will be updated later so a few words will be published here.

New features in version 2.1e:

Added option for port 3 and 4, server mode: new connection can be established immediately, although previous connection has not yet been released.
RTTYPE=3 option added, which overrides UECP RT toggle bit.
Existing reserved (unused) GPIO pin now works as TA output.
New command added: SETFEAT.
Dynamic group sequence added for Radiotext.
Selectable RT+ group type (11A/13A).

Instructions step by step:

The GUI hasn't been updated yet, so the TCP setup must be made using the terminal (command line console). Example:

SETPORT3=AT+iLTCP:23,2$

Enables the new feature for port 3, TCP port 23. After the device reset, you'll be able to establish a new connection regardless of the socket status, i.e. even though the previous connection has not yet been released.

Another useful feature is the dynamic group sequence for Radiotext (RT). It is a solution for situations when it is not easy to find a good balance between RT update speed and occupation of the channel by RT groups 2A. The dynamic group sequence temporarily doubles the RT group rate after the RT is changed. To enable this, type

SETFEAT=0001

Of course, this firmware update applies to the P232 and P332 model as well.