simple explanation of peer to peer filesharing

June 26, 2007 11:01 PM

Can you explain peer-to-peer filesharing to me in really simple terms? Particularly, I want to know about the similarities and differences between two programs.

I have a basic understanding of how peer-to-peer filesharing works, but I'd like to be able to distinguish between what I use (Azureus) and what my boyfriend uses (eMule).

Please help me by explaining with not-so-technical terms. Pretend it's your grandma asking.

posted by CrazyLemonade to computers & internet (16 comments total)

eMule-
When you go to download a file, you are downloading the file from some guys computer who is sharing it.

Azureus-
Azureus is a bittorrent client. When you download a file you get pieces of the file from a number of different people called seeders. When all these pieces are put together, you get the entire file.

With bittorrent you both upload and download. If you have a piece of the file that Joe doesn't, Joe downloads it from you. Once your file is 100% downloaded you continue to seed (upload) for others to download.
posted by rancidchickn at 11:37 PM on June 26, 2007

Once you start getting a file eMule and bittorrent work fundamentally the same. You are downloading a file from a number of other people who have all or part of it, and as soon as you have any significant portion of it, you are uploading those bits to other people who want the file.

The main difference between all the different peer to peer systems is how you go about finding people to download parts of the file from, and how "fairness" is ensured. The biggest difference between bittorrent and the others is that bittorrent protocol basically punts entirely on the searching aspect of this; instead of searching in the bittorrent client, you use a regular web browser to find (through whatever means) a .torrent file, which tells Azureus what server to connect to and what file to ask for. With eMule there is a built in search system which goes and talks to all the other people and sees what files they have up for offer; it's easier to put files up for sharing.

Because of web integration, bittorrent is a little better suited for non-piracy uses, and because it's a little more work to add your own files, it's a little worse suited for piracy uses, but it as you probably know gets used for both.
posted by aubilenon at 12:08 AM on June 27, 2007

rancidchickn basically has it. It's important to understand that in eMule, a single person is responsible for sharing the file. But with BitTorrent, everybody uploads.

BitTorrent is tougher to 'stop'. If the RIAA wants to stop a file from getting distributed on eMule, they just need to shut down that single uploader. With BitTorrent, they have to go after all the uploaders (Could be hundreds or thousands of people).

Also, with BitTorrent, you must upload in order to download, so there's a shared responsibility.With eMule, one guy's doing all the work.
posted by theiconoclast31 at 12:12 AM on June 27, 2007

Another important distinction is that eMule is (mostly) a centralized service. There is a server (farm) somewhere that tracks everything on the network and organizes just how you are going to download a file from someone else. If a government agency wished to shut down eMule entirely, they would simply need to show up at their office and pull the plug. However, eMule has recently integrated with the Kad network, which is not centralized, so it may be looking to change this. By the way, eMule does have a "credits" system that encourages uploaders.

BitTorrent is almost completely decentralized. There are various trackers with web interfaces that try to maintain a list of all the stuff on the network, but there is no master list. There is also no central server organizing your connections, you are linked to other people to download or upload through the existing network itself. There is no way to "shut down" BitTorrent because there are no central servers. Legal attacks have been launched at the trackers, however the introduction of trackerless torrents has demonstrated the futility of this approach.
posted by sophist at 12:37 AM on June 27, 2007

'Also, with BitTorrent, you must upload in order to download'

My understanding is that you'll often be penalised for not uploading, and it's very bad form not to, but that it's not a technical requirement to do so.
posted by edd at 12:38 AM on June 27, 2007

I haven't come across a client that'll download without upload, but maybe I'm wrong.

I've used Azureus, and I haven't found a way to remove the upload entirely [not that you would want to, don't leech :]
posted by theiconoclast31 at 12:50 AM on June 27, 2007

In bittorrent you prioritize who you upload to by how good they are to download from (very roughly). There is nothing stopping you from making a client that doesn't upload, but if you don't upload at all other clients will tend to ignore your requests for chunks of the file in favour of others. So your download speed will be worse than if you uploaded. This works better than, say, what Kazaa tried, because Kazaa trusted what you said about how much you had uploaded, making it easy to fake. You can't fake how much you have sent to someone else, because they know.

This is separate from the issue of trackers which track how much you upload and change your permissions based on that. Which is something done outside of the bittorrent protocol.
posted by markr at 1:31 AM on June 27, 2007

"BitTorrent is tougher to 'stop'. If the RIAA wants to stop a file from getting distributed on eMule, they just need to shut down that single uploader"

Er, this is only true if only a single user has it, otherwise it'll be distributed across multiple users, just like BitTorrent. The primary difference is every user on a torrent is trying to get the same thing, while more traditional P2P systems like eDonkey are more geared towards searching and sharing arbitrary sets of files.

If I wanted to share my entire music collection on eDonkey (the protocol eMule uses), I'd just add them to my client and connect to a server to advertise them. To do the same with BitTorrent, I'd create a .torrent file, set up a tracker and "seed" them, probably uploading the torrent to an indexing website.

BitTorrent would make it easier for users to get everything in my collection, eDonkey would make it easier for them to find specific items in the collection, alongside other versions from other users.

"BitTorrent is almost completely decentralized. ... There is also no central server organizing your connections"

This is only true if you're not using a tracker, which many clients depend on (and which are generally used anyway?). There are a lot of different trackers, yes, but there are also lots of different eDonkey servers. Both also have their respective fully-distributed protocols based on distributed hash tables; eMule's Kad, and BT's DHT.
posted by Freaky at 2:22 AM on June 27, 2007

aubilenon's got it. I didn't realize eMule had developed so much since I last took a look. These days I just get my NNTP piped through HTTP so I don't have to worry about bandwidth throttling, whether the seeder will bail at 99%, or fake files (for the most part).

eMule and Bittorrent both share partial file downloads. When you download a file from someone, it usually takes a while before the file is complete. With previous technologies (like Napster) that meant you had to wait until you had completely downloaded a file before you could start sharing it with others.

Also, both systems appear to use a distributed client list. The only real difference I can tell is that eMule requires you to run a server if you want to share files, whereas with Bittorrent you need a tracker. Either one represents a single point of failure, but both are easy enough to create.
posted by Civil_Disobedient at 3:26 AM on June 27, 2007

Most of these answers are on the technical side. Here's the effective difference:

Bittorrent is generally faster, but you're limited by which torrents you can find and which still have seeders.

eMule is generally slower, but you can find nearly anything because the content is more static.

They work well in conjunction: if you can find an active .torrent, use BT. If you can't, you can be pretty sure that it's available on eMule.
posted by Mayor Curley at 4:21 AM on June 27, 2007

'I haven't come across a client that'll download without upload, but maybe I'm wrong.'

Neither have I, but it's certainly possible to find yourself in that situation due to firewalling, in which case as I said, and markr said in more detail, other clients will be less likely to send you the data you request.

Some downloading must always happen without an upload, just to get you started within the swarm.
posted by edd at 5:18 AM on June 27, 2007

Thanks for all your answers. I'm still just a little unclear about something:

rancidchickn said "eMule-
When you go to download a file, you are downloading the file from some guys computer who is sharing it.

Civil_Disobedient said "eMule and Bittorrent both share partial file downloads"

So, if in eMule I'm getting a file from some guy's computer who is sharing it, how does it work with partial file downloads?
posted by CrazyLemonade at 8:50 AM on June 27, 2007

how does it work with partial file downloads?

There's a cheat sheet called a dummy file which keeps all the bits of data in order.

"What is Bit Torrent" is the best (easy to understand) explantion of the technical side of BT and why it's different from other types of file sharing.
posted by squeak at 10:17 AM on June 27, 2007

note to self: when mind is elsewhere it is best to not hit post before thinking things through
posted by squeak at 10:53 AM on June 27, 2007

Both split files into chunks, and concentrate on transfering those file fragments instead of entire files. Everybody agrees on a chunk size to make things simpler and easier to verify -- the first thing P2P apps do when starting a download is to get a list of these chunks and their checksums to make sure they transfer correctly. In the case of eMule, these lists are grabbed from other clients (multiple times, to help identify broken/malicious clients, wrong files and so on) -- in the case of BitTorrent, they're contained in the .torrent file.

As for as uploading and downloading partial files, eMule allows a peer to say "I have the following 1/8ths of the file you want: 1, 4, 5, 6" when asked; since your client has a list of peers either with the file or in the process of getting it, it can ask lots of them and try to grab the bits which are missing on your side from any which appear to have them.

That "1/8th" thing sounds like it could be a considerable bottleneck for large files, since lots of clients with substantial portions of a file may still not advertise having any sections -- if you're grabbing a 700MB movie file, say, you'd need to get nearly 44MB of it in one 88MB area of the file before saying "I have this 1/8th" won't disappoint more than it helps.

By comparison, BitTorrent appears to let clients know specifically what parts they have: "When a peer finishes downloading a piece and checks that the hash matches, it announces that it has that piece to all of its peers". This Likely increases overhead a bit, but has the benefit of making it easier to make immediate use of new peers.


OK, maybe I don't do simple terribly well
posted by Freaky at 11:01 AM on June 27, 2007

So, if in eMule I'm getting a file from some guy's computer who is sharing it, how does it work with partial file downloads?

You can't think of files as singular entities, like a contiguous block of "stuff". In the real world, a program is just a bunch of ones and zeros. If you've only download some of a file, why shouldn't you be able to share it? It only helps everyone else... the more people who are sharing, the faster everyone's download will go.

Think of a program like a book. I want all my friends to read this book, and they all want to read it. But I have to photocopy one page at a time. If everyone had to wait until they had completely "downloaded" the book (me making them a complete copy of the book for them), it would take forever! Instead, what if each of the people I'm giving a page to can also photocopy their pages and give them to the other members of the group that don't have them? That would significantly decrease the amount of time it would take for everyone to get a copy.
posted by Civil_Disobedient at 9:13 PM on June 27, 2007