Monday, July 11, 2011

A Closer Look at BEEP

‹prev | My Chain | next›

Last night, I was able to get the Vortex reference implementation of BEEP running. Up tonight, I take a closer look at some of the packets moving back and forth between client and server over BEEP. Hopefully, that will give me a better idea of how BEEP and SPDY compare.

Still in vortex's test sub-directory, I think vortex-file-transfer-client and vortex-file-transfer-server look like reasonable candidates for comparison with a web server.

Firing up the server in one window, I need to specify a file to transfer (this is a test, not a full blown static file server):
➜  test  ./vortex-file-transfer-server Makefile.in
INFO: serving file Makefile.in (file found, regular file)
In a separate window, I fire up the client. It seems that vortex-file-transfer-client requires the destination file to already exist prior to transfer. For some reason, that file is named "file.2". So, starting up my transfer, I see:
➜  /tmp  cat /dev/null > file.2 
➜ /tmp ~/src/vortex-1.1.8.b4662.g4666/test/vortex-file-transfer-client --server=localhost bigmsg
Usage: ./vortex-file-transfer-client [--server=hostname] [bigmsg|feeder|ansnul|ansnulfeeder]
Usage: [--transfer-count=transfer_count]
Usage: [--window-size=window_size]
Examples:
-- transfer one copy using feeder method..
>> ./vortex-file-transfer-client --server=localhost feeder
-- transfer 10 copies using bigmsg method..
>> ./vortex-file-transfer-client --server=localhost bigmsg --transfer-count=10

Running test..
connecting to localhost:44017...
ok
Creating a channel with big message profile
Requested to download /tmp/file.2, 1 times..
Configuring set serialize..
Looking caller..
closing file...
Time to transfer 45176 bytes (44 Kbytes): 0.3 secs
To the Wiresharks!

Inspecting the packets, I find a definite difference with SPDY, plain text headers:



There are actually a fair amount of plain text headers. Packet 9 through 14 all contain headers:



I am unsure if this are just done for the sake of this reference implementation or if this is typical BEEP behavior. The BEEP RFC seems to suggest that it is normal BEEP behavior. If so, that would be a definite deficiency as compared with SPDY (at least as it relates to page load times).

I also notice that BEEP seems to use message terminators—even for partial frames of a larger message:



I wonder if the message terminator is meant to be parsed by the stream endpoint of its meant as some kind of checksum. Grist for another day (or more likely SPDY Book).

For now, I re-run the example downloading the file 10 times:
➜  /tmp  ~/src/vortex-1.1.8.b4662.g4666/test/vortex-file-transfer-client --server=localhost bigmsg --transfer-count=10
Usage: ./vortex-file-transfer-client [--server=hostname] [bigmsg|feeder|ansnul|ansnulfeeder]
Usage: [--transfer-count=transfer_count]
Usage: [--window-size=window_size]
Examples:
-- transfer one copy using feeder method..
>> ./vortex-file-transfer-client --server=localhost feeder
-- transfer 10 copies using bigmsg method..
>> ./vortex-file-transfer-client --server=localhost bigmsg --transfer-count=10

Running test..
connecting to localhost:44017...
ok
Creating a channel with big message profile
Requested to download /tmp/file.2, 10 times..
Configuring set serialize..
Looking caller..
Transfer done, pending count: 9
Looking caller..
Transfer done, pending count: 8
Looking caller..
Transfer done, pending count: 7
Looking caller..
Transfer done, pending count: 6
Looking caller..
Transfer done, pending count: 5
Looking caller..
Transfer done, pending count: 4
Looking caller..
Transfer done, pending count: 3
Looking caller..
Transfer done, pending count: 2
Looking caller..
Transfer done, pending count: 1
Looking caller..
closing file...
Time to transfer 45176 bytes (44 Kbytes): 2.411 secs
Looking a time-sequence network graph, I see a nice steady increase:



Similarly, I see the CWND growing over a short time:



Dunno why I looked at that. Any network connection should exhibit that kind of growth, BEEP, SPDY or other wise. Regardless, that is a stopping point for today.
Day #71

No comments:

Post a Comment