Understanding the term "socket" in the Unix/Linux context

Question

I understand that the term "socket" can mean two different things in the Unix/Linux context:

A Unix socket; the interface between 2 or more processes.
An IP socket; the interface between a process and 1 or more communicating services (or machines).

Is the general definition sums up in these two or there are is more to "socket" in our context?

Perhaps helpful: https://unix.stackexchange.com/q/16311/117549 — Jeff Schaller, Feb 13 '19 at 18:16
A socket is a generic endpoint for communication. See the socket(2) manual. — Kusalananda, Feb 13 '19 at 18:16
@Tomasz I removed that sentence, please consider omitting downvote if downvoted because of that. — , Feb 13 '19 at 18:22

score 0 · Answer 1 · edited Oct 07 '21 at 07:34

http://man7.org/linux/man-pages/man2/socket.2.html

int socket(int domain, int type, int protocol);
DESCRIPTION

socket() creates an endpoint for communication and returns a file descriptor that refers to that endpoint. The file descriptor returned by a successful call will be the lowest-numbered file descriptor not currently open for the process.

The domain argument specifies a communication domain; this selects the protocol family which will be used for communication. These families are defined in <sys/socket.h>. The currently understood formats include:

   Name                Purpose                          Man page

   AF_UNIX, AF_LOCAL   Local communication              unix(7)
   AF_INET             IPv4 Internet protocols          ip(7)
   AF_INET6            IPv6 Internet protocols          ipv6(7)
   AF_IPX              IPX - Novell protocols
   AF_NETLINK          Kernel user interface device     netlink(7)
   AF_X25              ITU-T X.25 / ISO-8208 protocol   x25(7)
   AF_AX25             Amateur radio AX.25 protocol
   AF_ATMPVC           Access to raw ATM PVCs
   AF_APPLETALK        AppleTalk                        ddp(7)
   AF_PACKET           Low level packet interface       packet(7)
   AF_ALG              Interface to kernel crypto API

...

The above list is not comprehensive. One of the others is AF_BLUETOOTH :-).

A socket is something you can call sendmsg() and recvmsg() on. Messages are sent to / received from socket addresses.

There are further details, but they differ between socket types. E.g. -

SOCK_STREAM sockets don't really care about messages. They transport a stream of bytes, like a bi-directional equivalent of a unix pipe. You can use the write() and read() calls without losing anything. (Except for so-called "out of band" data. This is deprecated and was mostly used by telnet.)

For connection-oriented socket types including SOCK_STREAM, you can only send to / receive from one peer address per socket. You must set this in advance using connect(). Or on the other side, bind() to a specific address, and instead of receiving messages, you can receive sockets. That is, you start listening by calling listen(), and then receive each connection by calling accept() which returns a socket.

The type SOCK_SEQPACKET is defined as connection-oriented (and reliable, in-order delivery), but otherwise has conflicting definitions, even within the standard. And for SCTP it may receive connections without using the accept() call I described above. So if you use a SOCK_SEQPACKET protocol, don't make too many assumptions about what that means. Look for information on the specific protocol implementation you are using instead.

The last 2 paragraphs (expect for the 1st sentence) are kind of bogus. Try harder ;-) — , Feb 14 '19 at 11:07
@pizdelect glossing over connect() was certainly a bit optimistic. In case I managed to mis-interpret RFC6458, it is probably better if I can strip that last paragraph down further... any better? — sourcejedi, Feb 14 '19 at 20:15

Understanding the term "socket" in the Unix/Linux context

1 Answers1