TCP/IP Protocol :: RCP Communications Protocols

navigation bar

Table of Contents >Quanser Rapid Control Prototyping Toolkit >Communication Protocols >

TCP/IP Protocol

The TCP/IP protocol supports communications via TCP/IP sockets.

Syntax

tcpip://hostname:port?option=value,... % Use TCP/IP communications with host "hostname" on port "port"

Description

The TCP/IP communications protocol supports communications over Ethernet. It is identified by using tcpip as the protocol name in a URI.

The hostname in the URI is used when connecting to a remote host. It is ignored when establishing a listening connection. The hostname may be a standard TCP/IP hostname that is resolved via the normal name resolution mechanisms (DNS, hosts file, etc.) or it may be an IP address in dot notation (eg. 192.168.0.10).

The port in the URI determines the TCP/IP port used for communications. For example, the URI tcpip://quanser-dev:18000 refers to a machine called quanser-dev listening on port 18000. The default port number is 18000. For listening streams, the port should not be used by other components in the system.

Hint

For low-latency applications, disable the Nagle algorithm using the nagle option. Otherwise the data may appear quantized or will arrive later than expected. However, for high bandwidth applications, the Nagle algorithm should be left enabled (the default).

Limitations

Polling restrictions

Warning The TCP/IP protocol cannot distinguish between the completion of the connection and the connection being ready to flush more data over the communication channel when polling a non-blocking stream. Hence do not attempt to poll on these two events at the same time. Poll for completion of the connection first.

Listening streams can only poll for client connections ready to be accepted, because listening streams cannot send or receive data. Likewise, streams created with the CL Stream Connect or CL Stream Accept VIs cannot poll for pending client connections because such streams are not listening streams.

Send and receive buffer sizes

Warning The target operating system may limit the TCP/IP send and receive buffers to a specific range of values. Also, setting the send and/or receive buffer sizes to a value less than the system default has been known to cause severe performance degradation on some systems.

Options

backlog

Set this option to the number of client connections that may be pending on a listening connection. Client connections are queued until the connection is accepted. The backlog parameter determines the length of this queue. This parameter is only used for listening connections and is ignored otherwise.

nagle

Set this option to enable or disable the Nagle algorithm. A value of "0", "n" or "no" will disable the Nagle algorithm. A value of "1", "y" or "yes" will enable the Nagle algorithm. The Nagle algorithm attempts to optimize network bandwidth usage by sending complete Ethernet packets. The Nagle algorithm delivers better bulk performance when streaming data to a remote host but can introduce delays in transmission that are undesirable for applications such as teleoperation where delays are generally destabilizing. The Nagle algorithm is enabled by default because the TCP/IP protocol is often used for connecting to VIs on remote targets in order to stream data for plotting to another VI.

bufsize

Set this option to set the size of the TCP/IP send and receive buffers. Setting this option is equivalent to setting both the sndsize and rcvsize options to this value. If none of these options are set then the system default is used.

sndsize

Set this option to set the size of the TCP/IP send buffer. If this option is not set then the system default is used.

rcvsize

Set this option to set the size of the TCP/IP receive buffer. If this option is not set then the system default is used.

close_timeout

When a TCP/IP connection is closed, the TCP/IP driver attempts to perform a graceful shutdown by first disabling send operations locally and then entering a loop to receive data from the peer. Shutting down send operations locally notifies the peer that no more data will be sent so the peer's receive operations will return any remaining data in the network buffer and then return 0 to indicate that the connection has been closed at the other end. The peer then performs a graceful shutdown also, so that the receive loop at this end finishes receiving any remaining data in the network buffer and then exits the loop and closes the connection. In this way, the local receive loop prevents any send operations at the peer from blocking or returning an error, and both ends of the connection close gracefully and no errors are returned. However, if the peer is misbehaving and never does a receive operation, so that it never detects that our end has begun closing the connection, then the receive loop at our end would block indefinitely. To prevent this situation, this loop is timed. If a receive operation in this loop takes more than the time period specified in the close_timeout option then the loop exits and the connection is closed forcefully. Send operations at the peer, in this case, will return a QERR_CONNECTION_SHUTDOWN error indicating that the connection has been shutdown ungracefully. Unlike the shared memory driver, this timeout is not used if the stream_shutdown function has been called and a receive operation is called locally. In this case, the receive operation will only block for up to certain amount of time before the TCP/IP stack notifies it that an error has occurred because the peer is not closing its end of the connection. However, this timeout is determined by the TCP/IP stack and can be 30 to 60 seconds long or longer.

connect_timeout

When connecting to a remote peer in which the remote peer is not responding, the TCP/IP stack waits a certain amount of time before it decides that it cannot connect.

Driver

The driver supporting TCP/IP communications is called qrt_tcpip.

Targets

Target	Supported	Comments
RCP Windows (64-bit) Target	Yes	Fully supported.