On Sun, Jan 26, 2003 at 09:55:22PM +1100, fish wrote: > On Sat, Jan 25, 2003 at 11:49:46AM -0500, Gianni Johansson wrote: > > > 1) This doesn't belong in Fred's JVM. We have enough problems > > undertanding/bounding fred's resource consumption as it is. > > [exaggeration] > You could say the same about fec generally, and I'm sure you could make a > similar argument about fproxy as a whole > [/exaggeration] > > Seriously, I honestly can see your argument. You should be aware that there > are quite a few people who disagree with you on this, howver, and several of > them said to me that life would be better if there was a version of it > which could be possibly integrated into fred. > > This being said, I don't think this application is really *that* intensive - > it only runs at most around 15 requests at a time with the default settings, > which are admittedly not the most sensible, and around 25-30 requests at a > time with a buffer of 5 blocks, which is more sensible. Hmmm. That's pushing it IMHO. What does the thread load look like? > > > 2) How do you plan to address QOS? I have asked this question several times > > and each time it is ignored. > > My plans involve not addressing QOS in exactly the way that everyone else > doesn't. > > One could theoretically add QOS support at FNP level, but all that would > happen is everyone would mark their patches as urgent, therefore making the > entire exercise useless. Otherwise, flooding the network with urgent > packets would make quite an interesting attack. bad idea. > > QOS won't save the world in exactly the same way that UDP and multicast > didn't. What QOS does the internet have in general? We need simply to have enough local bandwidth, enough of a buffer, enough parallel requests and enough redundancy. > > > If you really want to do streaming you need to have a reasonable QOS > > gaurantee. I don't see how you are going to get this from fred. I am > > concerned that we are essentially encouraging people to write DOS clients, > > that don't have a chance of working in all but the most contrived test > > scenarios. > > Yes, I am writing tools to DOS the network :-p. I am teh l33t h4x0r. You mean like the Frost d00dz? Killer apps will always cause substantial load. We need to deal it. > > I do think you're being a little pessemistic here. Don't misread me, I don't > suggest for a moment that we are going to achieve truely live streaming, but > this being said I did manage to listen to almost an hour (57 minutes, if you > must know specifics) with a 15 minute delay being streamed from two of matt's > perminant nodes to my transient (ex)node. I know that this is not terribly > impressive, but the network is always (usually ^_^) improving. While this > test is partially contrived, because yeah, I was controlling both the client > and the server, it was nonetheless being transported through the production > network. Hey, not bad! This is at 32kbps? > > Perhaps it is stupid, and perhaps I am wasting my time. But I believe it > is within the realms of possibility, even if yours does not. I won't lie, > you need, right now, two nodes on a broadband connection to server a stream > at all reliably. This is obviously unreasonable. But I also believe that What exactly about it is unreasonable? Non-broadband nodes are generally worthless. > this situation will only improve over time, and is mostly fred getting > overloaded with insert requests (remember, inserts take at least 3x the time > of a retrieval :-p). (This is, btw, the reason the ClientInfo patch exists). NIO should help a lot [with load], and will be a primary focus of 0.5.2. What ClientInfo patch? > > > The right way (tm) to do this is to make a servlet that prefetches audio > > files and presents them for later retrieval over http. That would be cool. > > But don't call it streaming. You could even have play lists which could be > > updated via enumerated SSKs or DBRs. Use FEC, healing, and write a good UI > > and you might be pretty close to having the killer freenet app. > > This is not the right way(tm) to do this, and does address what I'm trying > to at all. The whole point of this exercise is live media. Where 15 minutes is "live"? :) I doubt we're going to ever get the lag down to a reasonable level, it'll always be far more than streaming over the regular inet... <flame>the only real use for it is to relay an existing stream over freenet, where you can't rearchitecture it into a DBR playlist or whatever... it looks to me like the non-infringing uses are pretty limited :)</flame> > > > Freenet *is not* a replacement for internet radio. It is much more > > interesting than that. > > While this is true, in my opinion, the architecture freenet is not the bad match > for this task that you believe it is. To be fair, you are far more of an > authority on what freenet is or isn't than me ;). > > - jj
-- Matthew Toseland [EMAIL PROTECTED][EMAIL PROTECTED] Full time freenet hacker. http://freenetproject.org/ Freenet Distribution Node (temporary) at http://amphibian.dyndns.org:8889/RMMHBxLOISw/ ICTHUS.
msg06415/pgp00000.pgp
Description: PGP signature
