> 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.
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.
> 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.
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.
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.
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
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!