wrote this on P2P and MS a couple of weeks back
http://dotnetjunkies.com/WebLog/stefandemetz/archive/2004/11/27/33854.aspx

BitTorrent is actually quite effective for flash-downloading which makes it an ideal choice for things like ISO images of Visual Studio CTPs (hint hint).

The protocol is based on .torrent files which contain hashes of the files to be downloaded meaning that if your .torrent file is reliable your download will be too.

I think that Microsoft should seriously consider allowing people to select BitTorrent as a download method. It's quite secure and the only downside is that other people will use your bandwidth while you download.

I would rather let people share my download than to be forced to download Subscription stuff from Singapore - I live in Iceland which means I get 8 kbytes/sec.

I and my dev partner Ian have been working on a C# implementation of the python BitTorrent code for a while. The goal is to make a managed library that can be used to download torrents with any interface (WinForms, ASP.NET, IE addin etc.).

I'd love to discuss this a bit more - if you like you can contact me at snorri.beck@gmaildotcom :)

> I and my dev partner Ian have been working on a C# implementation of the python BitTorrent code for a while. The goal is to make a managed library that can be used to download torrents with any interface (WinForms, ASP.NET, IE addin etc.).

SUPER SWEET! Email me too if this becomes available (blog link in name)

The problem I have with BitTorrent is the python-serialized manifest (torrent file). Wouldn't it be nice to make an open xml based torrent file format that works within the bittorrent protocol so we could all get along?

Carl, if possible, could you do a post after you start using the BT downloads and tell us how it changes your bandwidth usage? On the plus side, I'm sure it will decrease your bandwidth a little. On the minus side, will this make it harder for you to get an exact number of downloads for the show?

Actually, the BT protocol allows for absolute tracking of all downloads seeded from our server. What we really need to do in order to make it work is get some high-bandwidth partners to run a BT client and a prog like ipodder to auto-download via BitTorrent, then we'll ask all the listeners who are podcasting to use the BT file instead of the MP3 download, and then we'll be able to see if it makes a dif.

Carl - by changing the format of the BitTorrent files the file is no longer compactable with the millions of other clients out there already as they wouldn't be able to parse the file + you'd have to write your own client. What makes BitTorrent so effective is the number of clients downloading the files so Snorrk idea of a full BitTorrent implementation in .Net would be the way to go. I've thought about this myself before but have never had the time to do anything about it. Considering the best BitTorrent client is written in Java (http://azureus.sourceforge.net/) it would be interesting to see how a .Net implementation performs.

That's all true, Damien. I don't think, however, that bittorrent is the end-all be-all to effective peer-to-peer networking. It's just the beginning. It will only be popular if lots of people use it. Well, the .NET Rocks! listener base is lots of people, and a good open protocol with a good implementation could get some good traction right here. I guess I'm not concerned with bittorrent compatibility.

I haven't used bit torrent before simply cause I don't want to waste my bandwith on p2p networks. But I would probably share around DNR files just out of good will. On the other side it's great for freeing up bandwith on websites.

Sweet! Downloading as I type. Pulling from 4 peers at the moment and it's coming down pretty quickly compared to normal (which isn't saying much as "normal" sucks usually from here in Oz).

I'm sure most listeners would be glad to leave the BT client running after their downlaod has finished to help the rest of the DNR community.

Great idea. Please keep doing it :-)

The key to fast downloads is if lots of people use a podcasting client like ipodder(http://www.ipodder.org) or Doppler (http://www.dopplerradio.net) and point to an as-yet-created torrent RSS feed on our site. That way, when we publish, all the torrent clients will kick in at more or less the same time, and everyone will get the file faster.

We'll make a feed before the next show.

Hi,

the .torrent files are not in python binary format :) They are b-encoded as author calls it, and it's nothing but a custom binary format. Same goes for the binary protocol.
I have already written good piece of C# library to read/write these files, download/upload them, and I have also created an ASP.NET based tracker (server if you will). I did not have to use anything but the .NET framework itself (v 1.1).
There is no need to invent a new file format/protocol, as you can see there are at least two "pure" .NET based solutions already in development, and BitTorrent as a protocol is quite good/efficient.

Drazen,

Yeah, I've been reading the protocol, and I see what you mean. Pretty simple. Still, I wish it was XML. I'm going to have a go at making a .NET client.

Are you saying you would like it to use XML protocol so you could pass it as an RSS feed to clients? Why not just wrap it in XML, leaving the already standard .torrent file alone, making 2 ways for a .torrent file to be distributed, instead of 2 different systems trying to accomplish the same thing.

I'm going to have a go at it too to write a bittorrent client in C#. Maybe in the end I'll put it at work in Doppler, very maybe.

The problem I'm having though is that whilst downloading shouldn't be a problem, uploading/sharing would I guess? What if I have Doppler running, downloading and sharing files, that will probably conflict at port level with other bittorrent clients running at the same time on my machine? I don't plan to make Doppler a full-featured bittorrent client. It (for now) should only focus on enclosure feeds.

So then I would have to shut down Doppler if I would want to use another (full featured) bittorrent client in order to succesfully share the downloaded files, but then I'm not sharing my podcasts anymore... etc. etc. etc. That's for now the main reason I'm not going for an embedded bittorrent solution in Doppler but want to integrate as much as possible an external (full-featured) bittorrent client.

Still... it could be a nice programming exercise.

Hey Erwin, I wondered what you were doing in Doppler. Actually, I'm embarking on a Windows Service like IE that runs a torrent client, with extensive XML configuration.

As for ports, it looks like you can use whatever port you want. The port gets listed along with your IP address in the header sent to the tracker. Firewalls are an issue in general. However, if you're using bittorrent correctly you've obviously opened the necessary ports already, no?

Carl

Carl

I think you shuld stick with Bittorrent given the support around it. As a matter of fact, the serializer between XML and Python could be a good project. There's a site called LegalTorrents.com on which you could put your feed up there (maybe).

Plus there are so many bittorrent clients (Shareazaa is my fav.)

- SM

Seems like a good opportunity to do something more original using .NET. I've been working on similar concepts with large scale software and data distribution over the internet. Instead of using bittorrent, how about just using ASP.NET, and .NET podcast client (call it DNRCast). Your main DNR site could be the equiv of a tracker, using a Webservice to query for contributing peers and content detail, such as hash values, block length, total blocks etc. DNRCast clients can then opt in to contribute (which requires ports to be opened etc, just like other p2p).. the .NET app can just loadup ASP.NET in an appdomain and host a websevice to publish which complete blocks it has and to repond to block request...

This is just an off the top of my head idea.. might not be the direction your wanting to go...

I guess I'm sold on BitTorrent. I don't see any more obstacles. I was a little concerned about the BEncoding, but after looking at the spec, it only took an hour to write an encoder/decoder. So, I'm going to do my project completely to spec. Not as bad as I thought at all.

Hi Carl,

Right now there is no native support for bittorrent. I fire off any (configured) external client to handle the bittorrent. It works. However, it looks 'nicer' if I would go for a native version of BitTorrent in Doppler, stil... but still... that would make Doppler a full featured bittorrent client, not sure if I want to walkt that road. But it might be that I have no choice. Swarmstreaming seems more 'logical' to me, as that takes all the logic out of the client application. Everything that works/talks HTTP works with swarmstreaming. But again, if people want it, they should get it.

Are you going to publish your efforts? Would save me at least an hour writing the encoder/decoder ;-)

/Erwin

Erwin,

Let's collaborate. Seems to be the sensible thing to do.

Carl,

Makes sense. Will send you an email.

/Erwin

All this talk about Bittorrent is great, but let's get to talking about something that is MORE important.... it's Christmas Eve and still no DNR The Movie.... My Christmas is ruined!!!

Ah.. I knew that would come up. My manufacturer JUST missed it. You should get your DVD early next week. They completed the run yesterday (Thursday) and begain shipping then. I gave them an earful. Best I could do, I'm afraid.

I want my, I want my, I want my D V D.

I just got my DVD in the mail today. It's great!

You pay for a 'Service' and you get let down ...

...Please don't mention fasthosts! (Hosting)

Mark

(Me & Others - A.K.A. 'The Customers')

So, are you saying you have not received your copy yet? If you send me your real information by email I'll track it for you. Send your info to dotnetrocks@franklins.net

Are you or Erwin going to release your code? I'd like to incorporate bittorrent into an app I'm working on, and I'd prefer your code to mine.