PDA

View Full Version : Multicasting?


View Full Version : Multicasting?


dr. damn
June 29th, 2003, 06:35 PM
The protocol for multicasting has been around a while now. Are their any p2p networks that use a multicast system for transfering data? It seems to me that it would save a lot of bandwidth and make transfers far faster if I could upload part of a file once to multiple users.

Nothingface5384
June 29th, 2003, 07:00 PM
isnt that what segmented swarming is?...or at least a form of it....

triniti
June 29th, 2003, 07:16 PM
edonkey and overnet use multicast file transfer. This reduces network overhead for each peer dramatically.

dr. damn
June 30th, 2003, 05:19 PM
Originally posted by Nothingface5384
isnt that what segmented swarming is?...or at least a form of it....
Nope. Swarming is when you download different parts of the file from one user. Multicasting is when one user uploads, say a segment of a file once, but the network infastructure is smart enough to deliver that segment to more than one peer.

Some (but not all) internet radio and TV works this way.

napho
June 30th, 2003, 07:20 PM
Freenet might be the closest to actually trying that. Also with Usenet 1 guy uploads to a group and hundreds of thousands download it from their isp servers. Now that's efficiency!!!

dr. damn
July 7th, 2003, 03:30 PM
Originally posted by napho
Freenet might be the closest to actually trying that. Also with Usenet 1 guy uploads to a group and hundreds of thousands download it from their isp servers. Now that's efficiency!!!
Not exactly... the servers get the short end of the stick there. It's not like multicasting where you "magically" turn one packet of data into multiple packets of identical data.

Nothingface5384
July 14th, 2003, 10:32 PM
ok ..its the complete oposite then..so i guess edonkeys HORDE system and the way BT uls is what Multicasting is....

FileHoover
July 14th, 2003, 11:36 PM
Multicasting is a specific TCP/IP feature that allows clients to subscribe to specific ip addresses (anything from 224.x.x.x to 240.x.x.x).

Unfortunately, multicasting has to be enabled on routers and the vast majority of people managing routers do not have it turned on.

For one, they mistakenly think it would increase their bandwidth usage when in fact it would lessen it, and two, it would be a security nightmare. If it were enabled throughout the net, it would essentially allow anonymous broadcast of any type of IP material, files, streaming movies, audio etc since multicast uses UDP and UDP packets can easily have forged source addresses.

It would not be that useful for file sharing because it would be more like cable television. You'd have to wait for the file to come around to get it.

It would be fantastic for a discovery protocol to find other nodes on a p2p network.

shellreef
July 18th, 2003, 01:39 PM
Originally posted by FileHoover
For one, they mistakenly think it would increase their bandwidth usage when in fact it would lessen it,
I'm all for decreasing my bandwidth usage. Less usage, more efficiency.

and two, it would be a security nightmare. If it were enabled throughout the net, it would essentially allow anonymous broadcast of any type of IP material, files, streaming movies, audio etc since multicast uses UDP and UDP packets can easily have forged source addresses.
Yeah, this could be a problem. Some sort of authentication mechanism may need to be built-in.. maybe a digital signature. But I have no idea how that would fit in a UDP packet. Maybe the completed file could be hashed and verified against a trusted digital signature using tree hashes or something. Security is undoubtedly a problem, but its not insurmountable.

Of course, multicasting could be very useful on a LAN where security is less paramount.

Although, this "anonymous broadcast" sounds enticing in light of the recent lawsuits.

There is also the problem of throttling and packet loss. TCP includes features to throttle the transfer rate down to an appropriate level (using a window), detect packet loss (acknowledgements), and re-order packets in the correct order (sequence numbers). TCP can't be used in a multicast environment however, so it has to be re-invented over UDP for this purpose. Which may not entirely be possible, but its worth a try.

It would not be that useful for file sharing because it would be more like cable television. You'd have to wait for the file to come around to get it.
To me, that sounds very useful. Audiogalaxy had a system like this, and it worked amazingly well. I loved joining groups and waiting for new files to come out... I didn't have to request anything. They just sent me the files when they were available. Worked like a charm. More peer-to-peer applications need to add this feature.

shellreef
August 9th, 2003, 11:57 PM
Found something:

Digital Fountain Transporter sends equations in place of data (http://www.eetimes.com/story/OEG20011211S0065) (it was linked from here (http://slashdot.org/articles/01/12/13/1351228.shtml)).

This company developed software that uses technology similar to "erasure codes" (a forward-error correcting technology), called Tornando codes (http://www.icsi.berkeley.edu/~luby/PAPERS/losscode.ps) (warning: PostScript file), that allows any packet to be lost, and the data reassembled from any other packet. This is the solution to multicast UDP data transfer. Its like PAR files on steroids -- and consequentially, the recipient(s) don't have to send acknowledgements/retransmits to the sender, making a spoofed UDP multicast transfer possible.

Here is what the developer's website (http://www.icsi.berkeley.edu/~luby/) says:

The proliferation of applications that must reliably distribute bulk data to a large number of autonomous clients motivates the design of new multicast and broadcast protocols. We describe an ideal, fully scalable protocol for these applications that we call a digital fountain. A digital fountain allows any number of heterogeneous clients to acquire bulk data with optimal efficiency at times of their choosing. Moreover, no feedback channels are needed to ensure reliable delivery, even in the face of high loss rates. We develop a protocol that closely approximates a digital fountain based on Tornado codes that are orders of magnitude faster than standard erasure codes (see below for a description of Tornado codes). We provide performance measurements that demonstrate the feasibility of our approach and discuss the design, implementation and performance of an experimental system.

There are papers available on that site detailing Tornado codes. Now all we need is a free implementation, and multicast file transfer will be a reality.

Update: its now an Internet Standard. RFC 3453 - The Use of Forward Error Correction (FEC) in Reliable Multicast (ftp://ftp.rfc-editor.org/in-notes/rfc3453.txt).

Theinfamousone
August 10th, 2003, 12:11 AM
Wow, that's amazing, the next generation of P2P apps look to not only be completely anonymous (we'll easily be able to forge the source IP addresses of those using the app) but we'll also be able to have multiple users downloading from a single source. Now that's exciting news. If Bittorrent used both of these, speeds would be incredible and you would be completely free of the MPAA/RIAA sueing you.