Delay in responding to requests with EmbedIO listener using ipv6

[rocketraman]

Describe the bug Using the Embed.IO listener with a simple /health controller that simply responds with a String. The request takes 2 seconds to process. Have tried with both httpie and curl on the client side.

With the MS listener, the request processes immediately as expected.

Desktop (please complete the following information):

• OS: Windows
• Browser [e.g. chrome, safari]: N/A
• Version [e.g. 22]: 10

[geoperez]

@rdeago I don't think we should check this issue if we want to proceed with the idea of removing the current Http Listener.

What do you think?

[rocketraman]

What will you replace the current listener with, if anything?

[geoperez]

This is still on a topic on discussion. Anyway, I will try to check where is consuming time the startup of the webserver.

[rocketraman]

Note: its not just webserver startup. Each request takes 2s, not just the first one.

[geoperez]

😕 I don't have that time on each request. Can you elaborate a little more about your test?

[rocketraman]

I did some further testing and you're right... the issue appears to be something specific to my networking setup. When I connect directly to the machine instead of via an ssh tunnel I have, it works without any delay. Closing.

[rocketraman]

It is odd that its only the embedio listener and not the MS one though.

[geoperez]

So, is this happening when you connect using an ssh tunnel and work with EmbedIO Listener? Any additional information that you can share about the tunnel?

[rocketraman]

Nothing complicated. I use putty inside my Windows 10 VM to ssh to a Linux box (my host machine). Putty is configured to create a remote tunnel from port 7071 on the host, to localhost port 7071, which runs my EmbedIO app.

I've tried disabling Windows Firewall and Defender, and neither of these have any effect. When I connect directly to the VM from the host, it works fine. I've even tried capturing the network packets in Windows but am unable to for some reason -- doesn't seem to be as easy as with Linux.

[rocketraman]

Ah, its something to do with ipv6. With wireshark, I see a bunch of TCP RSTs happen with the ipv6 loopback, and then finally a fallback to ipv4 which works immediately:

[geoperez]

I see. So the endpoint manager is failing to grab the IPv6 bind with EmbedIO Listener. There is a setting to use IPv6:

EndPointManager.UseIpv6 = true;

Can you test it?

[rocketraman]

For reference, here is the packet cap with the MS listener, with no additional settings to enable IPV6. Will test that setting above.

[rocketraman]

And with EndPointManager.UseIpv6 = true; and the EmbedIO listener, it also works without an issue. Should that be the default?

[geoperez]

Maybe, I need to evaluate what could go wrong if a set this setting on by default. Let's keep open this issue while I review it.

[rocketraman]

Ok sounds good. BTW, I did confirm ipv4 requests with EndPointManager.UseIpv6 = true; do also work without any issue.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[rdeago]

@geoperez next minor version could be the right time to change the default for EndPointManager.UseIpv6 to true. Want a PR? :wink:

[geoperez]

I think I already did it.

On Sat, Dec 28, 2019, 11:47 AM Riccardo De Agostini < notifications@github.com> wrote:

@geoperez https://github.com/geoperez next minor version could be the right time to change the default for EndPointManager.UseIpv6 to true. Want a PR? 😉

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/unosquare/embedio/issues/399?email_source=notifications&email_token=AANRRMAUGLJ45BAIS4AHHB3Q26GK7A5CNFSM4JEXD5O2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHYO3MQ#issuecomment-569437618, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANRRMG2MLZDTBZH5YHALSDQ26GK7ANCNFSM4JEXD5OQ .

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[rocketraman]

Closing, thanks.