2.1 library(tipc/tipc): TIPC Sockets

author

Jeffrey Rosenwald (JeffRose@acm.org)

See also

http://tipc.sf.net, http://www.erlang.org

Compatibility

Linux only

Transparent Inter-Process Communication (TIPC) provides a flexible, reliable, fault-tolerant, high-speed, and low-overhead framework for inter-process communication between federations of trusted peers, operating as a unit. It was developed by Ericsson AB, as a means to provide for communications between Common Control Systems processes and Network Element peers in telephone switching systems, sometimes operating at arm's length on different line cards or mainframes. Delegation of responsibility in this way is one of the fundamental precepts of the Erlang programming system, also developed at Ericsson. TIPC represents a more generalized version of the same behavioral design pattern. For an overview, please see: tipc_overview.md.

Errors

The TIPC module uses the error handling functions from library(socket) and therefore all the functions below may throw error(socket_error(Code, Message)) where Code is the lowercase version of the C-macro error code and Message is an atom describing the error in a human friendly format, depending on the current locale. See the socket library for details.

[det]tipc_socket(-SocketId, +SocketType)

Creates a TIPC-domain socket of the type specified by SocketType, and unifies it to an identifier, SocketId.

SocketType

is one of the following atoms: rdm - unnumbered, reliable datagram service, dgram - unnumbered, unreliable datagram service, seqpacket - numbered, reliable datagram service, and stream - reliable, connection-oriented byte-stream service

[det]tipc_close_socket(+SocketId)

Closes the indicated socket, making SocketId invalid. In stream applications, sockets are closed by closing both stream handles returned by tipc_open_socket/3. There are two cases where tipc_close_socket/1 is used because there are no stream-handles:

• After tipc_accept/3, the server does a fork/1 to handle the client in a sub-process. In this case the accepted socket is not longer needed from the main server and must be discarded using tipc_close_socket/1.
• If, after discovering the connecting client with tipc_accept/3, the server does not want to accept the connection, it should discard the accepted socket immediately using tipc_close_socket/1.

SocketId

the socket identifier returned by tipc_socket/2 or tipc_accept/3.

[det]tipc_open_socket(+SocketId, -InStream, -OutStream)

Opens two SWI-Prolog I/O-streams, one to deal with input from the socket and one with output to the socket. If tipc_bind/3 has been called on the socket, OutStream is useless and will not be created. After closing both InStream and OutStream, the socket itself is discarded.

[det]tipc_bind(+Socket, +Address, +ScopingOption)

Associates/disassociates a socket with the name/3 or name_seq/3 address specified in Address. It also registers/unregisters it in the topology server name table. This makes the address visible/invisible to the rest of the network according to the scope specified in ScopingOption. ScopingOption is a grounded term that is one of:

scope(Scope)

where Scope is one of: zone, cluster, or node. Servers may bind to more than one address by making successive calls to tipc_bind/3, one for each address that it wishes to advertise. The server will receive traffic for all of them. A server may, for example, register one address with node scope, another with cluster scope, and a third with zone scope. A client may then limit the scope of its transmission by specifying the appropriate address.

no_scope(Scope)

where Scope is as defined above. An application may target a specific address for removal from its collection of addresses by specifying the address and its scope. The scoping option, no_scope(all), may be used to unbind the socket from all of its registered addresses. This feature allows an application to gracefully exit from service. Because the socket remains open, the application may continue to service current transactions to completion. TIPC however, will not schedule any new work for the server instance. If no other servers are available, the work will be rejected or dropped according to the socket options specified by the client.

Connection-oriented, byte-stream services are implemented with this predicate combined with tipc_listen/2 and tipc_accept/3. Connectionless, datagram services may be implemented using tipc_receive/4.

Note that clients do not need to bind to any address. Its port-id is sufficient for this role. And server sockets (e.g. those that are bound to name/3 or name_seq/3, addresses) may not act as clients. That is, they may not originate connections from the socket using tipc_connect/2. Servers however, may originate datagrams from bound sockets using tipc_send/4. Please see the TIPC programmers's guide for other restrictions.

[det]tipc_listen(+Socket, +Backlog)

Listens for incoming requests for connections. Backlog indicates how many pending connection requests are allowed. Pending requests are requests that are not yet acknowledged using tipc_accept/3. If the indicated number is exceeded, the requesting client will be signalled that the service is currently not available. A suggested default value is 5.

[det]tipc_accept(+Socket, -Slave, -Peer)

Blocks on a server socket and waits for connection requests from clients. On success, it creates a new socket for the client and binds the identifier to Slave. Peer is bound to the TIPC address, port_id/2, of the client.

[det]tipc_connect(+Socket, +TIPC_address)

Provides a connection-oriented, client-interface to connect a socket to a given TIPC_address. After successful completion, tipc_open_socket/3 may be used to create I/O-Streams to the remote socket.

[det]tipc_get_name(+Socket, -TIPC_address)

Unifies TIPC_address with the port-id assigned to the socket.

[det]tipc_get_peer_name(+Socket, -TIPC_address)

Unifies TIPC_address with the port-id assigned to the socket that this socket is connected to.

[det]tipc_setopt(+Socket, +Option)

Sets options on the socket. Defined options are:

importance(+Priority)

Allow sockets to assign a priority to their traffic. Priority is one of : low (default), medium, high, or critical.

src_droppable(+Boolean)

Allow TIPC to silently discard packets in congested situations, rather than queuing them for later transmission.

dest_droppable(+Boolean)

Allow TIPC to silently discard packets in congested situations, rather than returning them to the sender as undeliverable.

conn_timeout(+Seconds)

Specifies the time interval that tipc_connect/2 will use before abandoning a connection attempt. Default: 8.000 sec.

[det]tipc_receive(+Socket, -Data, -From, +OptionList)

Waits for, and returns the next datagram. Like its UDP counterpart, the data are returned as a Prolog string object (see string_codes/2). From is an address structure of the form port_id/2, indicating the sender of the message.

Defined options are:

as(+Type)

Defines the returned term-type. Type is one of atom, codes or string (default).

nonblock

Poll the socket and return immediately. If a message is present, it is returned. If not, then an exception, error(socket_error(eagain, Message), _), will be thrown. Users are cautioned not to "spin" unnecessarily on non-blocking receives as they may prevent the system from servicing other background activities such as XPCE event dispatching.

The typical sequence to receive a connectionless TIPC datagram is:

receive :-
        tipc_socket(S, dgram),
        tipc_bind(S, name(18888, 10, 0), scope(zone)),
        repeat,
            tipc_receive(Socket, Data, From, [as(atom)]),
            format('Got ~q from ~q~n', [Data, From]),
            Data == quit,
        !, tipc_close_socket(S).

[det]tipc_send(+Socket, +Data, +To, +Options)

sends a TIPC datagram to one or more destinations. Like its UDP counterpart, Data is a string, atom or code-list providing the data to be sent. To is a name/3, name_seq/3, or port_id/2 address structure. See tipc_overview.txt, for more information on TIPC Address Structures. Options is currently unused.

A simple example to send a connectionless TIPC datagram is:

send(Message) :-
        tipc_socket(S, dgram),
        tipc_send(S, Message, name(18888, 10,0), []),
        tipc_close_socket(S).

Messages are delivered silently unless some form of congestion was encountered and the dest_droppable(false) option was issued on the sender's socket. In this case, the send succeeds but a notification in the form of an empty message is returned to the sender from the receiver, indicating some kind of delivery failure. The port-id of the receiver is returned in congestion conditions. A port_id(0,0), is returned if the destination address was invalid. Senders and receivers should beware of this possibility.

[det]tipc_canonical_address(-CanonicalAddress, +PortId)

Translates a port_id/2 address into canonical TIPC form:

tipc_address(Zone, Cluster, Node, Reference)

It is provided for debugging an printing purposes only. The canonical address is not used for any other purpose.

[semidet]tipc_service_exists(+Address, +Timeout)

[semidet]tipc_service_exists(+Address)

Interrogates the TIPC topology server to see if a service is available at an advertised Address.

Address	is one of: name(Type, Instance, Domain) or name_seq(Type, Lower, Upper). A name/3, address is translated to a name_seq/3, following, where Lower and Upper are assigned the value of Instance. Domain is unused and must be zero. A name_seq(Type, Lower, Upper) is a multi-cast address. This predicate succeeds if there is at least one service that would answer according to multi-cast addressing rules.
Timeout	is optional. It is a non-negative real number that specifies the amount of time in seconds to block and wait for a service to become available. Fractions of a second are also permissible.

[nondet]tipc_service_probe(?Address)

[nondet]tipc_service_probe(?Address, ?PortId)

Allows a user to discover the instance ranges and/or port-ids for a particular service.

Address	is a name_seq/3 address. The address type must be grounded.
PortId	is unified with the port-id for a specific name_sequence address.

[det]tipc_service_port_monitor(+Addresses, :Goal)

[det]tipc_service_port_monitor(+Addresses, :Goal, ?Timeout)

Monitors a collection of worker threads that are bound to a list of Addresses. A single port monitor may be used to provide surveillance over workers that are providing a number of different services. For a given address type, discontiguous port ranges may be specified, but overlapping port ranges may not. Goal for example, may simply choose to broadcast the notification, thus delegating the notification event handling to others.

Addresses	is a list of name/3 or name_seq/3 addresses for the services to be monitored.
Goal	is a predicate that will be called when a worker's publication status changes. The Goal is called exactly once per event with its the last argument unified with the structure: published(-NameSeq, -PortId) when the worker binds its socket to the address. withdrawn(-NameSeq, -PortId) when the worker unbinds its socket from the address.
Timeout	is optional. It is one of: Timeout a non-negative real number that specifies the number of seconds that surveillance is to be continued. infinite causes the monitor to run forever in the current thread (e.g. never returns). detached(-ThreadId) causes the monitor to run forever as a separate thread. ThreadId is unified with the thread identifier of the monitor thread. This is useful when the monitor is required to provide continuous surveillance, while operating in the background.

[semidet]tipc_initialize

causes the TIPC service and the TIPC stack to be initialized and made ready for service. An application must call this predicate as part of its initialization prior to any use of TIPC predicates. Please note the change of the API.