socket — Low-level networking interface

Source code: Lib/socket.py

This module provides access to the BSD socket interface. It is available on all modern Unix systems, Windows, MacOS, and probably additional platforms.

Note

Some behavior may be platform dependent, since calls are made to the operating system socket APIs.

Availability: not WASI.

This module does not work or is not available on WebAssembly. See WebAssembly platforms for more information.

The Python interface is a straightforward transliteration of the Unix system call and library interface for sockets to Python’s object-oriented style: the socket() function returns a socket object whose methods implement the various socket system calls. Parameter types are somewhat higher-level than in the C interface: as with read() and write() operations on Python files, buffer allocation on receive operations is automatic, and buffer length is implicit on send operations.

See also

Module socketserver

Classes that simplify writing network servers.

Module ssl

A TLS/SSL wrapper for socket objects.

Socket families

Depending on the system and the build options, various socket families are supported by this module.

The address format required by a particular socket object is automatically selected based on the address family specified when the socket object was created. Socket addresses are represented as follows:

  • The address of an AF_UNIX socket bound to a file system node is represented as a string, using the file system encoding and the 'surrogateescape' error handler (see PEP 383). An address in Linux’s abstract namespace is returned as a bytes-like object with an initial null byte; note that sockets in this namespace can communicate with normal file system sockets, so programs intended to run on Linux may need to deal with both types of address. A string or bytes-like object can be used for either type of address when passing it as an argument.

    Changed in version 3.3: Previously, AF_UNIX socket paths were assumed to use UTF-8 encoding.

    Changed in version 3.5: Writable bytes-like object is now accepted.

  • A pair (host, port) is used for the AF_INET address family, where host is a string representing either a hostname in internet domain notation like 'daring.cwi.nl' or an IPv4 address like '100.50.200.5', and port is an integer.

    • For IPv4 addresses, two special forms are accepted instead of a host address: '' represents INADDR_ANY, which is used to bind to all interfaces, and the string '<broadcast>' represents INADDR_BROADCAST. This behavior is not compatible with IPv6, therefore, you may want to avoid these if you intend to support IPv6 with your Python programs.

  • For AF_INET6 address family, a four-tuple (host, port, flowinfo, scope_id) is used, where flowinfo and scope_id represent the sin6_flowinfo and sin6_scope_id members in struct sockaddr_in6 in C. For socket module methods, flowinfo and scope_id can be omitted just for backward compatibility. Note, however, omission of scope_id can cause problems in manipulating scoped IPv6 addresses.

    Changed in version 3.7: For multicast addresses (with scope_id meaningful) address may not contain %scope_id (or zone id) part. This information is superfluous and may be safely omitted (recommended).

  • AF_NETLINK sockets are represented as pairs (pid, groups).

  • Linux-only support for TIPC is available using the AF_TIPC address family. TIPC is an open, non-IP based networked protocol designed for use in clustered computer environments. Addresses are represented by a tuple, and the fields depend on the address type. The general tuple form is (addr_type, v1, v2, v3 [, scope]), where:

    • addr_type is one of TIPC_ADDR_NAMESEQ, TIPC_ADDR_NAME, or TIPC_ADDR_ID.

    • scope is one of TIPC_ZONE_SCOPE, TIPC_CLUSTER_SCOPE, and TIPC_NODE_SCOPE.

    • If addr_type is TIPC_ADDR_NAME, then v1 is the server type, v2 is the port identifier, and v3 should be 0.

      If addr_type is TIPC_ADDR_NAMESEQ, then v1 is the server type, v2 is the lower port number, and v3 is the upper port number.

      If addr_type is TIPC_ADDR_ID, then v1 is the node, v2 is the reference, and v3 should be set to 0.

  • A tuple (interface, ) is used for the AF_CAN address family, where interface is a string representing a network interface name like 'can0'. The network interface name '' can be used to receive packets from all network interfaces of this family.

    • CAN_ISOTP protocol requires a tuple (interface, rx_addr, tx_addr) where both additional parameters are unsigned long integer that represent a CAN identifier (standard or extended).

    • CAN_J1939 protocol requires a tuple (interface, name, pgn, addr) where additional parameters are 64-bit unsigned integer representing the ECU name, a 32-bit unsigned integer representing the Parameter Group Number (PGN), and an 8-bit integer representing the address.

  • A string or a tuple (id, unit) is used for the SYSPROTO_CONTROL protocol of the PF_SYSTEM family. The string is the name of a kernel control using a dynamically assigned ID. The tuple can be used if ID and unit number of the kernel control are known or if a registered ID is used.

    Added in version 3.3.

  • AF_BLUETOOTH supports the following protocols and address formats:

    • BTPROTO_L2CAP accepts a tuple (bdaddr, psm[, cid[, bdaddr_type]]) where:

      • bdaddr is a string specifying the Bluetooth address.

      • psm is an integer specifying the Protocol/Service Multiplexer.

      • cid is an optional integer specifying the Channel Identifier. If not given, defaults to zero.

      • bdaddr_type is an optional integer specifying the address type; one of BDADDR_BREDR (default), BDADDR_LE_PUBLIC, BDADDR_LE_RANDOM.

      Changed in version 3.14: Added cid and bdaddr_type fields.

    • BTPROTO_RFCOMM accepts (bdaddr, channel) where bdaddr is the Bluetooth address as a string and channel is an integer.

    • BTPROTO_HCI accepts a format that depends on your OS.

      • On Linux it accepts an integer device_id or a tuple (device_id, [channel]) where device_id specifies the number of the Bluetooth device, and channel is an optional integer specifying the HCI channel (HCI_CHANNEL_RAW by default).

      • On FreeBSD, NetBSD and DragonFly BSD it accepts bdaddr where bdaddr is the Bluetooth address as a string.

      Changed in version 3.2: NetBSD and DragonFlyBSD support added.

      Changed in version 3.13.3: FreeBSD support added.

      Changed in version 3.14: Added channel field. device_id not packed in a tuple is now accepted.

    • BTPROTO_SCO accepts bdaddr where bdaddr is the Bluetooth address as a string or a bytes object. (ex. '12:23:34:45:56:67' or b'12:23:34:45:56:67')

      Changed in version 3.14: FreeBSD support added.

  • AF_ALG is a Linux-only socket based interface to Kernel cryptography. An algorithm socket is configured with a tuple of two to four elements (type, name [, feat [, mask]]), where:

    • type is the algorithm type as string, e.g. aead, hash, skcipher or rng.

    • name is the algorithm name and operation mode as string, e.g. sha256, hmac(sha256), cbc(aes) or drbg_nopr_ctr_aes256.

    • feat and mask are unsigned 32bit integers.

    Availability: Linux >= 2.6.38.

    Some algorithm types require more recent Kernels.

    Added in version 3.6.

  • AF_VSOCK allows communication between virtual machines and their hosts. The sockets are represented as a (CID, port) tuple where the context ID or CID and port are integers.