On Tue, Sep 06, 2005 at 09:30:06AM +0200, freenetwork at web.de wrote: > >How so? > > dunno, but as i/r (0.5 insert and retrieve) and p/s are in effect entierely > different services using oscar-routing ;) on the network fabric I could > imagine that there are > * different security aspects on both (i/r: correlation if a splitfile breaks > up into many requests, p/s: (real)time timing attacks, traces through the > tree, detectable subscription mechanics?)
Well maybe traffic analysis... and lots of attacks if you can control the topology, but you can't. > * combined aspects as both (all) services use the network fabric and its > routing for different purposes. > so I'd assume that every single service has to be reviewed for > anonymity/security issues > > * would a plug-in architecture for services work? then again... that's of not > much use as a plugin had to be widespread to work at all as not understood > messages ought to be dropped. Wouldn't make sense for the reasons you explain. Also security issues. > * would it be possible to deactivate a specific service? issues? No, because that would break the service for the whole network. > > >> * There was a streaming test implementation in the old 0.4 aera made by f= > >ish featuring FECed chunks of data that were adressed like edition freesite= > >s (there was some additional meta IIRC). So you could skip within that stre= > >am, old unwanted parts of the stream would fall=20 > > errata: it was a DBR :) > > >Indeed. Which never really worked across the network, was absurdly > >inefficient, and at best could have achieved latencies of minutes. I > >think we estimated that 90 seconds might be achievable at one point. > >Failure tables meant that half an hour was a realistic minimum at the > >time, but are no longer a problem. > > but it would be good for non-realtime audio- or videofeeds as it's mainly > designed for bulk-transfer? also it would be FECced, meaning the stream won't > fade too fast and could be (re)viewed at any time as the stream-data persists Or you could just download the file. :) There isn't that much difference really... > > >> * Are the datachunks cached and routed in the same way as normal freenet = > >CHK data? > > > >They are not cached in the same way, but the whole thing depends on > >routing. > > > >The function of the tree is to fan out the messages, so we don't have > >individual connections to each client from the root node. On each node > >in the tree, the data is cached, and a normal subscribe request will > >terminate when it reaches it. > > _are_ there any data chunks for p/s or is everything stored within the > controlling messages? how far a stream could be accessed into the past? We have 1kB blocks. We cache the last maybe 32 of them on each node in the tree, for each stream. > > >> * Are those streams to be understood as "shoutcast" audio streams? as new= > >sfeeds? as read-only filestreams? IRC-style streams? What are their main us= > >e and what are they geared for? bulk transfer? low latency? > > > >Anything from a non-polling RSS to IRC. Low latency. NOT bulk transfer, > > so it's not "read only" but a stream can be written into. from any > participant? then it would be like... a frost board, right? I assume any > posted message would hit the tree, wander to the root and trough the full > tree again. Now imagine this for many posts to that board. No. The original poster can write to it, because he has the private key. There might be uses of this which could use public or semipublic keys and more than one source, in future, but that's not the intention at the moment. > Wouldn't the tree stick out at network analysis? > > >> * What if DNFs are common? or at least often enough to have the tree brea= > >k into pieces having to Resubscribe over and over? > > > >Then routing doesn't work, and ordinary requests won't work either. This > >depends on working routing. However everything suggests that oskar's new > >routing algorithm CAN work. > > DNFs can happen even if routing works; either by broken connections (provider > auto-disconnect), shut down nodes (u wanna play qu4k3!), temporary network > throughput decrease (grabbing the new OpenOffice/Knoppix.iso/...), routing > flaps, etc. And even a > _single_ DNF would make the tree "panic" and wiggle around. I hope the > effects won't be too drastic if that happens Umm, that's what all the error handling stuff is about. > > >> Workflow: > >> You seem to be using at least some of your valuable (you being the only o= > >ne that is able to bring us 0.7) time on p/s. > > > >Volunteers are always appreciated. :) > > :) > > but even volunteers have to be qualified and have to know where the trip is > going to be able to help Volunteers can expect to receive a reasonable level of assistance, as they save us a lot of time in the long run. > > >> * What priority is it? Maybe this could be considered 0.7.2 stuff and get= > > 0.7.0 running first? > > > >I am of the view that something new and fun is important to the goal of > >getting some money and enthusiasm so we can continue to work on the rest > >of 0.7. IRC over Freenet is something we've never been able to do. And > >furthermore, IRC is a great way to establish a community, as shown by > >IIP and I2P. Certainly there is loads to do on 0.7; it just seems best > >to work on this first. We have basic insert/request working, we need > >splitfiles, and SSKs, and FCPv2, and fproxy, and rate limiting, and so > >on. > > so i/r is somewhat working but unusable for a end-user. > wouldn't it make sense to have at least something for the masses to play > before having tens of half-complete things which no user can enjoy? Completing everything will take ages. Building publish/subscribe will not take anything like as long as implementing everything else. And it will give something that users CAN use. > > 0,02? -- Matthew J Toseland - toad at amphibian.dyndns.org Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20050906/021dc8c2/attachment.pgp>
