Here's one possibility for major changes to pub/sub that might make it implementible:
Posting: A poster will subscribe to the stream, get all the recent messages, then send a message out with the next ID. There is no feedback on his post. Pub/sub is unreliable with multiple posters, and client authors must take this into account. It is suggested that client authors use one stream per client and build a web of trust. Bandwidth limiting / bandwidth allocation: We define a stream bandwidth limit in packets per second. We don't directly send stream data packets; we send them to the bandwidth limiter. This sends one packet every X, where X is 1000ms/bwlimit. It uses a round-robin scheduling algorithm. Scale: We have a limit of 4096 streams. We cache 32 packets for each stream. A packet is 1kB. This gives a total of around 128MB of data we must cache. So we cache it on disk, using an ephemerally encrypted random-access file. Propagation: In order to get maximum reliability and attack resistance (at the cost of what is hopefully a relatively small amount of bandwidth), when we receive a valid packet, we propagate it to every node we know is interested in the stream, which hasn't already sent us it. This means our parent, and our dependants. This check is performed in the bandwidth limiter, which is better called a StreamSender. Coalescing: Running subscribe requests are never coalesced. If a node receives a subscribe request, and it is successfully subscribed, and its root is closer to the target than the nearest-so-far on the request, it accepts the requestor node as a dependant. If the node is subscribing, it rejects it, with a fatal rejection message. The client is expected to do exponential backoff. For a resubscribe, we send a SubscribeRestarted to all our dependants, who will then let our request through. -- 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/2fd8d160/attachment.pgp>
