how-to block ads
|
|
Uniqs:
1297 |
Share Topic
 |
 |
|
|
| Multicast is GOOD, write for it today... patcat88 said:"I'm still waiting for Xcast (Explicit Multicast), or some system to let me receive or send multicast traffic in P2P.
P2P traffic would decrease exponentially if consumers had access to Multicast.
My 1 upstream stream of sectors of the file can duplicate to 100s of peers with only 1 copy of the traffic on each ISP, and it can go across long haul backbone fiber optics as 1 copy.
Only problem is if your download is too slow for my upstream stream, you will have to get "makeup" packets via conventional P2P P2P from peers who did get my packets.
Sectors with the most users needing them/rarest get sent out first.
So a torrent can be seeded to 1000 users in the time it takes for the initial seed to seed it exactly once.
"
"reply to Bar Humbug2U
Re: who cares HOW its used.. its PAID for by me anyways.
said by Bar Humbug2U :
the worlds ISPs simply dont and want turn the existing Multicast protocol back ON.
No multicast=users generate more traffic and pay for it, T1 vs T3, 10 mbit vs gigabit. If you want a Multicast IP, it will cost more than unicasting the traffic on a larger pipe. ISPs laugh all the way to the bank."
its good to finally see people talk and ask for Multicast capabilitys, iv been advocating Multicast in all its forms for a long time now but we need some coders to actually take the time and make multicasting an optionfor the masses to use TODAY.
thats why i pointed the readers to the most basic Multicast tunnel and and Bamboo multicast DHT, if you know of any torrent coders that are capable, its time to finally convince them to make the effort and refactor and retrofit new and existing code into the AZ torrents etc ASAP and make that generic Multicast tunnel available to push it all through.
BTW ,you wouldnt need to" "makeup" packets via conventional P2P P2P from peers who did get my packets" as even if all your Multicast DHT torrents would all be opening just 2 to 10 other multicast get,put,request,resend conections to other Multicast client/servers then any one of them could que up the missed parts much as unicast does now but in a timed que to allow more than a single request for that packet to come in and be qued up to multicast re-transmission etc.
a kind of "NEAR" realtime que for multicast use , a simple 5 minute countdown timer, that takes queed requests for packets at its most basic use could work fine.....
remember its all going through the generic multicast tunnel at the alpha/beta (plugin)multicast trial stage as we cant assume any world ISP has turned on Multicast at the generic level to and fromthe end users.
we cant rely on the worlds ISPs to turn in it SO DONT EVEN TRY AND WORK WITH THEM to start with, in time if and when such a simple generic multicast tunnel for P2p/torrent multi-point to multipoint use is working and passing all your data, its then up to the ISPs themselves to finally turn on real multicast and start saving bandwidth thats already in place as they can start telling people to use real multicast instead of using the tunnels....
the torrent coders need to make this multicast tunnel and retro-fit the multicast DHT into a plugin or in the core, if they can make time for this uncast UDP retrofit, they can also make time for a the basic multicast DHT and tunnels i already pointed to above " Mtunnel" and Bamboo DHT"
are you a torrent coder patcat88 ?, if so just make some time and try and push some multicast DHT through that simple and free java bamboo and Mtunnel and see if you are capable of making something innovative from the existing free working code.....
put simply, even if only 2 to 10 torrents are using viable multicast through a tunnel, thats almost a 10 fold saving (allowing for overheads etc)in bandwidth and time for all taking part in any alph/beta AZ torrent plugin and thats got to be a very good thing for your upload bandwidth , getting far better as time and users grow to it to save their bandwidth.
OC as i already said and you restated, far better use of local (lan/WAN/DHT/ISP sections etc)"No current P2P system and no realistic future P2P system actively attempts to talk to local (same ASN/ISP/city/least hops) peers vs distent peers." in all its forms both unicast and Multicast
it takes someone willing to make these simple DHT code changes and add in the required basic new code, will you be the coder and gave everyone greatful to you for making the P2p/torrent better for all! | |
| Multicast won't improve the situation that P2P presents one bit. Multicast only works well in a one-to-many broadcast situation, such as a video stream or streaming radio station.
--
There is no such thing as too much vacation, but I would wager that there is such a thing as too little. | |
| said by NetAdmin1:Multicast won't improve the situation that P2P presents one bit. Multicast only works well in a one-to-many broadcast situation, such as a video stream or streaming radio station. with respect NetAdmin ,NO IT DOESNT, if you read that paper i linked to above »www.cl.cam.ac.uk/research/srg/ne···port.pdf
it make it perfactly clear your View is the antiquated old school way of thinking, and is just an excuse NOT to provide it to the end users.
if the worlds ISPs were to simply make the existing and generic Multicast protocol available to and from the end users CPE desktop kit, and if it had no value as you imply, your worlds ISPs have wasted nothing in finally turning it back ON in their internal configs as onone would use it ,so turn it ON and tell people you have done it and see what happens.
i put it to you that if it is made ISP and globally available to end users and coders, then you would see lots of retrofitiing to many bandwidth useing unicast apps to take advantage of the multicast protocol for MANY things other than user to user streaming IP muticast video, although that's not a bad thng to use it for anyway.
after all IP muticast and IP broadcast was designed to from the onset of the IP internet to be used for mass point to multipoint and multipoint to multipoint transfer of ANY data you care to mention, not just "near realtime" video just as the "IP broadcast" was for the far larger IPTV MASS viewer use , but you can use that IP broadcast eather as the worlds ISPs dont turn it on....
so your "Multicast won't improve the situation that P2P presents one bit" statement is totally wrong,IT WILL help save massive bandwidth of someone writes and refactors the current unicast codebases.
give the end users and coders direct access to the multicast protocol and/OR the torrent coders finally produced a multicast tunnel and related code so as to totally bypass the antiquated thinking of the ISPs regarding Multicast as seen in your comment, and we might finally get somewere, far better bandwidth and time saving than this unicast UDP torrent codebase thats for sure. | | |
|
| You read the paper, but did you understand the paper beyond the experimental use of multicast in P2P setups? Do you understand the issues that implementation of such a design would create? Do you understand the network and infrastructure issues? Do you understand the issues of scalability in such a design?
it make it perfactly clear your View is the antiquated old school way of thinking, and is just an excuse NOT to provide it to the end users. Antiquated old school? Not even close. Skeptical of real-world benefits and cautious of the issues that would be caused because I know how multicast works, yep.
Do you understand multicast or how it even works? Do you have any clue of the issues that would be caused in routers in a design like this where P2P sessions are constantly built and broken down? Do you know the status of multicast support across the dozens of hardware and software platforms out there from the OS to the $40 Linksys router at your house?
I'd wager you do not.
--
There is no such thing as too much vacation, but I would wager that there is such a thing as too little. | |
|
