On Tuesday 13 May 2008 00:44, Michael Rogers wrote: > Evan Daniel wrote: > > The major change needed would be a way to request not the specific SSK > > block, but the SSK, whatever CHK it happens to redirect to, and any > > CHK blocks needed to decode the result > > Exactly, so you'd need a different protocol, different data formats and > a different routing implementation to cope with the latency - which > raises the question, why use Freenet instead of building a separate network?
Why would you need different data formats? Well there are two options here: 1. Bigger SSKs, big enough to contain the entire message. Bback has asked for this for Frost, but I'm not sure what the advantage is: it would make uploading spam slower, but it would also make downloading it slower. 2. True (non-key-based) publish/subscribe. 2. Higher level requests, as a latency/security tradeoff. These could use the same keys, or very similar keys, but clearly they are somewhat different to how we do things now. In any case the client level protocol doesn't have to be much different. Even with the same exact request semantics, hopefully your neighbours would hopefully be subscribed to the same stream, in which case, the latency would only be a single local round trip. > > > -- plus a way to prevent that > > being a DoS attack (tit-for-tat?). > > How would TFT work in this context? Say Alice sends Bob a batch of > requests and Bob doesn't find the data - does Alice punish Bob for > black-holing the requests or does Bob punish Alice for trying to DoS > him? What if Alice was only forwarding the requests for Carol? > > I have some ideas for DoS-resistant routing, but they're only suitable > for long streams of messages between the same endpoints, and the > endpoints need to share an authentication key. I'm not sure whether they > could be adapted to anonymous pub/sub. There are ways to limit the damage e.g. by only allowing a certain number of requests at each priority level for any single peer? > > Cheers, > Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080513/0be0d4be/attachment.pgp>
