Hi Alon, the 6 and the 17 are the IANA protocol numbers for TCP and UDP taken from http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml

In this case I'm not *totally* convinced that using cDefine is the "correct" thing to do. What I mean is that for sure an "equivalent" cDefine might exist, so if you look in netinet/in.h you will see (among others)
#define IPPROTO_TCP      6
#define IPPROTO_UDP      17

But the IPPROTO_ stuff in in.h tends to be a bit of a hangover from older network code - so there's lots of code around like:
fd = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP);

but a lot of more recent code uses the protocol database e.g. 
fd = socket(PF_INET, SOCK_STREAM, getprotobyname("tcp")->p_proto);

This is physically (or logically perhaps) "looking up" an entry from the protocols database.

If you do "man protocols" on a Unix box you'll see:
"This file is a plain ASCII file, describing the various DARPA internet protocols that are available from the TCP/IP subsystem. It should  be consulted instead of using the numbers in the ARPA include files, or, even worse, just guessing them".....

"Each line is of the following format:

              protocol number aliases ...
where  the  fields  are  delimited  by spaces or tabs.  Empty lines are ignored.  If a line contains a hash mark (#), the  hash  mark  and  the part of the line following it are ignored."

in /etc/protocols you see:

ip	0	IP		# internet protocol, pseudo protocol number
#hopopt	0	HOPOPT		# IPv6 Hop-by-Hop Option [RFC1883]
icmp	1	ICMP		# internet control message protocol
igmp	2	IGMP		# Internet Group Management
ggp	3	GGP		# gateway-gateway protocol
ipencap	4	IP-ENCAP	# IP encapsulated in IP (officially ``IP'')
st	5	ST		# ST datagram mode
tcp	6	TCP		# transmission control protocol
egp	8	EGP		# exterior gateway protocol
igp	9	IGP		# any private interior gateway (Cisco)
pup	12	PUP		# PARC universal packet protocol
udp	17	UDP		# user datagram protocol
hmp	20	HMP		# host monitoring protocol

etc.

Ultimately the allocprotoent is essentially mirroring the appropriate entries from /etc/protocols

I'd have to say that I think that if there's concern over the constants a better approach might be to improve the commenting around this, but TBH that's what my comments:

    // Populate the protocol 'database'. The entries are limited to tcp and udp, though it is fairly trivial
    // to add extra entries from /etc/protocols if desired - though not sure if that'd actually be useful.

were trying to convey.

I realise that this code is essentially "faking" the protocols database for the case of TCP and UDP so arguments about "correctness" probably don't hold any water :-) but what I've put above is certainly my interpretation of what the various man pages were getting at and what shaped my thinking as to how to implement this stuff.