Random sockets not opening

[hustf]

The randomness makes this hard to document, but it seems a httpsocket sometimes get assigned the same number and one of them basically stalls. For the current version of tests, the number of simultaneous sockets has been reduced to alleviate the problem.

This functionality comes from HtttpServer, which currently has some deprecation warnings and may have slower reaction than normally.

Of course, to debug, one needs to temporarily add some logs in HttpServer. But such logging takes more time than just opening a socket and is likely to increase the problem.

It may seem to be less of a problem on cygwin / julia compiled with 8 threads than on the downloaded binary. HttpServer opens sockets as async tasks, not threads or processes.

[hustf]

Refer PR #86, appveyor tests for Julia 0.6.2 on Windows 32 bit https://ci.appveyor.com/project/hustf/websockets-jl-nfuiv/build/1.0.12/job/vvlhiu2xaxw0q5m7

Also refer issue #84, quote @samoconnor

My take at this point is that it is essential for HTTP.jl to include higher level protocols so that real-world tests can be implemented. For example my PR branch implements AWS authorisation to enable a test that does lots of concurrent GET/PUT against AWS S3. This enabled me to find intermittent bugs in HTTP.jl, MbedTLS.jl (JuliaLang/MbedTLS.jl#117, JuliaLang/MbedTLS.jl#114) and Base JuliaLang/julia#25314.

we see two probably different causes. The logs are a tedious read so I summarize:

1. On Chrome , webscocket 'ws2' subprotocol never makes the connection. 'ws1' makes the connection at 22:44:58, but 'ws2' never makes it. Chrome seems to wait due to the unexpected lack of reply until 22:45:12 when it proceeds to close httpsocket 2.

We see that two seemingly different sockets have been assigned the same socket id, number 4:

INFO:	22:44:58 events.ev_connect	 from client HttpServer.Client{TCPSocket} 4
	sock TCPSocket(Base.Libc.WindowsRawSocket(Ptr{Void} @0x0000026c) open, 0 bytes waiting)
	parser libhttp-parser: v2.7.1, HTTP/0.0, Content-Length: 0 
INFO:	22:44:58 events.ev_connect	 from client HttpServer.Client{TCPSocket} 4
	sock TCPSocket(Base.Libc.WindowsRawSocket(Ptr{Void} @0x0000026c) open, 0 bytes waiting)
	parser libhttp-parser: v2.7.1, HTTP/0.0, Content-Length: 0 

This occurs the first time this session we try to upgrade a socket to websocket with subprotol, which is a weak indication that two sockets gets the same id assigned due to Julia compiling some functions.

Internet Explorer fails to load browsertest2.html. The script that navigates there from browsertest1.html has clearly been run. We never receive a connect event, and this is a different browser.

[hustf]

This was due to blocking asyncronous calls. Servers are still easily overloaded.