Taking advantage of TCP loopback fast path in Windows | Hacker News Reader

Taking advantage of TCP loopback fast path in Windows

mail.openjdk.java.net

90 pointsrbanffy22 comments

It was refreshing to read the entire thread and not see a negative comment about the source of the patch.

The entire thread was limited to discussing the actual patch implementation.

Good for the patch submitter for doing two things:

1)sticking around and answer any questions about the patch. Some people dump their patch and leave.

2) For making their modification stay behind an input flag, ie they aren't pushing this as the default, though it looks like maybe it should be.

And today I found out about "Microsoft Open Technologies, Inc." I've never heard of that group before!

> And today I found out about "Microsoft Open Technologies, Inc." I've never heard of that group before!

Open Tech is the MS group that is trying to push open source as a culture both inside Microsoft and also among traditional .NET developers. They're the reason you can run Node on Azure, can reliably run Redis on Windows, and they're the ones leading the drive on ASP.NET vNext, the next version of ASP.NET.

It makes it a really exciting time to be a .NET dev.

(Not affiliated, just a fan)

How does one contact them, maybe they could help with some python issues on windows ?

Is the file extension going to be .aspxx?

This "new leaf" Microsoft is showing is quite refreshing. I hope they continue to integrate themselves as part of the FOSS community while reducing their fights.

I did find that they were top posting amusing. Well done for the other contributors in the thread for ignoring it though.

[1] http://en.wikipedia.org/wiki/Posting_style#Top-posting

> And today I found out about "Microsoft Open Technologies, Inc." I've never heard of that group before!

I was about to say that the purpose of the separation is probably to allow them the possibility to grant patent licenses with one hand (e.g. under the Apache 2.0 license) while suing with the other... but Microsoft Open Technologies being a "wholly-owned subsidiary" actually means (I think) that the license would consider them the same "Legal Entity", so that particular trick wouldn't work.

So the app needs to set a flag to optimize network code paths if both endpoints are on same local loopback network. Why can't Windows detect that internally and enable the shorter code paths automatically? At that level it should be an implementation detail to the app so doing it transparently shouldn't be an issue.

Also they should have posted some numbers in support of this change - what's improved and how much.

The answers for your questions:

http://blogs.technet.com/b/wincat/archive/2012/12/05/fast-tc...

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.

Fun fact:

The message is misformatted in the archive beacause the mail client bungled the MIME type (just "text/plain" which means "preformatted, don't reflow lines", instead of "text/plain; format=flowed" which would have been correct here).

Apple's Mail had this bug at some point as well.

edit: Seems there's more to it - the format=flowed part was also, until a 2010 release of MailMan, stripped out by the mailing list sw even if the original mail had it correctly. And then the web archiving part (Pipermail) dutifully follows the specs. Can't easily tell if this is a case of outdated MailMan installation or mail client bug. See this 2006-vintage bug: https://bugs.launchpad.net/mailman/+bug/266341

Avoiding format=flowed is a feature on development mailing lists; it mangles code and patches.

The text/plain MIME type predates the specification of format=flowed by at least 7 years.

Hmmm wouldnt it have been better (for portability reasons) to implement the equivalent of unix domain sockets instead?

Deleted comment

You assume they are communicating with 127.x.x.x. Some implementations are smart enough to detect a loopback with any IP address.

It's a trap!

Reply on news.ycombinator.com