gio.socket

A [gio.socket.Socket] is a low-level networking primitive. It is a more or less direct mapping of the BSD socket API in a portable GObject based API. It supports both the UNIX socket implementations and winsock2 on Windows.

[gio.socket.Socket] is the platform independent base upon which the higher level network primitives are based. Applications are not typically meant to use it directly, but rather through classes like [gio.socket_client.SocketClient], [gio.socket_service.SocketService] and [gio.socket_connection.SocketConnection]. However there may be cases where direct use of [gio.socket.Socket] is useful.

[gio.socket.Socket] implements the [gio.initable.Initable] interface, so if it is manually constructed by e.g. [gobject.object.ObjectWrap.new_] you must call [gio.initable.Initable.init_] and check the results before using the object. This is done automatically in [gio.socket.Socket.new_] and [gio.socket.Socket.newFromFd], so these functions can return NULL.

Sockets operate in two general modes, blocking or non-blocking. When in blocking mode all operations (which don’t take an explicit blocking parameter) block until the requested operation is finished or there is an error. In non-blocking mode all calls that would block return immediately with a [gio.types.IOErrorEnum.WouldBlock] error. To know when a call would successfully run you can call [gio.socket.Socket.conditionCheck], or [gio.socket.Socket.conditionWait]. You can also use [gio.socket.Socket.createSource] and attach it to a [glib.main_context.MainContext] to get callbacks when I/O is possible. Note that all sockets are always set to non blocking mode in the system, and blocking mode is emulated in [gio.socket.Socket].

When working in non-blocking mode applications should always be able to handle getting a [gio.types.IOErrorEnum.WouldBlock] error even when some other function said that I/O was possible. This can easily happen in case of a race condition in the application, but it can also happen for other reasons. For instance, on Windows a socket is always seen as writable until a write returns [gio.types.IOErrorEnum.WouldBlock].

[gio.socket.Socket]s can be either connection oriented or datagram based. For connection oriented types you must first establish a connection by either connecting to an address or accepting a connection from another address. For connectionless socket types the target/source address is specified or received in each I/O operation.

All socket file descriptors are set to be close-on-exec.

Note that creating a [gio.socket.Socket] causes the signal SIGPIPE to be ignored for the remainder of the program. If you are writing a command-line utility that uses [gio.socket.Socket], you may need to take into account the fact that your program will not automatically be killed if it tries to write to stdout after it has been closed.

Like most other APIs in GLib, [gio.socket.Socket] is not inherently thread safe. To use a [gio.socket.Socket] concurrently from multiple threads, you must implement your own locking.

Nagle’s algorithm

Since GLib 2.80, [gio.socket.Socket] will automatically set the TCP_NODELAY option on all [gio.types.SocketType.Stream] sockets. This disables

typically does more harm than good on modern networks.

If your application needs Nagle’s algorithm enabled, call [gio.socket.Socket.setOption] after constructing a [gio.socket.Socket] to enable it:

socket = g_socket_new (…, G_SOCKET_TYPE_STREAM, …);
if (socket != NULL)
 {
   g_socket_set_option (socket, IPPROTO_TCP, TCP_NODELAY, FALSE, &local_error);
   // handle error if needed
 }

Fluent builder for [gio.socket.Socket]