[21:02] <toad_> high bandwidth streams => vulnerable to bottlenecks =>
striping, ideally use passive requests
[21:02] <toad_> medium bandwidth, low latency streams => passive
requests are bad, preferable to use a single path
[21:03] <toad_> low bandwidth streams => either way is equally
reasonable
[21:03] <toad_> given that we won't be implementing 1:1 streams for some
time, i don't know how important the middle case is
linyos is concerned about bottlenecks. If we channel everything through
one key, then that makes a bottleneck - if the node is slow, or if any
node on the insert chain is slow, then it is a problem.
Conclusions:
- It is likely that the current approach of imposing arbitrary limits
will not work. We need to have the actual data in the datastore, with
LRU. This means, ultimately, implementing pub/sub over passive
requests - there are two approaches:
a) Spread spectrum - we subscribe to SSK at .../1, SSK at .../2, /3 etc.
This is more or less immune to "bottleneck" effects. But it is not
very efficient.
b) TUK-based - we send a passive request for a TUK, with a flag to
indicate that the passive request not be deleted when it fires. It
will then fire when new data comes in. This is more efficient than
the above because we do not need to maintain a large pool of
passive requests for future keys. But it is vulnerable to
bottleneck effects.
- We have not promised anyone that we will implement TUKs for 0.7.0, and
we should not do so unless it is necessary.
- If the current code on pub/sub is useful, we should get it working for
0.7.0. IMHO it isn't directly, but the thinking that went into it is.
That can be reused at a later date.
- It is possible to implement both fast and slow streams over passive
requests and SSKs.
- Passive requests have many of the same issues that publish/subscribe
has. There are however simple (but crude) solutions. The obvious one
being if we lose our parent node, instead of rerouting we just
forcibly disconnect all our dependants. They will then retry.
Coalescing can work exactly as in regular requests to ensure that the
passive-request tree does not get into loops.
Therefore:
- We should shelve the whole publish/subscribe project for the time
being.
- We should implement the basic functionality of freenet - splitfiles,
SSKs, FCPv2, etc.
- Passive requests, possibly TUKs, publish/subscribe streams etc. should
go into a future release. IMHO this should be 0.8.0. Premix routing
and 1:1 streams (in cooperation with I2P or otherwise) should go into
0.9.0. :)
--
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/20051020/3ae972ed/attachment.pgp>
