"There are, believe it or not, entire web development frameworks where you don't actually need to manage the TCP/IP sockets yourself."
Actually, what I'm doing with TCP/IP is the easy way to proceed!
You interpreted what I wrote as working with TCP/IP for the Web page Internet communications. Sure, I let Windows and IIS handle that!
But, consider a Web page that needs to execute a SQL query. SQL Server runs in a different 'process', likely in a different address space, maybe on a different machine, real or virtual. So, how does the Web page communicate with SQL Server? Sure: That's already worked out by Microsoft. BUT: There IS communications, and it is 'asynchronous'.
Okay. What holds for a Web page getting to SQL Server can also hold for a Web page getting to some other software possibly particular to the Web site.
So, suppose the design of the Web site has a program that needs to run as a 'service' and be accessed from the Web pages 'asynchronously'. So, how to do that communications?
I looked into Windows 'remoting' (now considered obsolete by Microsoft), the Windows version of old remote procedure call (RPC), Windows Communications Foundation (WCF), Windows pipes (on the same machine), and old TCP/IP sockets. Just to investigate these may have involved over 100 Web pages at MSDN.
I settled on old TCP/IP sockets. For the data to be sent/received, to convert to/from instances of classes, I settled on 'serialization'.
So, I got (back) into TCP/IP sockets. I've done socket programming for over 20 years. To get started with sockets on Windows, I started with some simple socket code in the scripting language Rexx. I got both the 'client' and 'server' sides working with each other. Then I wrote the server side in Visual Basic .NET (the Microsoft 'managed code' version of their TCP/IP) and got that working with the client side code in Rexx. Then I wrote the client side code in VB.NET and got it working with the server side code in both Rexx and VB.NET.
Now the TCP/IP code is ready to drop into the VB Web page code and the VB 'remote server' code.
But using TCP/IP and serialization for this communications was the easy way.
Net, all your criticisms have turned out to be unjustified. I've done nothing wrong. What I wrote to begin with was right on target. Being so consistently wrong you should fear will hurt your credibility. It's not good to be so consistently wrong.