The
Berkeley socket facility provides an
API which can be used to
communicate between named entities using a communication
protocol.
A set of
form,
meaning and
representation rules for
names along with an associated
communications protocol or
protocols is called a
communication domain.
Somewhat more formally, a communication domain is:
- a set of rules describing the syntax (i.e. form) and semantics (i.e. meaning) of names within the domain
- a set of address formats, typically called an address family, which specify how to represent names when using the API with the domain
- a set of protocols, typically called a protocol family, which specify how communication within the domain is to occur (i.e. how the bits get from the sender to the receiver)
Let's (VERY briefly) consider how each of the above three defining characteristics of a communication domain apply to the best known communication domain - i.e. version 4 of the
Internet domain (
IPv4):
- names are called Internet protocol addresses or IP addresses and are 32-bit values (this, roughly speaking, is the syntax of a name).
IP address semantics get quite complicated.
As an example, one aspect of IP address semantics is:
- if the first bit of an IP address is 0 and at least some of the other bits are 1 then the IP address is a class A address
- if the first two bits of an IP address are 10 then the address is a class B address
- if the first three bits of an IP address are 110 then the address is a class C address
- etc (sort-of)
a 32-bit IP address is always represented as a four byte value when using the Berkeley sockets API.
When stored in memory, the IP address is stored in big-endian byte order (i.e. most significant byte first).
the protocols within the Internet domain are WAY too complicated to get into here.
One tiny aspect of the protocol is that data flows across the network in packets or datagrams.
The first four bits of each datagram specifies the version of the protocol (i.e. 4 for version 4 of the Internet domain's protocol)
and the next four bits specifies the length of the packet's header in units of four bytes.
Although not strictly speaking correct, the terms address family, protocol family and communication domain are often treated as
synonyms.
Sidebar: Treating them as synonyms is, strictly speaking, incorrect as the address family and protocol family notions are each only one of the three characteristics which together define a communication domain.
In practical terms, each domain's address family rules are generally (but not necessarily) unique as are each domain's protocol(s).
Consequently, using the terms interchangeably is relatively low risk.
A partial list of communication domains which could, at least in theory, be supported by an implementation of the Berkeley socket facility is:
Sources