I recall developing a embedded product that was to interact with a Microsoft music server to retrieve and playback music from it (sorry, this was many years ago and the details are hazy). We had a problem with our embedded TCP/IP stack running out of TCP connections (it was limited due to memory considerations) when skipping songs on the server and it was due to the server keeping TCP connections open even after we had indicated we wanted to close it and open a new one (for the next song). Eventually, we had to 'break' with the TCP/IP spec and force a TCP reset on our end to close the port and reclaim the memory.
TCP pools and connections are part of why I'm excited about reactive design right now. Although it still doesn't address the problem with a bunch of TCP timeouts eating my entire connection pool if the firewall team locks out our production servers again...
I recall developing a embedded product that was to interact with a Microsoft music server to retrieve and playback music from it (sorry, this was many years ago and the details are hazy). We had a problem with our embedded TCP/IP stack running out of TCP connections (it was limited due to memory considerations) when skipping songs on the server and it was due to the server keeping TCP connections open even after we had indicated we wanted to close it and open a new one (for the next song). Eventually, we had to 'break' with the TCP/IP spec and force a TCP reset on our end to close the port and reclaim the memory.