> The discussion of streaming so-far seems to miss my intention for > streaming, namely that data can be streamed out of Freenet as it is > being streamed in to Freenet - so someone could broadcast live-ish into > freenet, and Freenet will distribute this live streaming data, without > caching the entire output (which would be huge for a radio station > transmitting for even a few hours, let alone 24 hours a day!).
There are two ways to do this: "realtime" streaming in which a request for data is considered a request to join the stream being sent "in progress", and Freenet is just used to route the sender to the reciever. The other is to stream near-realtime, where different requestors want the stream at different time-points. The latter has to be done by blocking and buffering, and since Inserts are slower than fetches, a "transmitter" node would have to accomplish this by self-insertion; that is, simply making the data available in its own data store without actually inserting into the net (except as a consequence of the caching that will naturally happen when it is requested). The former is probably possible to do as well, but it is so foreign to what Freenet is now that I wouldn't even want to tackle it for 2.0; maybe 3.0. Even with that method, where the data is routed to node-registered recievers in realtime, there's still no reason to mess with the packet format since even this stream can be sent in packets with keep-alive connections. It may require new key type(s) and/or transport type(s). -- Lee Daniel Crocker <lee at piclab.com> <http://www.piclab.com/lcrocker.html> "All inventions or works of authorship original to me, herein and past, are placed irrevocably in the public domain, and may be used or modified for any purpose, without permission, attribution, or notification."--LDC _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
