Attention: We are retiring the ASP.NET Community Blogs. Learn more >

Some thoughts on BitTorrent, Podcasting & Groove

This is something I posted within a Groove space (in a discussion thread regarding BitTorrent, Podcasting & Groove). Posted here verbatim.


Regarding Podcasting -
Carl Franklin (an associate - we run the local .NET developers group www.ctdotnet.com) has a terrific 'video' on configuring Bittorrent clients (www.pwop.com/video/BitTorrentDemo/btTutorial.htm). Carl runs an online radio show, .NET Rocks that just celebrated its 100th show! (www.dotnetrocks.com). He also uses Bittorrent to distribute content (mp3/wma files). I also recommend taking a look at another client NIMIQ - www.nimiq.nl which uses .NET and is well suited for podcasting.

Regarding Bittorrent -
Bittorrent's original purpose is as a file-distribution protocol that "seeks pareto efficiency" (in an excellent economics paper by Cohen, the inventor of BT). It does this by ensuring pipelining, choking algorithms & tracking which also tracks "leechers" who download content but do little or nothing to upload which leads to the distribution inefficiency.

Regarding Groove+BT
A Groove+BT combination in the GFS may work (a seperate option as in the manual download perhaps) but am not sure what gains it will bring. This is partly, for the role & need of the Tracking/Relay servers in the architecture. The tracking, storage & forwarding mechanisms itself, will induce a complexity (overhead & the needed security layer) that may affect performance. In itself, GVO does have a BT-like distribution (e.g.,'fanning') so I am not sure if incorporating a BT-architecture will bring gains (perhaps marginal at best). The primary goals of GVO (IMHO) is security & P2P syncing - stability & currency within spaces and doing it with minimal or no external resource dependencies (e.g, relay servers, trackers, etc).

There are BT-clients out there that "cheat" - wrongfully reporting the upload statistics, thereby avoding "snubbing/choking" by other BT-clients.  There are situations where such "cheating" is needed - large-file distribution during emergency crisis (eg, Tsunami relief) where the end-user can only consume (download) and not upload especially over very low bandwidth like dial-ups. A seperate BT+GVO tool (3rd party development) may be worth exploring  and this was suggested before by a few Groove developers.

(Un)fortunately, as with all "commons" (commonly consumed resources) there will always be inefficiencies - be it in distributing content or bringing in content.

SBC