Package org.gnome.gio

Class Socket

java.lang.Object
org.javagi.base.ProxyInstance
org.gnome.gobject.TypeInstance
org.gnome.gobject.GObject
org.gnome.gio.Socket
All Implemented Interfaces:
DatagramBased, Initable, Proxy
@Generated("io.github.jwharm.JavaGI") public class Socket extends GObject implements DatagramBased, Initable
A GSocket 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.

GSocket 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 SocketClient, SocketService and SocketConnection. However there may be cases where direct use of GSocket is useful.

GSocket implements the Initable interface, so if it is manually constructed by e.g. GObject() you must call Initable.init(org.gnome.gio.Cancellable) and check the results before using the object. This is done automatically in Socket() and fromFd(int), 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 G_IO_ERROR_WOULD_BLOCK error. To know when a call would successfully run you can call conditionCheck(java.util.Set<org.gnome.glib.IOCondition>), or conditionWait(java.util.Set<org.gnome.glib.IOCondition>, org.gnome.gio.Cancellable). You can also use createSource(java.util.Set<org.gnome.glib.IOCondition>, org.gnome.gio.Cancellable) and attach it to a GLib.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 GSocket.

When working in non-blocking mode applications should always be able to handle getting a G_IO_ERROR_WOULD_BLOCK 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 G_IO_ERROR_WOULD_BLOCK.

GSockets 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 GSocket causes the signal SIGPIPE to be ignored for the remainder of the program. If you are writing a command-line utility that uses GSocket, 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, GSocket is not inherently thread safe. To use a GSocket concurrently from multiple threads, you must implement your own locking.

Nagle’s algorithm
Since GLib 2.80, GSocket will automatically set the TCP_NODELAY option on all G_SOCKET_TYPE_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 setOption(int, int, int) after constructing a GSocket 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
   }
Since:
2.22