4 ms·

The article is a bit hazy on some rather important details, such as "are you going to use P2P for downloads" and "how will you route traffic to the nodes". Usi

by m_eiman 17y ago

The article is a bit hazy on some rather important details, such as "are you going to use P2P for downloads" and "how will you route traffic to the nodes". Using P2P means custom client software, which means that it can only be used to very specific things like application updates. I'm assuming that there will need to be some central point of contact that knows what content is available where - how will this be distributed and scaled? There's also the question of how to handle nodes dropping out of the network.

marcamillion 17y ago
This article wasn't meant to spell out everything, but just meant to prime the discussion pump in an effort to flesh out the idea from a 50,000 foot view. But to clear up any misconceptions, I am not purporting a new P2P application that people use to download stuff. I am essentially purporting a new protocol that replaces rmtp (the flash media streaming protocol) and other media streaming/distribution protocols. Routing the traffic is all a software issue. Same thing with nodes dropping out of the network. Bit Torrent (the protocol) has solved many - if not all - of those issues.
- m_eiman 17y ago
  I am essentially purporting a new protocol that replaces rmtp (the flash media streaming protocol) and other media streaming/distribution protocols. Ah. So you just need to either convince Adobe to add that to Flash, or have the users run an application that can act as a proxy between it and RTMP. It's not a question of if it's possible or not, the problem is that it's hard to sell the concept to a website after you mention the "oh, and every one of your users will need to install this piece of software to be able to access the site" detail. It'll probably be a reasonable trade-off for some sites with devoted users, but for sites that have a lot of random users that only go there once or very seldom, it'll probably make more sense to pay the higher price of a normal CDN. Or maybe you intend to run the P2P/RTMP proxy on the nodes instead? Either way, the problem with the node dropping is to handle it in a graceful way that doesn't rely on custom software on the user side. Since your nodes are going to be pretty unreliable, your users will need to be able to switch between nodes without interrupting a large download. For smaller files they'll just need to be able to restart the transfer, which is a bit easier. I'm assuming that you want to use the CDN for serving various web content, for which HTTP should do just fine for just about everything. You probably don't even need RTMP, progressive downloading with a hack to allow non-linear access works just as well for most uses.

by m_eiman 17y ago

marcamillion 17y ago

This article wasn't meant to spell out everything, but just meant to prime the discussion pump in an effort to flesh out the idea from a 50,000 foot view. But to clear up any misconceptions, I am not purporting a new P2P application that people use to download stuff. I am essentially purporting a new protocol that replaces rmtp (the flash media streaming protocol) and other media streaming/distribution protocols. Routing the traffic is all a software issue. Same thing with nodes dropping out of the network. Bit Torrent (the protocol) has solved many - if not all - of those issues.

m_eiman 17y ago
I am essentially purporting a new protocol that replaces rmtp (the flash media streaming protocol) and other media streaming/distribution protocols. Ah. So you just need to either convince Adobe to add that to Flash, or have the users run an application that can act as a proxy between it and RTMP. It's not a question of if it's possible or not, the problem is that it's hard to sell the concept to a website after you mention the "oh, and every one of your users will need to install this piece of software to be able to access the site" detail. It'll probably be a reasonable trade-off for some sites with devoted users, but for sites that have a lot of random users that only go there once or very seldom, it'll probably make more sense to pay the higher price of a normal CDN. Or maybe you intend to run the P2P/RTMP proxy on the nodes instead? Either way, the problem with the node dropping is to handle it in a graceful way that doesn't rely on custom software on the user side. Since your nodes are going to be pretty unreliable, your users will need to be able to switch between nodes without interrupting a large download. For smaller files they'll just need to be able to restart the transfer, which is a bit easier. I'm assuming that you want to use the CDN for serving various web content, for which HTTP should do just fine for just about everything. You probably don't even need RTMP, progressive downloading with a hack to allow non-linear access works just as well for most uses.