A more interesting story is why are the older services using mainly odd port numbers (ie. 21 = FTP, 23 = telnet, why was port 22 free at that time?). It turns out because the protocol which preceded the invention of TCP, called NCP, used even-odd pairs of port numbers, with even for "outgoing" data and odd for "incoming". So the well-known port numbers for incoming services were all odd.
You can follow the assignments of such "socket numbers" for NCP in RFCs 349, 433, 503, 739, 750, and 755. RFCs 758, 762, 770, 776, and 790 address both socket numbers for NCP and port numbers for TCP/IP simultaneously. RFCs 820, 870, 900, 923, 943, 960, 990, 1010, 1060, 1340, 1700 continue that work for port numbers only and RFC 3232 finally switches it to an online database.
Back in the "bad old days" of the simplex NCP protocol [1], before the full duplex TCP/IP protocol legalized same-sex network connections, connect and listen sockets had gender defined by their parity, and all connections were required to use sockets with different parity gender (one even and the other odd -- I can't remember which was which, or if it even mattered -- they just had to be different).
The act of trying to connect an even socket to another even socket, or an odd socket to another odd socket, was considered a "peculiar error" called "homosocketuality", which was strictly forbidden by internet protocols, and mandatory "heterosocketuality" was called the "Anita Bryant feature" [2].
When the error code is zero, the next 8 bit byte is the Stanford peculiar error code, followed by 72 bits of the ailing command returned. Here are the Stanford error codes. [...]
IGN 3 Illegal Gender (Anita Bryant feature--sockets must be heterosocketual, ie. odd to even and even to odd) [...]
Illegal gender in RFC, host hhh/iii, link 0
The host is trying to engage us in homosocketuality. Since this is against the laws of God and ARPA, we naturally refuse to consent to it.
; Try to initiate connection
loginj:
init log,17
sixbit /IMP/
0
jrst noinit
setzm conecb
setom conecb+lsloc
move ac3,hostno
movem ac3,conecb+hloc
setom conecb+wfloc
movei ac3,40
movem ac3,conecb+bsloc
move ac3,consck
trnn ac3,1
jrst gayskt ; only heterosocketuals can win!
movem ac3,conecb+fsloc
mtape log,[
=15
byte (6) 2,24,0,7,7
] ; Time out CLS, RFNM, RFC, and INPut
[...]
gayskt: outstr [asciz/Homosocketuality is prohibited (the Anita Bryant feature)
/]
ife rsexec,<jrst rstart;>exit 1,
(The PDP-10 code above adds the connect and listen socket numbers together, which results in bit 0 being 0 if they are the same gender, then TRNN is "test bits right, no change, skip if non zero", which skips the next instruction (jrst gayskt) if they different sex.)
I think this is both insightful and funny. It's a pretty interesting little thing that I'm sure could easily get blow out of context by the same people who get upset when they learn about master and slave devices.
I don't use them at the same time: I switched over to using my own name instead of an old alias.
Whenever I plagiarize myself, I try to check the links and refine the text to keep it relevant.
Just posting a link to an old article requires less effort for me, but more effort for other people to switch context, navigate and read. And a server's disk space and bandwidth aren't as precious as a reader's time and effort.
It was not my intention to trigger mdekkers into having fits about SJWs, or shocking paxcoder who is not a gay supporter.
Personally I think it's great that you reposted your comment.
I suggest however that when you do, you add a line to the bottom that says something along the line "This comment was based on an earlier comment I made X days ago using another account." when you do just to keep people from accusing you of plagiarizing others.
It's not only older services, also fast services. TCP is not the best and fastest protocol for data at all. It's just coldwar security with it's 7 flows of ack to close. "Are you there? Here you are. Got it? Really got it? Ok, you got it" TCP vs "Here you are" UDP.
HTTP Streaming e.g. is only there to artificially keep traffic numbers up by factor 3 but has not much technical justification, other than fix a broken RTSP negotiation.
For example if you telephone with somebody over SIP you will be assigned two UDP numbers (RTP is UDP), you at an even number and the return stream on the next odd number. You don't care if each and every audio frame is ACK'ed. That's why sometimes someone can hear you, but you cannot hear them. No ack for the return stream.
Sources:
https://en.wikipedia.org/wiki/Network_Control_Program
http://www.pcvr.nl/tcpip/introduc.htm