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.inIn a separate window, I fire up the client. It seems that
INFO: serving file Makefile.in (file found, regular file)
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.2To the Wiresharks!
➜ /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
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=10Looking a time-sequence network graph, I see a nice steady increase:
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
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