Closed aglyzov closed 12 years ago
I couldn't get the erlang client to work so I've only tested with chrome. I'll spend some time trying to fix the erlang client on my machine & see if I can debug this.
Possibly won't be able to do it before the weekend though. :(
I'll check into it today. Did runtest spew out a ton of errors?
I've just rerun the test with just 10 connections for 10 seconds to reduce the problem field:
$ ./runtest data/clojure 10 192.168.1.2 8080 10 Running test with 10 clients for 10 seconds Data File: "data/clojure" Running logger queue: 0 Elapsed: 0s of 10s Finished
type, clients, handshakes, connection_timeouts, messages_sent, messages_recv, crashes "clojure", 10, 0, 0, 0, 0, 0
Note, the port is right, the clojure server uses 8080 instead of 8000. So, as you can see, no rough errors like connection timeouts, but yet no handshakes.
Ravi, I can help you to setup erlang/rebar if you're on ubuntu or debian. I already did this a dozen times recently :)
Hmm. Alphe uses Netty which looks like it supports Websockets version 13. That is the version my client is targeting.
May sample version 13 request doesn't successfully handshake:
cat request.txt | nc localhost 8080
That simply returns.
I sent your clojure server the exact request that is in the Netty docs for version 13 and it exhibits the same behavior:
I have tracked the issue down to this cause. It appears that the Clojure server does not like that I am sending the
Sec-WebSocket-Protocol: chat
header:
$ git diff request.txt
diff --git a/request.txt b/request.txt
index 4a5ecb5..13f6bbe 100644
--- a/request.txt
+++ b/request.txt
@@ -4,6 +4,5 @@ Connection: Upgrade
Host: localhost
Origin: http://localhost/
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
-Sec-WebSocket-Protocol: chat
Sec-WebSocket-Version: 13
$ cat request.txt | nc localhost 8080
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Chrome 19 is not sending the "Sec-WebSocket-Protocol: chat" header. I'll look into why I thought it was required (It is probably copy pasta from the spec)
ah! I remember now I had the same issue with the twisted websocket implementation (txWS). when I tweaked the server to accept any Sec-WebSocket-Protocol it interoperated fine!
btw, the websocket RFC states this header is to define a sub-protocol (on top of websocket transport). so the questions is can you omit sending it altogether? thus I would be able to also add a vanilla twisted websocket server.
So, yes that was copy pasta.
What I've gleaned in the past 10 minutes of Googling is that the Sec-WebSocket-Protocol
defines a subprotocol that both the client and server needs to agree that they speak. I suppose that Netty is probably the only server that enforces this by default. I bet the following exception is being swallowed up somehow and if we enable logging on the Clojure server we'll see it:
probably
Yup, Chrome breaks if I provide the send argument of ["chat"]. Looks like we have a winner.
I'll remove the header from my client for now
Works perfectly, pushing to master now.
works here too. clojure is slower than java, no miracles today
I'm surprised that Clojure does much worse, it's just a wrapper around the same library. searching google Actually, it looks like Webbit is not using the built-in Netty websocket implementation. I should probably do a native Netty server using their implementation.
I wonder if that is the source of the slower times. It would be interesting to know if Webbit beats Netty's implementation.
I tried to test the provided clojure server, here is what I got:
"clojure", 10000, 0, 2754, 0, 0, 0
I think this means the aleph library used in the server speaks some older websocket dialect.