GSocket

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.ObjectG.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.Sockets 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 Nagle’s algorithm as it 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
  }