Author Archive

How not to do P2P

Tuesday, February 23rd, 2010 by Kriss Andsten

Peer-to-peer is rather interesting to work with. Disruptive technologies always fascinate me, especially when it’s closely related to work so I can spend oodles of time on it. It’s also interesting to see the developments in the area – even if I don’t always agree with the sentiments of the researchers (for instance, I quite agree with “http://www.digitalsociety.org/2009/11/analysis-of-bittorrent-utp-congestion-avoidance/” George Ou on BitTorrent – for now).

Even so, there are good apples and bad apples. BitTorrent got an undeservingly bad name from people confusing content with transport. Even if I don’t think that they got it right with their be-nice-to-the-network idea, they tried. All in all, a sane actor.

Pando, on the other hand, is an actor that seems quite sane – working in the P4P working group, seemingly trying to make a living out of a very kosher sort of P2P. The protocol isn’t too bloody bad either – the only problem is that parts of the client lodge themselveswhere it’s quite invisible on a Windows system. That, and the usual foray of “Would you want to make xyz.com your default website? Search page? Dog grooming service?”.

Some quick testing shows PMB.exe – Pando Media Booster – disregards the Pando client setting telling it not to start on Windows startup. Different binary from the Pando client, you say? Sure. Explain that to the average user. The net effect is that the software is happily chugging along at 1.5 Mbps without any sort of user notification. No tray icons, or windows – nothing.

Speaking in terms of ISP per-subscriber data usage (on average per user), Pando will skew it to the tunes of one Pando user not knowing she runs PMB to 50 – give or take – purely average users. That, in my book, is the dark side of P2P. Users running BitTorrent, Spotify, Voddler, etc. make a conscious decision to run it. Users running PMB don’t and really have no simple way of knowing why World of Warcraft lag went up or why pages are loading slowly.

File Transfer – The Ugly Way

Monday, February 1st, 2010 by Kriss Andsten

Working in the field of traffic analysis, you get to see a rather modest number of good solutions to a given problem, a larger number of decent solutions and – sadly – quite a few less than stellar ideas as well.  My favorite pet peeve – and believe me, there’s a slew to choose from, is using FTP as an update mechanism for games, and doing it in a not very thought-out manner.

Say that you have 4000 asset files in a given game. Most of them are pretty small – well under 8KB. You want to support users going from version A, B or C to version D, utilizing the least amount of bandwidth in the process. Logic dictates that it would make a lot of sense to get a checksum of all your local files, send the checksums to the server and have the server return a list of files you need to update, right? A minimum amount of bandwidth is utilized and the user can update from pretty much any version.

Enter FTP. FTP uses one control connection and n data connections, where n equals the number of transferred files and directory listings done over the lifetime of the session. And by ‘connection’, that’s a full-blown TCP stream, three-way handshake and all. Let’s pretend that I have a 100ms latency to the update server and the server or clients themselves incur no extra overhead – that leaves us with:

* One PASV call in the control connection and the response to that one. 200 ms.

* One three-way handshake, add another 300 ms (SYN, SYNACK, ACK) – plus another 100 ms before I start seeing the data from the server.

So the tally: To transfer a given file (be it 0.5 KB, 200 KB or 15 MB), the transfer overhead itself will be 600 ms. ,which could be OK’ish for one large patch file. Let’s say there’s a 200 MB update covering 1500 files – that’s 15 minutes worth of waiting for the transfers to start for a set of files that should take something along the lines of two minutes to actually transfer over a pretty basic broadband connection.

I think World of Warcraft  (and others, but they’re a good example) got the right idea from a developer’s perspective – they transfer the patches in sets – going from A to D would require you to go from A to B to C to D – more to download, but people can do such over BitTorrent or any old HTTP mirror rather than the developer’s own site. Game developers, take note. Please.