The library(socket) provides TCP and UDP inet-domain
sockets from SWI-Prolog, both client and server-side communication. The
interface of this library is very close to the Unix socket interface,
also supported by the MS-Windows winsock API. SWI-Prolog
applications that wish to communicate with multiple sources have three
options:
- Use I/O multiplexing based on wait_for_input/3.
On Windows systems this can only be used for sockets, not for general
(device-) file handles.
- Use multiple threads, handling either a single blocking socket or a
pool using I/O multiplexing as above.
- Using XPCE's class
socket which synchronises socket
events in the GUI event-loop.
Using this library to establish a TCP connection to a server is as
simple as opening a file. See also http_open/3.
dump_swi_homepage :-
setup_call_cleanup(
tcp_connect(www.swi-prolog.org:http, Stream, []),
( format(Stream,
'GET / HTTP/1.1~n\c
Host: www.swi-prolog.org~n\c
Connection: close~n~n', []),
flush_output(Stream),
copy_stream_data(Stream, current_output)
),
close(S)).
To deal with timeouts and multiple connections, threads,
wait_for_input/3 and/or non-blocking
streams (see tcp_fcntl/3) can be
used.
The typical sequence for generating a server application is given
below. To close the server, use close/1 on AcceptFd.
create_server(Port) :-
tcp_socket(Socket),
tcp_bind(Socket, Port),
tcp_listen(Socket, 5),
tcp_open_socket(Socket, AcceptFd, _),
<dispatch>
There are various options for <dispatch>.
The most commonly used option is to start a Prolog thread to handle the
connection. Alternatively, input from multiple clients can be handled in
a single thread by listening to these clients using wait_for_input/3.
Finally, on Unix systems, we can use fork/1
to handle the connection in a new process. Note that fork/1
and threads do not cooperate well. Combinations can be realised but
require good understanding of POSIX thread and fork-semantics.
Below is the typical example using a thread. Note the use of
setup_call_cleanup/3 to guarantee that all
resources are reclaimed, also in case of failure or exceptions.
dispatch(AcceptFd) :-
tcp_accept(AcceptFd, Socket, Peer),
thread_create(process_client(Socket, Peer), _,
[ detached(true)
]),
dispatch(AcceptFd).
process_client(Socket, Peer) :-
setup_call_cleanup(
tcp_open_socket(Socket, StreamPair),
handle_service(StreamPair),
close(StreamPair)).
handle_service(StreamPair) :-
...
Errors that are trapped by the low-level library are mapped to an
exception of the shape below. In this term, Code is a lower
case atom that corresponds to the C macro name, e.g., epipe
for a broken pipe.
Message is the human readable string for the error code
returned by the OS or the same as Code if the OS does not
provide this functionality. Note that Code is derived from a
static set of macros that may or may not be defines for the target OS.
If the macro name is not known, Code is ERROR_nnn,
where nnn is an integer.
error(socket_error(Code, Message), _)
Note that on Windows Code is a wsa* code
which makes it hard to write portable code that handles specific socket
errors. Even on POSIX systems the exact set of errors produced by the
network stack is not defined.
- [det]tcp_socket(-SocketId)
- Creates an INET-domain stream-socket and unifies an identifier to it
with SocketId. On MS-Windows, if the socket library is not
yet initialised, this will also initialise the library.
- [det]tcp_close_socket(+SocketId)
- Closes the indicated socket, making SocketId invalid.
Normally, sockets are closed by closing both stream handles returned by
open_socket/3. There are two cases where tcp_close_socket/1
is used because there are no stream-handles:
- If, after tcp_accept/3, the
server uses 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 tcp_close_socket/1.
- If, after discovering the connecting client with
tcp_accept/3, the server does
not want to accept the connection, it should discard the accepted socket
immediately using tcp_close_socket/1.
- [det]tcp_open_socket(+SocketId,
-StreamPair)
- Create streams to communicate to SocketId. If SocketId
is a master socket (see tcp_bind/2), StreamPair
should be used for
tcp_accept/3. If SocketId
is a connected (see tcp_connect/2)
or accepted socket (see tcp_accept/3), StreamPair
is unified to a stream pair (see stream_pair/3)
that can be used for reading and writing. The stream or pair must be
closed with close/1, which also closes SocketId.
- [det]tcp_open_socket(+SocketId,
-InStream, -OutStream)
- Similar to tcp_open_socket/2,
but creates two separate sockets where tcp_open_socket/2
would have created a stream pair.
- deprecated
- New code should use tcp_open_socket/2
because closing a stream pair is much easier to perform safely.
- [det]tcp_bind(SocketId,
?Address)
- Bind the socket to Address on the current machine. This
operation, together with tcp_listen/2
and tcp_accept/3 implement the server-side
of the socket interface. Address is either an plain Port
or a term HostPort. The first form binds the socket to the given port on
all interfaces, while the second only binds to the matching interface. A
typical example is below, causing the socket to listen only on port 8080
on the local machine's network.
tcp_bind(Socket, localhost:8080)
If Port is unbound, the system picks an arbitrary free
port and unifies Port with the selected port number. Port
is either an integer or the name of a registered service. See also
tcp_connect/4.
- [det]tcp_listen(+SocketId,
+BackLog)
- Tells, after tcp_bind/2, the
socket to listen for incoming requests for connections. Backlog
indicates how many pending connection requests are allowed. Pending
requests are requests that are not yet acknowledged using tcp_accept/3.
If the indicated number is exceeded, the requesting client will be
signalled that the service is currently not available. A commonly used
default value for Backlog is 5.
- [det]tcp_accept(+Socket,
-Slave, -Peer)
- This predicate waits on a server socket for a connection request by a
client. On success, it creates a new socket for the client and binds the
identifier to Slave. Peer is bound to the
IP-address of the client or the atom
af_unix if Socket
is an AF_UNIX socket (see
unix_domain_socket/1).
- [det]tcp_connect(+SocketId,
+Address)
- Connect SocketId. After successful completion, tcp_open_socket/3
can be used to create I/O-Streams to the remote socket. This predicate
is part of the low level client API. A connection to a particular host
and port is realised using these steps:
tcp_socket(Socket),
tcp_connect(Socket, Host:Port),
tcp_open_socket(Socket, StreamPair)
Typical client applications should use the high level interface
provided by tcp_connect/3
which avoids resource leaking if a step in the process fails, and can be
hooked to support proxies. For example:
setup_call_cleanup(
tcp_connect(Host:Port, StreamPair, []),
talk(StreamPair),
close(StreamPair))
If SocketId is an AF_UNIX socket (see unix_domain_socket/1), Address
is an atom or string denoting a file name.
- [det]tcp_connect(+Socket,
+Address, -Read, -Write)
- Connect a (client) socket to Address and return a
bi-directional connection through the stream-handles Read and Write.
This predicate may be hooked by defining socket:tcp_connect_hook/4
with the same signature. Hooking can be used to deal with proxy
connections. E.g.,
:- multifile socket:tcp_connect_hook/4.
socket:tcp_connect_hook(Socket, Address, Read, Write) :-
proxy(ProxyAdress),
tcp_connect(Socket, ProxyAdress),
tcp_open_socket(Socket, Read, Write),
proxy_connect(Address, Read, Write).
- deprecated
- New code should use tcp_connect/3
called as
tcp_connect(+Address, -StreamPair, +Options).
- [det]tcp_connect(+Address,
-StreamPair, +Options)
- [det]tcp_connect(+Socket,
+Address, -StreamPair)
- Establish a TCP communication as a client. The +,-,+ mode is the
preferred way for a client to establish a connection. This predicate can
be hooked to support network proxies. To use a proxy, the hook
proxy_for_url/3 must be
defined. Permitted options are:
- bypass_proxy(+Boolean)
- Defaults to
false. If true, do not attempt to
use any proxies to obtain the connection
- nodelay(+Boolean)
- Defaults to
false. If true, set nodelay on the
resulting socket using tcp_setopt(Socket, nodelay)
The +,+,- mode is deprecated and does not support proxies. It behaves
like tcp_connect/4, but
creates a stream pair (see
stream_pair/3).
| Address | is either a Host:Port term or a file
name (atom or string). The latter connects to an AF_UNIX socket and
requires
unix_domain_socket/1. |
- Errors
proxy_error(tried(ResultList)) is raised by mode (+,-,+) if
proxies are defines by proxy_for_url/3
but no proxy can establsh the connection. ResultList contains
one or more terms of the form
false(Proxy) for a hook that simply failed or error(Proxy, ErrorTerm)
for a hook that raised an exception.- See also
library(http/http_proxy) defines a hook that allows to
connect through HTTP proxies that support the CONNECT
method.
- tcp_select(+ListOfStreams,
-ReadyList, +TimeOut)
- Same as the built-in wait_for_input/3.
Used to allow for interrupts and timeouts on Windows. A redesign of the
Windows socket interface makes it impossible to do better than Windows
select()
call underlying wait_for_input/3. As input
multiplexing typically happens in a background thread anyway we accept
the loss of timeouts and interrupts.
- deprecated
- Use wait_for_input/3
- [semidet,multifile]try_proxy(+Proxy,
+TargetAddress, -Socket, -StreamPair)
- Attempt a socket-level connection via the given proxy to
TargetAddress. The Proxy argument must match the
output argument of proxy_for_url/3.
The predicate tcp_connect/3
(and http_open/3 from the
library(http/http_open))
collect the results of failed proxies and raise an exception no proxy is
capable of realizing the connection.
The default implementation recognises the values for Proxy
described below. The library(http/http_proxy) adds
proxy(Host,Port) which allows for HTTP proxies using the
CONNECT method.
- direct
- Do not use any proxy
- socks(Host, Port)
- Use a SOCKS5 proxy
- [nondet,multifile]proxy_for_url(+URL,
+Hostname, -Proxy)
- This hook can be implemented to return a proxy to try when connecting to URL.
Returned proxies are tried in the order in which they are returned by
the multifile hook try_proxy/4.
Pre-defined proxy methods are:
- direct
- connect directly to the resource
- proxy(Host, Port)
- Connect to the resource using an HTTP proxy. If the resource is not an
HTTP URL, then try to connect using the CONNECT verb,
otherwise, use the GET verb.
- socks(Host, Port)
- Connect to the resource via a SOCKS5 proxy
These correspond to the proxy methods defined by PAC Proxy
auto-config. Additional methods can be returned if suitable clauses
for
http:http_connection_over_proxy/6 or try_proxy/4
are defined.
- [det]tcp_setopt(+SocketId,
+Option)
- Set options on the socket. Defined options are:
- reuseaddr
- Allow servers to reuse a port without the system being completely sure
the port is no longer in use.
- bindtodevice(+Device)
- Bind the socket to Device (an atom). For example, the code
below binds the socket to the loopback device that is typically
used to realise the localhost. See the manual pages for
setsockopt()
and the socket interface (e.g.,
socket(7) on Linux) for details.
tcp_socket(Socket),
tcp_setopt(Socket, bindtodevice(lo))
- nodelay
- nodelay(true)
- If
true, disable the Nagle optimization on this socket,
which is enabled by default on almost all modern TCP/IP stacks. The
Nagle optimization joins small packages, which is generally desirable,
but sometimes not. Please note that the underlying TCP_NODELAY setting
to setsockopt() is not available on all platforms and
systems may require additional privileges to change this option. If the
option is not supported, tcp_setopt/2
raises a domain_error exception. See
Wikipedia
for details.
- broadcast
- UDP sockets only: broadcast the package to all addresses matching the
address. The address is normally the address of the local subnet (i.e.
192.168.1.255). See udp_send/4.
- ip_add_membership(+MultiCastGroup)
- ip_add_membership(+MultiCastGroup,
+LocalInterface)
- ip_add_membership(+MultiCastGroup,
+LocalInterface, +InterfaceIndex)
- ip_drop_membership(+MultiCastGroup)
- ip_drop_membership(+MultiCastGroup,
+LocalInterface)
- ip_drop_membership(+MultiCastGroup,
+LocalInterface, +InterfaceIndex)
- Join/leave a multicast group. Calls
setsockopt() with the
corresponding arguments.
- dispatch(+Boolean)
- In GUI environments (using XPCE or the Windows
swipl-win.exe
executable) this flags defines whether or not any events are dispatched
on behalf of the user interface. Default is
true. Only very specific situations require setting this to false.
- sndbuf(+Integer)
- Sets the send buffer size to Integer (bytes). On Windows this
defaults (now) to 64kb. Higher latency links may benefit from increasing
this further since the maximum theoretical throughput on a link is given
by buffer-size / latency. See https://support.microsoft.com/en-gb/help/823764/slow-performance-occurs-when-you-copy-data-to-a-tcp-server-by-using-a
for Microsoft's discussion
- [det]tcp_fcntl(+Stream,
+Action, ?Argument)
- Interface to the
fcntl() call. Currently only suitable to
deal switch stream to non-blocking mode using:
tcp_fcntl(Stream, setfl, nonblock),
An attempt to read from a non-blocking stream while there is no data
available returns -1 (or end_of_file for read/1),
but
at_end_of_stream/1 fails. On actual
end-of-input,
at_end_of_stream/1 succeeds.
- [semidet]tcp_getopt(+Socket,
?Option)
- Get information about Socket. Defined properties are below.
Requesting an unknown option results in a
domain_error
exception.
- file_no(-File)
- Get the OS file handle as an integer. This may be used for debugging and
integration.
- [det]tcp_host_to_address(?HostName,
?Address)
- Translate between a machines host-name and it's (IP-)address. If
HostName is an atom, it is resolved using
getaddrinfo()
and the IP-number is unified to Address using a term of the
format
ip(Byte1,Byte2,Byte3,Byte4). Otherwise, if Address
is bound to an ip(Byte1,Byte2,Byte3,Byte4) term, it is
resolved by
gethostbyaddr() and the canonical hostname is unified with
HostName.
- To be done
- This function should support more functionality provided by
gethostbyaddr, probably by adding an option-list.
- [det]gethostname(-Hostname)
- Return the canonical fully qualified name of this host. This is achieved
by calling
gethostname() and return the canonical name
returned by getaddrinfo().
- [det]negotiate_socks_connection(+DesiredEndpoint,
+StreamPair)
- Negotiate a connection to DesiredEndpoint over StreamPair.
DesiredEndpoint should be in the form of either:
- hostname : port
ip(A,B,C,D) : port
- Errors
socks_error(Details) if the SOCKS negotiation failed.
Unix domain sockets (sockets with address family AF_UNIX) are
represented as a (socket) file in the file system. They can only be used
to connect processes on the same host. The main advantage of AF_UNIX
sockets is that name conflicts are much easier to manage than port
conflicts and that access is determined by the file system permission
rules.
- unix_domain_socket(-Socket)
- Creates an AF_UNIX-domain stream-socket and unifies an identifier to it
with Socket. This predicate does not exist if the OS does not
support the AF_UNIX address family (e.g. MS-Windows).
Unix domain socket affect tcp_connect/2
(for clients) and tcp_bind/2
and
tcp_accept/3
(for servers). The address is an atom or string that is handled as a
file name. On most systems the length of this file name is limited to
128 bytes (including null terminator), but according to the Linux
documentation (unix(7)), portable applications must keep the address
below 92 bytes. Note that these lengths are in bytes. Non-ascii
characters may be represented as multiple bytes. If the length limit is
exceeded a representation_error(af_unix_name) exception is
raised.
The socket library provides support for UDP sockets. The UDP protocol
is a connection-less and unreliable datagram based
protocol. That means that messages sent may or may not arrive at the
client side, may arrive in a different order then they were sent or even
may arrive multiple times. UDP messages are often used for data
replication, streaming media, or service discovery.
The library library(udp_broadcast) provides a high-level
interface that builds on top of the library(broadcast)
facilitating an unreliable
publish-subscribe pattern based communication channel. The
library(udp_broadcast) library supports multiple network
architectures, e.g., classical LAN broadcasting, multicast and
unicast.
- udp_socket(-Socket)
- Similar to tcp_socket/1,
but create a socket using the
SOCK_DGRAM protocol, ready
for UDP connections.
- udp_receive(+Socket,
-Data, -From, +Options)
- Wait for and return the next datagram. The data is returned as a Prolog
string object (see string_to_list/2). From
is a term of the format ip(A,B,C,D):Port
indicating the sender of the message. Socket can be waited
for using wait_for_input/3.
Defined Options:
- as(+Type)
- Defines the returned term-type. Type is one of
atom, codes, string (default) or
term. The value term causes the data to be
parsed to a Prolog string.
- encoding(+Encoding)
- Specify the encoding used to intepret the message. It is one of
octet. iso_latin_1, text
or
utf8.
- max_message_size(+Size)
- Specify the maximum number of bytes to read from a UDP datagram. Size
must be within the range 0-65535. If unspecified, a maximum of 4096
bytes will be read.
The typical sequence to receive UDP data is:
receive(Port) :-
udp_socket(Socket),
tcp_bind(Socket, Port),
repeat,
udp_receive(Socket, Data, From, [as(atom)]),
format('Got ~q from ~q~n', [Data, From]),
fail.
- udp_send(+Socket,
+Data, +To, +Options)
- Send a UDP message. Data is a string, atom or code-list providing the
data. To is an address of the form Host:Port
where Host is either the hostname or a term ip/4.
Defined Options are:
- encoding(Encoding)
- Specifies the encoding to use for the string. See udp_receive/4
for details.
- as(Type)
- This uses the same values for Type as the
as(Type)
option of udp_receive/4.
The are interpreted differently though. No Type corresponds
to CVT_ALL of PL_get_chars(). Using atom
corresponds to CVT_ATOM and any of string or
codes is mapped to CVT_STRING|CVT_LIST,
allowing for a SWI-Prolog string object, list of character codes or list
of characters. Finally, term maps to CVT_WRITE_CANONICAL.
This implies that arbitrary Prolog terms1write_canonical/2
does not support blobs nor cyclic terms
can be sent reliably using the option list [as(term),encoding(utf8)]),
using the same option list for udp_receive/4.
A simple example to send UDP data is:
send(Host, Port, Message) :-
udp_socket(S),
udp_send(S, Message, Host:Port, []),
tcp_close_socket(S).
A broadcast is achieved by using tcp_setopt(Socket, broadcast)
prior to sending the datagram and using the local network broadcast
address as a ip/4
term.
The normal mechanism to discover a service on the local network is
for the client to send a broadcast message to an agreed port. The server
receives this message and replies to the client with a message
indicating further details to establish the communication.
0 
