Bug 64788 – WebSocket: Connecting to localhost:8880 takes one second on Windows

• Component: Tools / Tests
• Status: RESOLVED FIXED

[Yuta Kitamura]

The test seems to hung when opcode=11 on chromium-win. I don't know why.


Full output:

CONSOLE MESSAGE: line 0: Unrecognized frame opcode: 3
CONSOLE MESSAGE: line 0: Unrecognized frame opcode: 4
CONSOLE MESSAGE: line 0: Unrecognized frame opcode: 5
CONSOLE MESSAGE: line 0: Unrecognized frame opcode: 6
CONSOLE MESSAGE: line 0: Unrecognized frame opcode: 7

Tests whether WebSocket ignores frames with reserved opcode.

On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE".

Opcode 3: Test started.
onopen() was called.
onclose() was called.
PASS closeEvent.wasClean is false
Opcode 4: Test started.
onopen() was called.
onclose() was called.
PASS closeEvent.wasClean is false
Opcode 5: Test started.
onopen() was called.
onclose() was called.
PASS closeEvent.wasClean is false
Opcode 6: Test started.
onopen() was called.
onclose() was called.
PASS closeEvent.wasClean is false
Opcode 7: Test started.
onopen() was called.
onclose() was called.
PASS closeEvent.wasClean is false
Opcode 11: Test started.

[Yuta Kitamura]

Marked as TIMEOUT for now. I'm trying to reproduce this.

[Yuta Kitamura]

Okay, I figured out the cause.

This timeout happens on Win-Vista-Release and Win-7-Release. Mac and Linux seem unaffected.

- The test opens a WebSocket connection using the hostname "localhost" (e.g. new WebSocket("ws://localhost:8880/..."))
- Resolving "localhost" returns "::1" (IPv6 loopback address), but websocketserver doesn't listen on IPv6 address.
- So connect fails, but it takes about one second to fall back to IPv4. :(
- The test reserved-opcodes.html opens ten new connections, which means one-second block adds up and it will take 10+ seconds to complete the test.
- For release builds, the test timeout is set to 6 seconds so the test timeouts. For debug builds, the test has 12 seconds which is somewhat enough to complete the test.

Replacing "localhost:8880" with "127.0.0.1:8880" will fix the problem.

Using this opportunity, I'd like to replace all the occurrences of "localhost" in WebSocket tests. This should cut the layout test execution time in Vista/7 bots.

[Alexey Proskuryakov]

Nice catch!

> websocketserver doesn't listen on IPv6 address

Can this be fixed instead? Listening on IPv6 would be consistent with our Apache setup, and thus less surprising than having a requirement to only use 127.0.0.1.

[Yuta Kitamura]

(In reply to comment #3)
> Nice catch!
> 
> > websocketserver doesn't listen on IPv6 address
> 
> Can this be fixed instead? Listening on IPv6 would be consistent with our Apache setup, and thus less surprising than having a requirement to only use 127.0.0.1.

I first thought this was easy, but I was wrong; pywebsocket standalone server currently does not provide dual-stack server support, and adding it seems to require unobvious amount of work.

I'll ask pywebsocket folks about this, but I'm leaning towards the idea of using only "127.0.0.1:8880" and forgetting about IPv6... Maybe we could forbid the use of "localhost:8880" by adding some check to check-webkit-style.

[Yuta Kitamura]

Another idea is to bring up two instances of pywebsocket standalone server (one for IPv4, one for IPv6) in run-webkit-websocketserver. This is not obvious, either, and IMO the amount of work does not balance with the actual gain (what we really want to test is our WebSokcet implementation, not server's IPv4/v6 dual stackness).

[Alexey Proskuryakov]

We also need to test cross origin behavior, and the simple fact that we resolve host names.

[Yuta Kitamura]

Dual-stack support (listening at IPv4 and IPv6 addresses simultaneously) was added to pywebsocket recently. To make use of this feature, we have to give a command-line option "--server-host localhost" to standalone.py instead of "--server-host 127.0.0.1".

[Yuta Kitamura]

Created attachment 111603 [details]
Patch

[Kent Tamura]

Comment on attachment 111603 [details]
Patch

We had better land the 127.0.0.1 -> localhost change without the test_expectations.txt change , see the layout test results for a while, and then apply the test_expectations.txt change.

[Yuta Kitamura]

Created attachment 111729 [details]
Patch v2 (no expectation change)

[WebKit Review Bot]

Comment on attachment 111729 [details]
Patch v2 (no expectation change)

Clearing flags on attachment: 111729

Committed r98064: <http://trac.webkit.org/changeset/98064>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.

[Yuta Kitamura]

Reverted r98064 for reason:

Broke Mac bots.

Committed r98068: <http://trac.webkit.org/changeset/98068>

[Yuta Kitamura]

Sounds like this is pywebsocket's problem; after newer version of pywebsocket  is rolled into WebKit we will be safely land this patch again.

[Yuta Kitamura]

New pywebsocket (with a fix) has been landed; let me try this again.

[Yuta Kitamura]

Created attachment 112815 [details]
Patch for landing

[WebKit Review Bot]

Comment on attachment 112815 [details]
Patch for landing

Clearing flags on attachment: 112815

Committed r98693: <http://trac.webkit.org/changeset/98693>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.