Viper SC+™ IP Router for Licensed Spectrum PN 001-5008-000 Rev. C
| Page 181
POLLING REMOTE PLCS NON SEQUENTIALLY
Polling messages non-sequentially, where several poll requests are initiated asynchronously overlapping each other, is
not recommended since it is less efficient. But if the system cannot be converted or designed with sequential polling,
then some of the approaches used above for unsolicited messaging control (adding free on-air time) may need to be
applied.
MESSAGING WITH TCP AND TCP CONNECTION TIMEOUT
TCP is a stream protocol where lost parts of the data stream are being retried by the low-level TCP driver of the PLC.
Often the higher-level application of the PLC can function with TCP, UDP, or other. These applications therefore have
message timeouts to allow retransmission of a presumed lost or delayed message. With TCP this is not really required
since the low level driver will keep on trying and will only terminate the connection when tries are exhausted.
It is important to set the application message timeout long enough to minimize the application retrying above the TCP
driver retries. For example, if the reply for message 1 was not received in time due to temporarily network congestion
or outage, and the TCP low-level driver still keeps on trying, then the application could end-up sending additional
messages (2, 3, and so on). During this congestion or temporarily short network outage period, the retried messages by
the application could result in a backlog of outstanding messages and then on recovery resulting in a temporary sort of
network storm that may take some time to recover or sometimes turns into a TCP connection failure or termination.
For this case it is better for the application to wait longer than trying to resend the message too quickly resulting in
possible multiple responses or connection problems.
The application message timeout should not be made way too long since it may be used by the PLC application to
terminate the connection.
A good value for TCP connections timeout that seems to work well is 20 seconds. This gives 20 seconds time to make a
new TCP connection. On busy or temporarily congested / multi hop system, 25 or 30 seconds works better. These
settings are required for master PLC and remote PLCs.
For message timeout 10 seconds is often good, but on busy or temporarily congested / multi hop system, 15 seconds
works better. These settings are required for master PLC and remote PLCs.
If the system is often overloaded then monitoring is required to determine the cause and the delays. Traffic could be
reduced or timeout needs to be increased.
OPENING A NEW CONNECTION WHILE PREVIOUS TCP CONNECTION IS ST ILL IN PROGRESS
The PLC should not re-open a new connection while the last one for the same remote PLC is still in progress.
When a TCP connection is attempted by the application the low level TCP driver will perform several retries to achieve
the connection. Often the original TCP connection SYN message is sent then two more are retried using exponential
backoff timeouts. This often results in 21 seconds (3 +6+12) for all 3 tries. If the PLC application or sometimes the TCP
driver does not wait for the timeout to occur before starting a new connection, then multiple connections to the same
destination could be in progress. If the PLC only accepts responses from the last connection attempted, all previous
delayed SYN-ACK responses are ignored or terminated.
