TCP/IPv6 Protocol

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

Syntax

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

Description

The TCP/IPv6 communications protocol supports communications over Ethernet via IPv6. It is identified by using tcpip6 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/IPv6 hostname that is resolved via the normal name resolution mechanisms (DNS, hosts file, etc.) or it may be an IP address in IPv6 notation (eg. [fe80::abcd:beef:a31e:f123]). IPv6 addresses should be given in square brackets.

When connecting as a client using a link-local IPv6 address, the address should include a zone identifier to indicate which network interface is being used. The zone identifier appears at the end of the address following a percent sign. It is either a number or the name of the interface. For example, on a Linux system using eth0 it may be:

[fe80::abcd:beef:a31e:f123%eth0]

Or if eth0 is the third interface as shown by ifconfig:

[fe80::abcd:beef:a31e:f123%3]

On Windows systems, the ipconfig command shows the numeric zone identifier already as part of the IPv6 address.

Note that the zone identifier specified should indicate the network interface on the system using the address, not the network interface on the system to which the address refers. For example, a client on a Linux system connecting to a Windows server would specify the IPv6 address of the Windows server, but the link identifier of the network interface on the Linux system. For instance, if the Windows server IPv6 address is fe80::dcba:abcd:1234:5678 then the Linux system would connect to it through its eth0 network interface using the full IPv6 address of:

[fe80::dcba:abcd:1234:5678%eth0]

The port in the URI determines the TCP/IPv6 port used for communications. For example, the URI tcpip6://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/IPv6 ports

Models cannot share the same TCP/IPv6 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/IPv6 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/IPv6 port.

Also, IPv6 and IPv4 may not be able to use the same port number either, particularly on Linux systems.

Polling restrictions

The TCP/IPv6 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/IPv6 send and receive buffers to a specific range of values. For example, RT-TCP/IPv6 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/IPv6 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/IPv6 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/IPv6 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/IPv6 receive buffer. If this option is not set then the system default is used.

close_timeout

When a TCP/IPv6 connection is closed, the TCP/IPv6 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/IPv6 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/IPv6 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/IPv6 protocol to attempt to retry establishing the connection up to the specified number of times before giving up.

Driver

The driver supporting TCP/IPv6 communications is called qrt_tcpip6.

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.