'tcp' and 'tcpl' URLs
Specifying tcp or tcpl in the transport field of a URL indicates a server or client, respectively, TCP transport as described in the URLs section above. For tcp transports, the URL indicates the listening socket on which to accept incoming connections. For tcpl transports the URL specifies the TCP address to use as a global identifier.
For example,
scheme:/tcp/[hostname]:port]
scheme:/tcpl/[hostname]:port]
in which hostname can be any one of:
•A domain name (such as foo.oti.com or localhost)
•A dotted IP address (such as 192.230.48.9)
•Empty, which represents INADDR_ANY (0.0.0.0)
And port can be any one of:
•Not specified, in which case a default specified by the transport's configuration is used
•A non-zero number, which is used directly (such as 25)
•A well-known service name (such as smtp, ftp, or dst) usually found in the file /etc/services (UNIX) or \tcpip\etc\services (Windows/Novell). These must be TCP-style services.
You can get varying levels of flexibility depending on how precisely they specify addresses. For example, a tcp transport on a machine with two IP addresses can be specified using a precise IP name (foo.oti.com) or number (128.43.87.123). This transport will only accept connections on the specified interface. If the host name is not specified (representing INADDR_ANY), then the transport will accept connections on any of the machine's interfaces. Note that when connecting to a remote endpoint, you must always specify a host name or an error will be returned.
If the port is 0 (zero), which may be either given explicitly or be configured as the default port in the configuration, then the stack will automatically allocate an unused port on which to listen. Doing this will not change the contents of the endpoint; its URL will not be updated with the new port. Rather, the set of URLs describing that particular endpoint can be obtained by sending accessibleUrls to the endpoint.
While client TCP transports do not have a listening socket, they do bind with the socket corresponding to their URL. This feature allows the addresses which are not fully specified to be automatically completed with values which are guaranteed to be globally unique. It is by these values that the endpoint will be known on remote machines.
As to URLs, keep the following in mind:
•URLs supplied to a remote machine should always be as a result of an accessibleUrls operation. It is vital that the correct URLs be supplied as URLs are used to build endpoints which are used as the keys in the transport's internal connection table. Mismatches in the peer's view of the same endpoint can result in duplicate connections or, in the case of a client transport, an inability of the server to send messages to the client.
•It is highly recommended that TCP URLs not be specified using INADDR_ANY as the host. The SST TCP Transport does not currently handle connections with multiple interfaces. For example, if machine A is known as foo.com to machine B, and as bar.com to machine C, when it sends a message to B, it may go out as either foo.com or bar.com. However, if it goes out as the latter, B has no knowledge of a connection with that machine and the message is rejected.
•The tcp and tcpl transport configurations are defined with the noDelay option set. As a result, they are not suitable for sending and receiving large amounts of data.
Last modified date: 04/20/2020