EnglishУкраїнськаРocсийский
Вход/Новый

A serie of improvements of the transport subsystem in the output connections

25.10.2020 13:00 Давность: 36 days
Категория: НовостьРазработка

Автор: Roman Savochenko


Transports

The improvements mostly targeted for the connections customization with the related protocols and increasing the reliability and productivity.

Total complexity: 0.5 HD

Sponsored by, on 0.3 HD: Vinnica Poultry Farm

Sponsored by, on 0.1 HD: SVItoVYR Ltd

Sponsored by, on 0.1 HD: Elyor Turaboev, BLUE STAR GROUP Ltd

The subsystem "Transports" includes support for input and output transports. Input transports are designed to serve external requests and send replies. Output transports, by contrast, are designed to send messages and wait for a responses. Therefore, input transports contain configuration of local station, as a listening server, and output transports contain configuration of a remote server to connect. That sort of specialization is typical for the "request-response" mechanism, however, currently input and output transports support the independent transmission and reception of data. Modules of the subsystem "Transports" implement support for both input and output transports.

Opens external link in new windowThe output transport improvements include primarily the reliability increasing, after observing the responses receiving at previous requests and their wrong processing, for the network transports (Opens external link in new windowSockets and Opens external link in new windowSSL):

  • setting the tries default number to 1 from 2;
  • disconnection at the timeout error in any try, besides the initiative external connections;
  • increasing the default timeouts up to "30:2" for providing Opens external link in new windowthe OpenSCADA control interface in maximum delay of long requests processing in 30 seconds;
  • expanding the protocols Opens external link in new windowModBus and Opens external link in new windowSelf OpenSCADA protocol for some checking the response accordance to the request.

The next improvement was the default timeouts customization and specifying the network transports, since the common timeouts "30:2" is very big for protocols whate exclude the long time processing, like to Opens external link in new windowModBus/TCP, and especially Opens external link in new windowModBus/RTU through the Opens external link in new windowTCP or UDP sockets. So, the default timeouts of the output transports set for generic in "10:1", Opens external link in new windowSelfSystem in "20:2" and Opens external link in new windowModBus/RTU through network in "5:0.1". And the network is identified by the method "Opens external link in new windowisNetwork()".

And at the last there was:

  • appended a task of checking the output transports for disconnect the inactive ones in long time, what is usable for the external initiative connections and data sources with the limited connection number;
  • removed the option "To Start" to prevent of performing wrong connection tries at the start, slowing the common starting;
  • prevented from the new connections establishing at the program stop, slowing the common stopping on big number of the data sources working through one common transport;
  • improved the external initiative connections processing in only creation new output transports for new connections, but not reusing, what may be wrong in some cases;
  • renamed the transport messages "start/stop" to "connect/disconnect".


4612