2.1 library(tipc/tipc): TIPC Sockets
AllApplicationManualNameSummaryHelp

  • Documentation
    • Reference manual
    • Packages
      • Transparent Inter-Process Communications (TIPC) libraries
        • The TIPC libraries: library(tipc/...)
          • library(tipc/tipc): TIPC Sockets
            • tipc_socket/2
            • tipc_close_socket/1
            • tipc_open_socket/3
            • tipc_bind/3
            • tipc_listen/2
            • tipc_accept/3
            • tipc_connect/2
            • tipc_get_name/2
            • tipc_get_peer_name/2
            • tipc_setopt/2
            • tipc_receive/4
            • tipc_send/4
            • tipc_canonical_address/2
            • tipc_service_exists/2
            • tipc_service_exists/1
            • tipc_service_probe/1
            • tipc_service_probe/2
            • tipc_service_port_monitor/2
            • tipc_service_port_monitor/3
            • tipc_initialize/0
Availability::- use_module(library(tipc/tipc)).
[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.