From OpenSCADAWiki
Jump to: navigation, search
Translate this page
Other languages:
English • ‎mRussian • ‎Українська
Module Name Version License Source Languages Platforms Type Author Description
Sockets Sockets 4.9 GPL2 tr_Sockets.so en,uk,ru,de x86,x86_64,ARM Transport Roman Savochenko
  Maxim Kochetkov(2014), Maxim Lysenko (2009-2010) — this page initial translation 		Provides sockets based transport. Support network and UNIX sockets. Network socket supports TCP, UDP and RAWCAN protocols.

The module provides support for sockets based transports to the program. Input and output transports is supported, based on network sockets TCP, UDP, UNIX and RAWCAN.

You can add new input and output sockets through the configuration of the transport subsystem in any OpenSCADA configurator.

1 Input transports

Configured and running input transport opens the server socket for the expectation of connection of the clients, besides the initiative connections. In the case of the UNIX socket, the UNIX socket file is created. TCP and UNIX sockets are multi-stream, i.e. when the client connects to a socket of these type, the client socket and the new thread are created in which the client is served. Server socket in this moment switches to the waiting for the request from the new client. Thus the parallel service of the clients is achieved. RAWCAN socket accepts CAN frames from the interface according to the configured filter.

Each input transport is associated with one or several available transport protocols, to which input messages are transmitted. Together with the transport protocols, the mechanism of combining fragmented pieces when sending requests is supported.

Read about the passive acquisition mechanism and initiative connections you can in the corresponding part of the "Data acquisition in OpenSCADA" document.

Fig.1. The generic configuration dialogues of the input socket.

Using the main dialog you can set:

  • State of the transport, that is: status, "Connect", name of the storage (containing the configuration) and information about the active connections.
  • Identifier, name and description of the transport.
  • Address of the transport. The format of the address is listed in the table below.
  • Selecting of the transport protocols.
At.png Empty value of the protocols selection switches the transport mode to creating the associated output transports for each connection ID read from to that input.
  • State "Connect", in which the transport must be switched at start up.

Using the additional dialog you can set:

  • Priority of the transport tasks.
  • [TCP] System input buffer size in kilobytes of the socket. Set to 0 for disabling the user size. Actual size you can see in the status.
  • [TCP] Maximum segment size (MSS) in bytes, for limit the transmitted packages size (segments TCP) on bad link channels. Set to 0 for disabling the user limit for size. Actual size you can see in the status.
  • [TCP|UNIX|RAWCAN] Queue length of the sockets
  • [TCP|UNIX|RAWCAN,!INIT] Maximum number of clients and Maximum number of clients per host.
  • [TCP|UNIX|RAWCAN,!INIT] Keep alive requests — closing the connection after specified number of the requests. Zero value for disabling — never closes.
  • [TCP|UNIX|RAWCAN] Keep alive timeout, seconds — closing the connection after missing requests within a specified time. Zero value for disabling — never closes.
At.png Disabling this feature is not recommended because the TCP/IP network property does not guarantee the server notification about the disconnection, say in the event of a power failure on the client. As a result, the opened client connections can remain forever, and when the limit is reached the server will stop accepting new ones!
  • [TCP,INIT|ASSOC] Timeouts, tries of the initiative connection and the associated output transports, empty for default and separated by '||'. Format of the timeouts and tries is corresponded to ones of the output transport.
  • Protocols' specific custom parameters.
  • Reset all the additional parameters to default values and cleanup the protocols' specific custom parameters.

Features of the formation of the input socket address are given in the table below:

Socket type Address
TCP

[TCP:]{addr}[:{port}[,{port2}[,{portN}]][:{mode}[:{IDmess}]]]
where:

  • addr – address for socket to be opened, empty or "*" address opens socket for all interfaces. There may be as the symbolic representation as well as IPv4 "127.0.0.1" or IPv6 "[::1]".
  • port, port2, portN – network ports on which the socket is sequential opened (at busy the first ones), indication of the character name of the port, according to /etc/services is available.
  • mode – mode of the input socket working:
    • 0 — force closing the connection after the session reception-response.
    • 1(default) — do not close, only by the KeepAlive parameters.
    • 2 — initiative connection. Enables the mode of connecting this input transport to remote host (address instead of local) and switching to the listening state of this host. The "Keep alive timeout" value is used as the timeout of the re-connection of this transport in the absence of activity in order to restore the possibly lost connection.
  • IDmess — identification message of the initiative connection — the mode 2.

Example: "TCP::10001:1" — the TCP socket is available on all interfaces, opened on port 10001 and the connection does not break.

UDP

UDP:{addr}:{port}
where:

  • addr — the same as in the TCP;
  • port — the same as in the TCP.

Example: "UDP:localhost:10001" — the UDP-socket is only available on the "localhost" interface and opened on the port 10001.

RAWCAN

RAWCAN:{if}:{mask}:{id}
where:

  • if — name of the CAN interface;
  • mask, id — mask and identifier of filtering the CAN frames.

Example: "RAWCAN:can0:0:0" — is receiving all CAN frames at the interface "can0".

UNIX

UNIX:{name}:{mode}
where:

  • name — file name of the UNIX socket;
  • mode — the same as in the TCP.

Example: "UNIX:/tmp/oscada:1" — UNIX-socket is available through the file "/tmp/oscada" and it doesn't close the connection.

RAWCAN has some peculiarities in forming the package, that is:

  • the identifier of the received CAN-frame is located at the sender field, and the data in the request field;
  • the sign of the expanded identifier-sender is the presence of the most significant bit (0x80000000).

2 Output transports

Configured and running output transport opens a connection to the specified server. In the case of destroying the connection, output transport is stopped. In order to resume the connection transport must be re-run, that all protocols do automatically.

The transport supports of direct definition of multiple server addresses and processing of all IP addresses in which the symbolic address is resolved, which allows you to build vertical redundancy directly by the transport that will be automatically connected to the first available server.

Fig.2. The generic configuration dialogues of the output socket.

Using the main dialog you can set:

  • State of the transport, that is: status, "Connect" and name of the storage, containing the configuration.
  • Identifier, name and description of the transport.
  • Address of the transport. The format of the addresses is listed in the table below.

Using the additional dialog you can set:

  • Connection timings in the format "{conn}:{next}[:{rep}]", where:
    • conn — maximum connection waiting time, in seconds;
    • next — maximum time for waiting the continue of the response, in seconds;
    • rep — minimum delay time for next request, in seconds.
Can be prioritatile specified into the address field as the second global argument, as such "localhost:123||5:1".
  • Attempts of the requesting both for this transport and protocol, for full requests.
Can be prioritatile specified into the address field as the third global argument, as such "localhost:123||5:1||3".
  • [TCP] Maximum segment size (MSS) in bytes, for limit the transmitted packages size (segments TCP) on bad link channels. Set to 0 for disabling the user limit for size. Actual size you can see in the status.
  • Protocols' specific custom parameters.
  • Reset all the additional parameters to default values and cleanup the protocols' specific custom parameters.

Addresses of output sockets of different types are formed as follows:

Socket type Address
TCP/UDP

[TCP:]{addr}[,{addrN}]:{port}
UDP:{addr}[,{addrN}]:{port}
where:

  • addr — address with which the connection is made. There may be as the symbolic representation as well as IPv4 "127.0.0.1" or IPv6 "[::1]".
  • port — network port with which the connection is made. Indication of the character name of the port according to /etc/services is available.

Example: "TCP:127.0.0.1:7634" — connecting to the port 7634 on the host 127.0.0.1.

RAWCAN

RAWCAN:{if}:{mask}:{id}
where:

  • if — name of the CAN interface;
  • mask, id — mask and identifier of the CAN frames.

Example: "RAWCAN:can0:0:0" — receiving all CAN frames at the interface "can0".

UNIX

UNIX:{name}
where:

  • name — file name of the UNIX socket.

Example: "UNIX:/tmp/oscada" — connecting to the UNIX-socket through the file "/tmp/oscada".

RAWCAN has some peculiarities in forming the paсkcage, that is:

  • sending CAN frames (transparently) to the transport is structured as the struct can_frame. The size of the structure is 16 bytes, where: 4 bytes — identifier, 4 bytes — length, 8 bytes — data. For example, the package: 15 CD 5B 07 08 00 00 00 11 12 13 14 15 16 17 18 . Where:
    • identifier: 123456789 (0x75BCD15) => 15 CD 5B 07, append 0x80 to the last byte if you need for extended one;
    • length: 08 00 00 00 (eight bytes);
    • data: 11 12 13 14 15 16 17 18.
Retrieved from "http://oscada.org/wiki/index.php?title=Modules/Sockets/en&oldid=87770"