Friday, July 30, 2010

Faye Hates Chrome on Linux

‹prev | My Chain | next›

Last night, I ran into a bit of a problem with faye, the simple pub/sub messaging framework. My trouble may have been related to me quick diving into getting it working with fab.js, although that actually seemed to work relatively well.

Failure began when I tried to pub/sub messages from the Chromium browser. I am running on linux and, last night, I was running version 6.0.472.0-r53024. Upgrading to 6.0.472.11-r53709 today has no effect. It always works in Firefox and, oddly enough, works in older Chromium (5.x).

The HTML + Javascript code that I am using:
<html>
<head>
<title>Testing Faye/Fab</title>
<script type="text/javascript" src="/faye.js"></script>
<script type="text/javascript">
var client = new Faye.Client('/faye');
client.subscribe('/foo', function(message) {console.debug(message)});

</script></head>

<body>
<h1>Testing Faye/Fab</h1>

</body>
</html>
I pull in the faye source, instantiate a client object, then subscribe to the /foo channel with a callback that prints any channel messages to the console.

In Firefox/Firebug, I see this when messages are broadcast:



But, in Chrome, I see nothing:



I am at something of a loss for how to proceed at this point. It works everywhere but latest Chrome on linux. As I mentioned, I am doing this against a fab.js server. Maybe there is something in there that does not like Linux/Chrome. Yeah, I am grasping at straws, but, if nothing else, I ought to be able to reproduce this in the simplest possible way.

So I create a pure node.js / faye server, app.js:
ar Faye   = require('faye'),
server = new Faye.NodeAdapter({mount: '/faye'});

server.listen(8000);
I run that with the latest node.js on my londo server rather than my laptop to eliminate Linux/Chrome localhost weirdness:
cstrom@londo:~/tmp/faye-test$ node --version
v0.1.102
cstrom@londo:~/tmp/faye-test$ node app.js

I then create a local file that accesses this resource on the remote server (faye can go cross domain, so this ought to work just fine):
<html>
<head>
<title>Testing Faye/Fab</title>
<script type="text/javascript" src="http://londo:8000/faye.js"></script>
<script type="text/javascript">
var client = new Faye.Client('http://londo:8000/faye');
client.subscribe('/foo', function(message) {console.debug(message)});
</script>
</head>

<body>
<h1>Testing Faye/Fab</h1>

</body>
</html>
And again, this still works in Firefox/Firebug, but nothing in Chrome. At least I have eliminated my fab.js stuff as a culprit, but I still cannot get this working with Chrome.

The last thing I try tonight is inspecting the packets with tcpdump. For Chrome, I see:
cstrom@whitefall:~/repos/faye_test$ sudo tcpdump -i eth1  -n -s 0 -X port 8000
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
...
23:52:25.597289 IP londo.8000 > 192.168.1.150.48884: Flags [P.], seq 23516:23913, ack 853, win 62, options [nop,nop,TS val 279488801 ecr 12072325], length 397
0x0000: 4500 01c1 cb48 4000 3f06 eafd c0a8 010a E....H@.?.......
0x0010: c0a8 0196 1f40 bef4 23a5 be0b 5f9c 909b .....@..#..._...
0x0020: 8018 003e 2dfc 0000 0101 080a 10a8 a921 ...>-..........!
0x0030: 00b8 3585 4854 5450 2f31 2e31 2032 3030 ..5.HTTP/1.1.200
0x0040: 204f 4b0d 0a43 6f6e 7465 6e74 2d54 7970 .OK..Content-Typ
0x0050: 653a 2074 6578 742f 6a61 7661 7363 7269 e:.text/javascri
0x0060: 7074 0d0a 436f 6e6e 6563 7469 6f6e 3a20 pt..Connection:.
0x0070: 6b65 6570 2d61 6c69 7665 0d0a 5472 616e keep-alive..Tran
0x0080: 7366 6572 2d45 6e63 6f64 696e 673a 2063 sfer-Encoding:.c
0x0090: 6875 6e6b 6564 0d0a 0d0a 3132 300d 0a5f hunked....120.._
0x00a0: 5f6a 736f 6e70 315f 5f28 5b7b 2269 6422 _jsonp1__([{"id"
0x00b0: 3a22 6e75 646c 6e33 6776 7263 397a 3139 :"nudln3gvrc9z19
0x00c0: 7376 3336 6331 7767 3933 797a 222c 2263 sv36c1wg93yz","c
0x00d0: 6861 6e6e 656c 223a 222f 6d65 7461 2f68 hannel":"/meta/h
0x00e0: 616e 6473 6861 6b65 222c 2273 7563 6365 andshake","succe
0x00f0: 7373 6675 6c22 3a74 7275 652c 2276 6572 ssful":true,"ver
0x0100: 7369 6f6e 223a 2231 2e30 222c 2273 7570 sion":"1.0","sup
0x0110: 706f 7274 6564 436f 6e6e 6563 7469 6f6e portedConnection
0x0120: 5479 7065 7322 3a5b 226c 6f6e 672d 706f Types":["long-po
0x0130: 6c6c 696e 6722 2c22 6361 6c6c 6261 636b lling","callback
0x0140: 2d70 6f6c 6c69 6e67 222c 2277 6562 736f -polling","webso
0x0150: 636b 6574 225d 2c22 636c 6965 6e74 4964 cket"],"clientId
0x0160: 223a 226d 6730 756b 7131 326c 7831 6b6f ":"mg0ukq12lx1ko
0x0170: 3138 6763 6272 6331 767a 7232 7a6f 222c 18gcbrc1vzr2zo",
0x0180: 2261 6476 6963 6522 3a7b 2272 6563 6f6e "advice":{"recon
0x0190: 6e65 6374 223a 2272 6574 7279 222c 2269 nect":"retry","i
0x01a0: 6e74 6572 7661 6c22 3a30 2c22 7469 6d65 nterval":0,"time
0x01b0: 6f75 7422 3a36 3030 3030 7d7d 5d29 3b0d out":60000}}]);.
0x01c0: 0a .
23:52:25.597354 IP 192.168.1.150.48884 > londo.8000: Flags [.], ack 23913, win 906, options [nop,nop,TS val 12072326 ecr 279488801], length 0
0x0000: 4500 0034 b88f 4000 4006 fe43 c0a8 0196 E..4..@.@..C....
0x0010: c0a8 010a bef4 1f40 5f9c 909b 23a5 bf98 .......@_...#...
0x0020: 8010 038a 4d90 0000 0101 080a 00b8 3586 ....M.........5.
0x0030: 10a8 a921 ...!

...

23:52:52.288511 IP 192.168.1.150.32916 > londo.8000: Flags [P.], seq 1:192, ack 1, win 92, options [nop,nop,TS val 12078999 ecr 279491470], length 191
0x0000: 4500 00f3 5a45 4000 4006 5bcf c0a8 0196 E...ZE@.@.[.....
0x0010: c0a8 010a 8094 1f40 7989 15d7 3c22 9ae6 .......@y...<"..
0x0020: 8018 005c b842 0000 0101 080a 00b8 4f97 ...\.B........O.
0x0030: 10a8 b38e 4745 5420 2f66 6179 6520 4854 ....GET./faye.HT
0x0040: 5450 2f31 2e31 0d0a 5570 6772 6164 653a TP/1.1..Upgrade:
0x0050: 2057 6562 536f 636b 6574 0d0a 436f 6e6e .WebSocket..Conn
0x0060: 6563 7469 6f6e 3a20 5570 6772 6164 650d ection:.Upgrade.
0x0070: 0a48 6f73 743a 206c 6f6e 646f 3a38 3030 .Host:.londo:800
0x0080: 300d 0a4f 7269 6769 6e3a 206e 756c 6c0d 0..Origin:.null.
0x0090: 0a53 6563 2d57 6562 536f 636b 6574 2d4b .Sec-WebSocket-K
0x00a0: 6579 313a 2031 3734 756f 3220 3739 2b59 ey1:.174uo2.79+Y
0x00b0: 4d20 2020 6020 207a 2020 3478 4c65 204a M...`..z..4xLe.J
0x00c0: 3820 5633 300d 0a53 6563 2d57 6562 536f 8.V30..Sec-WebSo
0x00d0: 636b 6574 2d4b 6579 323a 2035 3734 2032 cket-Key2:.574.2
0x00e0: 3136 3720 4e36 380d 0a0d 0a04 6641 d419 167.N68.....fA..
0x00f0: d2e7 ad ...

...

23:52:52.290286 IP londo.8000 > 192.168.1.150.32916: Flags [P.], seq 1:45, ack 192, win 54, options [nop,nop,TS val 279491470 ecr 12078999], length 44
0x0000: 4500 0060 2969 4000 3f06 8e3e c0a8 010a E..`)i@.?..>....
0x0010: c0a8 0196 1f40 8094 3c22 9ae6 7989 1696 .....@..<"..y...
0x0020: 8018 0036 31cf 0000 0101 080a 10a8 b38e ...61...........
0x0030: 00b8 4f97 4854 5450 2f31 2e31 2031 3031 ..O.HTTP/1.1.101
0x0040: 2057 6562 2053 6f63 6b65 7420 5072 6f74 .Web.Socket.Prot
0x0050: 6f63 6f6c 2048 616e 6473 6861 6b65 0d0a ocol.Handshake..

...

23:52:52.291472 IP londo.8000 > 192.168.1.150.32916: Flags [P.], seq 45:154, ack 192, win 54, options [nop,nop,TS val 279491470 ecr 12078999], length 109
0x0000: 4500 00a1 296a 4000 3f06 8dfc c0a8 010a E...)j@.?.......
0x0010: c0a8 0196 1f40 8094 3c22 9b12 7989 1696 .....@..<"..y...
0x0020: 8018 0036 06e4 0000 0101 080a 10a8 b38e ...6............
0x0030: 00b8 4f97 5570 6772 6164 653a 2057 6562 ..O.Upgrade:.Web
0x0040: 536f 636b 6574 0d0a 436f 6e6e 6563 7469 Socket..Connecti
0x0050: 6f6e 3a20 5570 6772 6164 650d 0a57 6562 on:.Upgrade..Web
0x0060: 536f 636b 6574 2d4f 7269 6769 6e3a 206e Socket-Origin:.n
0x0070: 756c 6c0d 0a57 6562 536f 636b 6574 2d4c ull..WebSocket-L
0x0080: 6f63 6174 696f 6e3a 2077 733a 2f2f 6c6f ocation:.ws://lo
0x0090: 6e64 6f3a 3830 3030 2f66 6179 650d 0a0d ndo:8000/faye...
For Firefox, I do not see any of the websocket connections—it seems to be using only long polling to do its thing.

At this point, I think it is time to open an issue on the github tracker for faye—maybe someone else has some insights that might help. Unless there is an obvious solution, I will likely dig through the faye source code tomorrow to see what I can see. If nothing else, it might be nice to have a way to force long polling rather than attempting websockets—especially with Chrome+Linux.

Day #180

No comments:

Post a Comment