cpdavis at student.umass.edu writes: > The basic idea is that it would be a file distribution and mirroring tool. An > auto-downloader, such as is so popular with software these days. The key, > however, is that it would use Freenet as the distribution system. > This would help to solve the bandwidth problems of free projects, trying to > distribute to a wide audience.
This should definitely work. There are people distributing their software (mostly freenet-related at this point) over freenet -- or they would if the network could hold its water. > To make it simple, I'd make two programs. One that just uploaded a > single .tgz, and the other which just downloaded, and installed it. The upload part is already implemented by the freenet node software. Since only you will be doing uploads it doesn't make much sense to write another tool to do it -- unless you have special needs, of course. Downloading is a bit different, as every potential user must do it. Your installer would either implement part of a node's functionality, or rely on a proper node and download via FCP (the simpler node-to-client protocol). The latter option would mean a larger initial download for people, but OTOH it may motivate more people to run nodes that would otherwise never have heard of Freenet. > One thought raised on #freenet was that of the file falling out of > the server. It is possible to re-insert content. I'd go for a scheme somewhat like this: * The installer tries to get the file via Freenet first, applying whatever timeouts necessary. * But you also put the file on a webserver. If fetching from Freenet fails, the installer uses this as a fallback. (You could deliberately throttle web downloads so that leet haxors won't simply bypass the Freenet step.) * When you notice increasing downloads from the fallback server, the file has probably fallen out of Freenet and it may be time to re-insert. > Alternately, I could run a node myself, and point the installer at > that node. You will need to run a node for uploads. Hardcoding this node into the installer won't buy you anything though -- you could just as well serve the file from a webserver in this case. The point of the exercise is to spread the load over a number of servers, no? > The target of this system would be, after large files were worked > out, to download a 650 meg game that my team will be distributing > sometime this fall. You should be aware that the current network is in no shape to reliably store 650 megs, and there is no guarantee that it will be better in fall. It's to be hoped, though. -- Robbe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.ng Type: application/pgp-signature Size: 232 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20020116/132aac91/attachment.pgp>
