Would you mind copy + pasting the paragraph that answers the GP's first question? I read that whole article and found nothing indicating why the Windows socket library can't automatically use this fast path on all connections to 127.0.0.1.

I think the below one hints to it being for compat reasons but you're right no explanation as to what possibly could go wrong if they did it automagically -

> Existing Applications and Loopback Fast Path The default behavior of the TCP loopback interface is unchanged in Windows Server 2012 thereby preserving compatibility.

Microsoft being overly compatibility cautious as they should be - it's worked well for them. But on the other hand they should have pondered on what sort of compat issues might pop up if they defaulted to setting the flag for everyone and disabled it on per app blacklist basis or something like that.

Or provided some sort of override setting so the sysadmin could force this behaviour on all or some apps, without having to rewrite the app.

Because it limits the socket options you can use.

"Only a subset of the TCP/IP socket options are supported when the SIO_LOOPBACK_FAST_PATH IOCTL is used to enable the loopback fast path on a socket"

http://msdn.microsoft.com/en-us/library/windows/desktop/jj84...

I still fail to see why that is a problem...

Have it enable the option only if said unsupported options are not used.

What am I missing?

I don't have any special knowledge of this loopback fast path, so what follows is speculation. I'm guessing having it optimistically on unless one of the socket options is used is either a) impossible due to backwards compatibility or b) not worth the effort.

On A): If you look at the TechNet article above, it shows how the loopback fast path connections bypass certain layers of the networking stack. If you have a socket with the "supported" set of socket options that starts life and begins sending/receiving bytes only to have its socket options changed to "unsupported" you're going to have send/receive bytes through the extra layers of the network stack. Now all of a sudden this network stack is seeing a socket appear out of nowhere that's already open and has sent and received data. Previously this situation might never have occurred (i.e. all layers of the network stack would see all stages of a socket's lifecycle). Now network filters etc. are broken.

On B): You might be tempted to present to the extra layers of the network stack a faux-socket that faux-transitions through whatever stages of its lifecycle it needs to get to to get to the stage the real socket is at. (Not to mention going to other way around: switching to fast path from slow path.) This would avoid the compatibility problems. But that seems like a lot of effort for not a lot of value.