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. In particular, two models cannot share the same port number if they will be running at the same time on the same target because models establish a listening connection on the port specified in the model URI.

Limitations

Sharing of TCP/IP ports

Models cannot share the same TCP/IP port if they will be running at the same time on the same target. Models use their model URI to establish a listening connection for external-mode connections from Simulink. The second model will load but exit immediately because the TCP/IP port will be in use by the first model. If the models will not be run at the same time then they may use the same TCP/IP port.

Polling restrictions

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 stream_connect or stream_accept functions cannot poll for pending client connections because such streams are not listening streams.

Send and receive buffer sizes

The target operating system may limit the TCP/IP send and receive buffers to a specific range of values. For example, RT-TCP/IP under RTX limits the buffer sizes to 64K bytes. 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 models on remote targets using external mode, which streams data for Scopes and other Sink blocks back to the host.

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.

retries

Sometimes connecting to a remote port fails because the remote application is not yet listening on the port, or a timeout occurs before the connection succeeds. The retries option tells the TCP/IP protocol to attempt to retry establishing the connection up to the specified number of times before giving up.

Driver

The driver supporting TCP/IP communications is called qrt_tcpip.

Targets

See Also

• Communications
• QUARC Communications Protocols
• Communications Using the C Language

Copyright ©2024 Quanser Inc. This page was generated 2024-10-17. Submit feedback to Quanser about this page.