Hi @mtnygard, sorry for not following template. I’ve read your book „Release It Second Edition!” and found some TCP related errors worth mention:

• Ephemeral Ports on page 54 you wrote „The operating system assigns inbound connections to an „emphemeral” port that represents the receiving side of the connection … So we can stretch that range to ports 1024-65535, for maximum of 64,511 connections.”
  You also mention it on page 153 „Socket numbers only range from 1 to 65535, so at best a single NIC can support about 64,000 connections”.
  To precisely identify connection Operating system uses five-tuple (Protocol, Source Address, Destination, Address, Source Port, Destination Port) RFC 6056: Recommendations for Transport-Protocol Port Randomization. Ephemeral ports are used by Client as a way to route data to correct process. They aren’t depleted on server side when it accepts connection. It’s accept connection on well known port and uses ephemeral port to create answer for one particular IP address. So only limitation is on possible connection between particular (Client) IP, particular (Server) IP with known server port (for example 80). When different Clients open connections to port 80 they have different IP addresses and they are distinguished by them, ephemeral ports are used when one Client opened few connections to one Server to make sure they don’t mess with each other. You wrote that adding another Network Card could help. If one Client needs to open as many connections to one Server then it would be easier to just accept request on other server port (81, 82… but this seem improbable)

• TCP multicasting on page 73. I haven’t heard about TCP implementation which would allow for TCP multicasting because TCP stack cares a lot about connection state (window size, acknowledged bytes, occurrence of congestion etc…). It would need to maintain those for all multicast receivers which is something what multicast was created to avoid.

• (Just opinion) TCP retry on page 93. You wrote „ Some kinds of transient failures might be overcome with a retry (for example, dropped packets over a WAN).” Actually there is nothing wrong with that statement because you didn’t mention transport mechanism. But many people (me too) by default thinks about TCP. Which will do retry by itself (but no faster than one second RFC 6298: Computing TCP's Retransmission Timer)

• (Just opinion) Custom handshaking on page 113. I didn’t get what are advantages of custom handshaking over mentioned 503 Http response code, possible with standard Retry-After header RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
  Custom handshake, and I understand it as permission for making HTTP request, adds another Round Trip Time to whole operation latency and gives nothing back. If advantage is because of not sending huge, useless request then HTTP also allows to optimize that by Expect Header RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. Seems like more universal approach than custom stuff.

• (Minor mistake) On page 119 you wrote „When the queue is full, new connection attempts are rejected with an ICMP RST (reset) packet” RST is flag part of TCP message format. It is not related to ICMP Transmission Control Protocol (TCP) Specification.

• (Just opinion) Page 174 You wrote „Anything using Java’s built-in classes will cache the first IP address it receives from DNS, guaranteeing that every future connection targets the same instance and completely defeating load balancing” Although DNS allow you to configure TTL RFC 1035: Domain names - implementation and specification TTL I was surprised that you are right - Java ignores it. I found that you can disable caching or set it’s time manually jdk11/InetAddress.java at 37115c8ea4aff13a8148ee2b8832b20888a5d880 · openjdk/jdk11 · GitHub. This is more Java bug than issue of relying on DNS, of course very important one but it’s not DNS round robin that fails here.

• Page 185 TIME_WAIT and the Bogons: „Services that only deal with work inside a data center can set a very low TIME_WAIT to free up those ephemeral sockets. Just be sure to reduce the machine’s TCP setting for the default „time to live” on packets accordingly. On Linux, take a look at the tcp_tw_reuse kernel setting” As far as I know linux kernel don’t allow to set this value manually. You can IP Sysctl — The Linux Kernel documentation disable it, enable for all or for loopback only. I don’t get „time to live” change mention. Its IP job unrelated to TIME_WAIT. Reducing it make sense only if connections to your systems are terminated on Edge (which opens new “internal” connection) if not, there is possibility that your answer won’t reach recipient.

• Page 218 „At one time, it was common to use query parameters on URLs and hyperlinks to carry session IDs. Not only are those session IDs visible to every switch, router, and proxy server, they are also visible to humans”. Although there is good point about copying and pasting link after, this one is not precise. When traffic is encrypted (almost all now is) all devices in the middle see only IP and TCP headers. URL as part of HTTP data is encrypted. And if traffic is not encrypted then it doesn’t matter where you place session id - it will be visible.