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.
> 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.
> 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.
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.
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
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).
> 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.
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 230 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20030126/41c4d29d/attachment.pgp>
