Comments on: Bandwidth Donation Protocol http://blog.stevex.net/2008/12/bandwidth-donation-protocol/ Software development and other notes. Fri, 03 Feb 2012 14:03:53 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: stevex http://blog.stevex.net/2008/12/bandwidth-donation-protocol/comment-page-1/#comment-493908 stevex Thu, 01 Jan 2009 13:25:36 +0000 http://blog.stevex.net/?p=1260#comment-493908 Good points, Seth. Yes, it does require that the podcast trust the donors. One of the constraints on the BDP is that it can't require changes to iTunes or extra software on the client. Maybe this is a showstopper. One possible solution would be to have a donor verification mechanism that ensures that you at least know who the donor is, so you have some recourse if they mess with you. Something like requiring you to make a $1 cash donation via credit card to get your donation server added. Redirecting back to the server when the donator decides it doesn't want to donate any more bandwidth is a good idea. Good points, Seth. Yes, it does require that the podcast trust the donors. One of the constraints on the BDP is that it can’t require changes to iTunes or extra software on the client. Maybe this is a showstopper.

One possible solution would be to have a donor verification mechanism that ensures that you at least know who the donor is, so you have some recourse if they mess with you. Something like requiring you to make a $1 cash donation via credit card to get your donation server added.

Redirecting back to the server when the donator decides it doesn’t want to donate any more bandwidth is a good idea.

]]> By: Seth Sticco http://blog.stevex.net/2008/12/bandwidth-donation-protocol/comment-page-1/#comment-493743 Seth Sticco Thu, 01 Jan 2009 00:34:21 +0000 http://blog.stevex.net/?p=1260#comment-493743 This places a lot of trust on the donor. They're trusting that you won't send a corrupted/altered copy of the data. BitTorrent has measures to prevent that sort of thing when sharing bandwidth. HTTP redirects don't. The other thing I notice is that you don't really need the 200 different urls. They should just have a pool of donors (and place themselves as a possible donor). When a request comes into what I'm going to call the master server, they can redirect to a random donor. If a donor server decides that it's served up enough bandwidth, it can respond to requests with a redirect back to the master server, which will randomly re-redirect them to a different donor. At the same time, the donor can notify the master server so it'll stop sending people over. The reason why the donor would have to notify the master server itself instead of the master automatically detecting redirects back is to prevent other people from maliciously cutting off a donor by crafting fraudulent requests. This places a lot of trust on the donor. They’re trusting that you won’t send a corrupted/altered copy of the data. BitTorrent has measures to prevent that sort of thing when sharing bandwidth. HTTP redirects don’t.

The other thing I notice is that you don’t really need the 200 different urls. They should just have a pool of donors (and place themselves as a possible donor). When a request comes into what I’m going to call the master server, they can redirect to a random donor. If a donor server decides that it’s served up enough bandwidth, it can respond to requests with a redirect back to the master server, which will randomly re-redirect them to a different donor. At the same time, the donor can notify the master server so it’ll stop sending people over. The reason why the donor would have to notify the master server itself instead of the master automatically detecting redirects back is to prevent other people from maliciously cutting off a donor by crafting fraudulent requests.

]]>