What is the difference between AF_INET and PF_INET constants?
Question:
Looking at examples about socket programming, we can see that some people use AF_INET while others use PF_INET. In addition, sometimes both of them are used at the same example. The question is: Is there any difference between them? Which one should we use?
If you can answer that, another question would be… Why there are these two similar (but equal) constants?
What I’ve discovered, so far:
The socket manpage
In (Unix) socket programming, we have the socket() function that receives the following parameters:
int socket(int domain, int type, int protocol);
The manpage says:
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>.
And the manpage cites AF_INET as well as some other AF_ constants for the domain parameter. Also, at the NOTES section of the same manpage, we can read:
The manifest constants used under 4.x BSD for protocol families are
PF_UNIX, PF_INET, etc., while AF_UNIX etc. are used for address families.
However, already the BSD man page promises: “The protocol family
generally is the same as the address family”, and subsequent standards
use AF_* everywhere.
The C headers
The sys/socket.h does not actually define those constants, but instead includes bits/socket.h. This file defines around 38 AF_ constants and 38 PF_ constants like this:
#define PF_INET 2 /* IP protocol family. */
#define AF_INET PF_INET
Python
The Python socket module is very similar to the C API. However, there are many AF_ constants but only one PF_ constant (PF_PACKET). Thus, in Python we have no choice but use AF_INET.
I think this decision to include only the AF_ constants follows one of the guiding principles: “There should be one– and preferably only one –obvious way to do it.” (The Zen of Python)
Other info
This forum post links to this old message, which contains some historical information.
Answers:
I think the Wikipedia notes on this sum it up pretty well:
The original design concept of the socket interface distinguished between protocol types (families) and the specific address types that each may use. It was envisioned that a protocol family may have several address types. Address types were defined by additional symbolic constants, using the prefix AF_ instead of PF_. The AF_-identifiers are intended for all data structures that specifically deal with the address type and not the protocol family. However, this concept of separation of protocol and address type has not found implementation support and the AF_-constants were simply defined by the corresponding protocol identifier, rendering the distinction between AF_ versus PF_ constants a technical argument of no significant practical consequence. Indeed, much confusion exists in the proper usage of both forms.
Even if someone came up with a reason to have a difference today, they’d have to come up with new identifiers or so much stuff would break…
Looking at examples about socket programming, we can see that some people use AF_INET while others use PF_INET. In addition, sometimes both of them are used at the same example. The question is: Is there any difference between them? Which one should we use?
If you can answer that, another question would be… Why there are these two similar (but equal) constants?
What I’ve discovered, so far:
The socket manpage
In (Unix) socket programming, we have the socket() function that receives the following parameters:
int socket(int domain, int type, int protocol);
The manpage says:
The
domainargument specifies a communication domain; this selects the
protocol family which will be used for communication. These families
are defined in <sys/socket.h>.
And the manpage cites AF_INET as well as some other AF_ constants for the domain parameter. Also, at the NOTES section of the same manpage, we can read:
The manifest constants used under 4.x BSD for protocol families are
PF_UNIX, PF_INET, etc., while AF_UNIX etc. are used for address families.
However, already the BSD man page promises: “The protocol family
generally is the same as the address family”, and subsequent standards
use AF_* everywhere.
The C headers
The sys/socket.h does not actually define those constants, but instead includes bits/socket.h. This file defines around 38 AF_ constants and 38 PF_ constants like this:
#define PF_INET 2 /* IP protocol family. */
#define AF_INET PF_INET
Python
The Python socket module is very similar to the C API. However, there are many AF_ constants but only one PF_ constant (PF_PACKET). Thus, in Python we have no choice but use AF_INET.
I think this decision to include only the AF_ constants follows one of the guiding principles: “There should be one– and preferably only one –obvious way to do it.” (The Zen of Python)
Other info
This forum post links to this old message, which contains some historical information.
I think the Wikipedia notes on this sum it up pretty well:
The original design concept of the socket interface distinguished between protocol types (families) and the specific address types that each may use. It was envisioned that a protocol family may have several address types. Address types were defined by additional symbolic constants, using the prefix
AF_instead ofPF_. TheAF_-identifiers are intended for all data structures that specifically deal with the address type and not the protocol family. However, this concept of separation of protocol and address type has not found implementation support and theAF_-constants were simply defined by the corresponding protocol identifier, rendering the distinction betweenAF_versusPF_constants a technical argument of no significant practical consequence. Indeed, much confusion exists in the proper usage of both forms.
Even if someone came up with a reason to have a difference today, they’d have to come up with new identifiers or so much stuff would break…