Bug 64788 - WebSocket: Connecting to localhost:8880 takes one second on Windows
Summary: WebSocket: Connecting to localhost:8880 takes one second on Windows
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Yuta Kitamura
URL:
Keywords:
Depends on: 70992
Blocks:
  Show dependency treegraph
 
Reported: 2011-07-19 02:47 PDT by Yuta Kitamura
Modified: 2011-10-27 22:39 PDT (History)
6 users (show)

See Also:


Attachments
Patch (3.31 KB, patch)
2011-10-19 06:10 PDT, Yuta Kitamura
no flags Details | Formatted Diff | Diff
Patch v2 (no expectation change) (1.89 KB, patch)
2011-10-19 23:43 PDT, Yuta Kitamura
no flags Details | Formatted Diff | Diff
Patch for landing (1.92 KB, patch)
2011-10-27 22:28 PDT, Yuta Kitamura
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Yuta Kitamura 2011-07-19 02:47:08 PDT
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.
Comment 1 Yuta Kitamura 2011-07-19 03:04:47 PDT
Marked as TIMEOUT for now. I'm trying to reproduce this.
Comment 2 Yuta Kitamura 2011-07-19 10:40:36 PDT
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.
Comment 3 Alexey Proskuryakov 2011-07-19 10:47:09 PDT
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.
Comment 4 Yuta Kitamura 2011-07-19 12:09:51 PDT
(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.
Comment 5 Yuta Kitamura 2011-07-19 12:20:23 PDT
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).
Comment 6 Alexey Proskuryakov 2011-07-19 12:55:56 PDT
We also need to test cross origin behavior, and the simple fact that we resolve host names.
Comment 7 Yuta Kitamura 2011-10-19 05:28:52 PDT
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".
Comment 8 Yuta Kitamura 2011-10-19 06:10:09 PDT
Created attachment 111603 [details]
Patch
Comment 9 Kent Tamura 2011-10-19 18:10:18 PDT
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.
Comment 10 Yuta Kitamura 2011-10-19 23:43:07 PDT
Created attachment 111729 [details]
Patch v2 (no expectation change)
Comment 11 WebKit Review Bot 2011-10-20 21:13:19 PDT
Comment on attachment 111729 [details]
Patch v2 (no expectation change)

Clearing flags on attachment: 111729

Committed r98064: <http://trac.webkit.org/changeset/98064>
Comment 12 WebKit Review Bot 2011-10-20 21:13:24 PDT
All reviewed patches have been landed.  Closing bug.
Comment 13 Yuta Kitamura 2011-10-20 22:47:58 PDT
Reverted r98064 for reason:

Broke Mac bots.

Committed r98068: <http://trac.webkit.org/changeset/98068>
Comment 14 Yuta Kitamura 2011-10-20 23:42:24 PDT
Sounds like this is pywebsocket's problem; after newer version of pywebsocket  is rolled into WebKit we will be safely land this patch again.
Comment 15 Yuta Kitamura 2011-10-27 22:24:50 PDT
New pywebsocket (with a fix) has been landed; let me try this again.
Comment 16 Yuta Kitamura 2011-10-27 22:28:07 PDT
Created attachment 112815 [details]
Patch for landing
Comment 17 WebKit Review Bot 2011-10-27 22:39:32 PDT
Comment on attachment 112815 [details]
Patch for landing

Clearing flags on attachment: 112815

Committed r98693: <http://trac.webkit.org/changeset/98693>
Comment 18 WebKit Review Bot 2011-10-27 22:39:37 PDT
All reviewed patches have been landed.  Closing bug.