Enable TCP Loopback Fast Path (Windows) by benaadams · Pull Request #416 · aspnet/KestrelHttpServer

benaadams · 2015-11-22T13:25:34Z

Enable TCP Loopback Fast Path; where the IP layer is skipped, for lower latency for localhost comms. For example when fronted by the HttpPlatformHandler+IIS reverse proxy

TCP Loopback Fast Path reference: http://blogs.technet.com/b/wincat/archive/2012/12/05/fast-tcp-loopback-performance-and-low-latency-with-windows-server-2012-tcp-loopback-fast-path.aspx

Recommended work around for open issue in libuv "Enable Fast TCP Loopback on Win" libuv/libuv#489

Related: "Confirm HttpPlatformHandler uses Fast TCP Loopback" aspnet/IISIntegration#29

Resolves #420

davidfowl · 2015-11-23T06:54:34Z

Libuv reference counts and uses that to determine if it can shutdown loop. OnStop unreferences thread' OnStopRude calls Dispose on all the items still referenced and they call close which hopefully unreferences them. So OnStopRuder explicitly unreferences them.

Actually will split this to different PR

davidfowl · 2015-11-23T16:35:16Z

nit: casing

benaadams · 2015-12-02T14:24:45Z

Rebased

muratg · 2015-12-02T16:31:16Z

muratg · 2015-12-03T05:49:41Z

Looks good to me, but I'll wait for @davidfowl or @halter73 to give the squirrel.

benaadams · 2015-12-03T10:08:21Z

More deets https://msdn.microsoft.com/en-us/library/windows/desktop/jj841212(v=vs.85).aspx

The socket that plans to initiate the connection request must apply this IOCTL before making the connection request. So the socket used by the connect, ConnectEx, WSAConnect, WSAConnectByList, or WSAConnectByName function to initiate the connection must apply this IOCTL to use the fast path for loopback operations.

The socket that is listening for the connection request must apply this IOCTL before accepting the connection. So the socket used by the listen function must apply this IOCTL so any sockets that are accepted will use the fast path for loopback. Any sockets returned by the listen function and passed to the accept, AcceptEx, or WSAAccept function will be marked to use the special fast path for loopback operations.

Once an application establishes the connection on a loopback interface using the fast path, all packets for the lifetime of the connection must use the fast path.

Applying SIO_LOOPBACK_FAST_PATH to a socket which will be connected to a non-loopback path will have no effect.

^--- suggests no side effects; when not loopback

This TCP loopback optimization results in packets that flow through the Transport Layer (TL) instead of the traditional loopback through the Network Layer. This optimization improves the latency for loopback packets. Once an application opts in for a connection level setting to use the loopback fast path, all packets will follow the loopback path. For loopback communications, congestion and packet drop are not expected. The notion of congestion control and reliable delivery in TCP will be unnecessary. This, however, is not true for flow control. Without flow control, the sender can overwhelm the receive buffer, leading to erroneous TCP loopback behavior. The flow control in the TCP optimized loopback path is maintained by placing send requests in a queue. When receive buffer is full, the TCP/IP stack guarantees that the sends won't complete until the queue is serviced maintaining flow control.

moozzyk · 2015-12-17T22:20:35Z

Does this work on Nano?

cesarblum · 2016-02-13T00:36:28Z

Tested this on Windows 7, 8 and 2008 R2, both local connection and connection from another machine. Everything looks fine except I can't do a remote connection to 2008 R2. Not caused by the change though, I can't do it even without it. Might be a bug we have to look into, but I'm actually more suspicious it's something that needs to be setup correctly.

cesarblum · 2016-02-13T00:36:52Z

Next I'll make sure this does't cause issues on Linux and Mac.

benaadams · 2016-02-13T00:37:47Z

Opened windows advanced firewall ports on 2008?

cesarblum · 2016-02-13T01:07:58Z

@benaadams Thanks, that worked. For 7 and 8 I only had to create an endpoint in Azure portal, but 2008 required that extra step.

cesarblum · 2016-02-14T04:24:20Z

@benaadams Can you rebase?

Enable TCP Loopback Fast Path; where the IP layer is skipped, for lower latency for localhost comms, like HttpPlatformHandler+IIS reverse proxy http://blogs.technet.com/b/wincat/archive/2012/12/05/fast-tcp-loopback-performance-and-low-latency-with-windows-server-2012-tcp-loopback-fast-path.aspx Have to do it this way due to open issue in libuv Loopback fast path: libuv/libuv#489 Related: "Confirm HttpPlatformHandler uses Fast TCP Loopback" aspnet/IISIntegration#29

benaadams · 2016-02-14T04:46:14Z

Rebased

cesarblum · 2016-02-16T20:51:03Z

@benaadams Yep, hanging here too. For me it's hanging before the test summary is displayed.

cesarblum · 2016-02-16T20:58:40Z

@benaadams Have you see this in any of your runs?

Microsoft.AspNetCore.Server.KestrelTests.NetworkingTests.SocketCanRead [FAIL]
  System.Net.Sockets.SocketException : A connect request was made on an already connected socket
  Stack Trace:
       at System.Net.Sockets.Socket.BeginConnectEx(EndPoint remoteEP, Boolean flowContext, AsyncCallback callback, Object state)
       at System.Net.Sockets.Socket.BeginConnect(EndPoint remoteEP, AsyncCallback callback, Object state)
       at System.Threading.Tasks.TaskFactory`1.FromAsyncImpl[TArg1](Func`4 beginMethod, Func`2 endFunction, Action`1 endAction, TArg1 arg1, Object state, TaskCreationOptions creationOptions)
       at System.Net.Sockets.SocketTaskExtensions.ConnectAsync(Socket socket, EndPoint remoteEndPoint)
    D:\src\aspnet\KestrelHttpServer\test\Microsoft.AspNetCore.Server.KestrelTests\NetworkingTests.cs(143,0): at Microsoft.AspNetCore.Server.KestrelTests.NetworkingTests.<>c__DisplayClass7_0.<<SocketCanRead>b__3>d.MoveNext()
    --- End of stack trace from previous location where exception was thrown ---
       at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
       at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
       at System.Runtime.CompilerServices.TaskAwaiter.GetResult()
    D:\src\aspnet\KestrelHttpServer\test\Microsoft.AspNetCore.Server.KestrelTests\NetworkingTests.cs(151,0): at Microsoft.AspNetCore.Server.KestrelTests.NetworkingTests.<SocketCanRead>d__7.MoveNext()
    --- End of stack trace from previous location where exception was thrown ---
       at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
       at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
    --- End of stack trace from previous location where exception was thrown ---
       at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
       at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
    --- End of stack trace from previous location where exception was thrown ---
       at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
       at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)

benaadams · 2016-02-16T21:04:41Z

Wow, never - coreclr bug? Are you on later feed? What runtime, OS?

cesarblum · 2016-02-16T21:16:31Z

Win10, volatile feed. This is on CoreCLR.

benaadams · 2016-02-16T21:28:34Z

Was using ci; trying volatile

cesarblum · 2016-02-16T21:44:17Z

How are you using ci without hitting this:

Unable to resolve Microsoft.DotNet.CoreHost (>= 0.0.1-beta-00001) for DNXCore,Version=v5.0.

?

benaadams · 2016-02-16T21:45:50Z

Used the dotnet feed for something else; think it put it in my local cache

benaadams · 2016-02-16T21:53:07Z

Freezing at first test summary on volatile rather than second :(

cesarblum · 2016-02-16T22:46:54Z

Removing calls to ConnectAsync from lines 143 and 221 of NetworkingTests.cs got me past errors. Still hanging after test summary though.

cesarblum · 2016-02-16T22:50:38Z

+            var socket = new Socket(addressFamily, SocketType.Stream, ProtocolType.Tcp);
+            if (PlatformApis.IsWindows)
+            {
+                const int SIO_LOOPBACK_FAST_PATH = (-1744830448);


Why the parens?

Copy paste code from the blog post on example.

cesarblum · 2016-02-16T23:07:07Z

🚢 after removing offending lines.

benaadams · 2016-02-17T03:17:04Z

Removing calls to ConnectAsync from lines 143 and 221 of NetworkingTests.cs got me past errors. Still hanging after test summary though.

D'oh... double connect

benaadams · 2016-02-17T04:04:33Z

Removed lines, made the changes - never saw the error as couldn't get to that point in tests :(

cesarblum · 2016-02-17T04:24:50Z

@benaadams Still seeing hangs?

benaadams · 2016-02-17T04:31:06Z

Still seeing hangs?

Yep; but see hangs with everything. Tried #633 to resolve them, didn't help.

Not sure if its kestrel shutdown, tests, xunit or dotnet stuff - but started happening for me on move to dotnet from dnx.

Know which is the xunit repo that the tests reference?

cesarblum · 2016-02-17T05:30:10Z

This is the runner that we're using: https://github.com/xunit/xunit/tree/master/src/xunit.console

benaadams · 2016-02-17T06:16:52Z

Always seem get stuck here

benaadams · 2016-02-17T06:42:05Z

Other thread is stuck at which looks to be _process.WaitForExit();

benaadams · 2016-02-17T06:45:57Z

K and the process is stuff because the libuv is still in Run

benaadams · 2016-02-17T07:18:14Z

Usual place https://github.com/aspnet/KestrelHttpServer/blob/dev/src/Microsoft.AspNetCore.Server.Kestrel/Infrastructure/KestrelThread.cs#L280

benaadams · 2016-02-17T09:03:39Z

@CesarBS Added "Talk to the hand" stop to #633 which sorts out the hangs.

cesarblum · 2016-02-17T18:55:36Z

Once #623 is merged the hands should be gone. As far as this PR goes, everything looks good now.

dnfclas added the cla-already-signed label Nov 22, 2015

benaadams force-pushed the loopback-fastpath branch from 03f6c23 to 9cc10d0 Compare November 22, 2015 16:24

davidfowl reviewed Nov 23, 2015
View reviewed changes

benaadams force-pushed the loopback-fastpath branch 2 times, most recently from df6bc8b to 948ac69 Compare November 23, 2015 14:13

davidfowl reviewed Nov 23, 2015
View reviewed changes

Comment thread src/Microsoft.AspNet.Server.Kestrel/Networking/Libuv.cs Outdated

Copy link
Copy Markdown

Member

davidfowl Nov 23, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: casing

benaadams force-pushed the loopback-fastpath branch from 7921731 to d9ca2f3 Compare December 2, 2015 14:24

muratg reviewed Dec 2, 2015
View reviewed changes

Comment thread src/Microsoft.AspNet.Server.Kestrel/Networking/Libuv.cs Outdated

Copy link
Copy Markdown

Contributor

muratg Dec 2, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: var

moozzyk reviewed Dec 17, 2015
View reviewed changes

Comment thread src/Microsoft.AspNet.Server.Kestrel/Networking/Libuv.cs Outdated

Copy link
Copy Markdown

Contributor

moozzyk Dec 17, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this work on Nano?

benaadams mentioned this pull request Jan 11, 2016

Low RPS with lots of response data + chunking #572

Closed

muratg added this to the 1.0.0-rc2 milestone Feb 4, 2016

muratg assigned halter73 Feb 4, 2016

halter73 assigned cesarblum and unassigned halter73 Feb 11, 2016

benaadams force-pushed the loopback-fastpath branch from 39ec0f5 to 020e0b9 Compare February 14, 2016 04:45

cesarblum reviewed Feb 16, 2016
View reviewed changes

Helper function for test socket creation

ffa8f3f

benaadams force-pushed the loopback-fastpath branch from f04455f to ffa8f3f Compare February 17, 2016 04:00

cesarblum merged commit ffa8f3f into aspnet:dev Feb 18, 2016

benaadams deleted the loopback-fastpath branch May 10, 2016 10:59

eisendle mentioned this pull request Nov 29, 2017

Enable TCP FastPath support dotnet/orleans#3710

Merged

Conversation

benaadams commented Nov 22, 2015

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

benaadams commented Dec 2, 2015

Uh oh!

Choose a reason for hiding this comment

Uh oh!

muratg commented Dec 3, 2015

Uh oh!

benaadams commented Dec 3, 2015

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cesarblum commented Feb 13, 2016

Uh oh!

cesarblum commented Feb 13, 2016

Uh oh!

benaadams commented Feb 13, 2016

Uh oh!

cesarblum commented Feb 13, 2016

Uh oh!

cesarblum commented Feb 14, 2016

Uh oh!

benaadams commented Feb 14, 2016

Uh oh!

cesarblum commented Feb 16, 2016

Uh oh!

cesarblum commented Feb 16, 2016

Uh oh!

benaadams commented Feb 16, 2016

Uh oh!

cesarblum commented Feb 16, 2016

Uh oh!

benaadams commented Feb 16, 2016

Uh oh!

cesarblum commented Feb 16, 2016

Uh oh!

benaadams commented Feb 16, 2016

Uh oh!

benaadams commented Feb 16, 2016

Uh oh!

cesarblum commented Feb 16, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cesarblum commented Feb 16, 2016

Uh oh!

benaadams commented Feb 17, 2016

Uh oh!

benaadams commented Feb 17, 2016

Uh oh!

cesarblum commented Feb 17, 2016

Uh oh!

benaadams commented Feb 17, 2016

Uh oh!

cesarblum commented Feb 17, 2016

Uh oh!

benaadams commented Feb 17, 2016

Uh oh!

benaadams commented Feb 17, 2016

Uh oh!

benaadams commented Feb 17, 2016

Uh oh!

benaadams commented Feb 17, 2016

Uh oh!

benaadams commented Feb 17, 2016

Uh oh!

cesarblum commented Feb 17, 2016

Uh oh!

Reviewers