Additions:
See TreePassiveRequests for more details.
Additions:
See also [[UltraLightweightPassiveRequests a much less ambitious proposal]].
Revision [2051]
Edited on 2007-05-18 21:07:24 by MatthewToseland [add some notes on security and flooding]Additions:
===Security===
It might be safer, locally speaking, to send a bunch of passive requests once (or infrequently) than constantly polling for unpopular data. However, it might also make life easier for a powerful traffic analyst: He might just be able to trace the entire flow from the insert through all the subscribers back home. Although if he can do this, he can probably trace requestors anyway? Plainly we are in need of some countermeasures!
===Flooding===
It is likely that sometimes nodes will subscribe to a whole bunch of keys e.g. the missing blocks in a splitfile, which the client has requested out of band be reinserted. We need to return the data in such a way that transfers don't timeout nor cause a problem for load management. I am reluctant to make the transfer optional, for the same reason that you can't probe for a key without requesting it... but there needs to be some way to schedule the transfers, or something.
It might be safer, locally speaking, to send a bunch of passive requests once (or infrequently) than constantly polling for unpopular data. However, it might also make life easier for a powerful traffic analyst: He might just be able to trace the entire flow from the insert through all the subscribers back home. Although if he can do this, he can probably trace requestors anyway? Plainly we are in need of some countermeasures!
===Flooding===
It is likely that sometimes nodes will subscribe to a whole bunch of keys e.g. the missing blocks in a splitfile, which the client has requested out of band be reinserted. We need to return the data in such a way that transfers don't timeout nor cause a problem for load management. I am reluctant to make the transfer optional, for the same reason that you can't probe for a key without requesting it... but there needs to be some way to schedule the transfers, or something.
Revision [872]
Edited on 2006-04-27 13:38:43 by MatthewToselandAdditions:
====Passive Requests====
Deletions:
Revision [857]
Edited on 2006-04-27 12:48:13 by MatthewToselandAdditions:
Unfortunately implementing a truly persistent passive requests mechanism is likely to be challenging: TruePersistentPassiveRequests .
