Long-lived publish/subscribe streams present some problems: 1. We will have to restart the node sometimes. We may want to post to it from a different node. We cannot guarantee that we always have the number of the next post. 2. We may want to give the private key to more than one person. So we will have multiple posters.
In both cases, the problem boils down to this: A 1:many publish stream relies on sequence numbers. If we just have the key, we don't necessarily have the latest sequence number. We need to be able to find it, and the network needs to be able to deal with a collision. I propose that: - If a PublishData message chain does not reach any nodes on the subscribe tree, it returns an FNPPublishFailed, to indicate that nobody is listening. - If a PublishData reaches a node on the publish tree: -- If the packet number is already used and the packet cached is identical to the one being sent, we return an FNPPublishSucceeded. -- If the packet number is already used by a different packet, we return an FNPPublishCollision, including the highest unused packet number. -- Otherwise, we route up the tree to our parent. The same tests occur on that node. If we have no parent, we are the root. We therefore have the final say. If we have not received any packet with the same sequence number, we accept the packet, definitively, and broadcast it to all our children apart from the chain which just sent it to us. To that chain, we send an FNPPublishSucceeded. This then results in the data being propagated downwards off the nodes involved in the chain. It has been pointed out that the parent nodes, and especially the root node, can do some mischief. This is true. Self-regulation is quite difficult with the new routing algorithm, unlike with NGR. However a tree is the natural structure for the structure that the subscribe system uses; it is simply the convergence of many routed subscribe requests. The root is the node which can no longer find a closer node to the target key, within HTL, than itself. IMHO there will be ways to make this self-regulating and defend from cancer nodes in the tree. The way we would obtain the initial sequence number to send would be by subscribing to the tree. This then presents a problem: timing attacks. The way to beat timing attacks is to send the data from the bottom of the tree... so instead of having the subscription tree plus the PublishData chains (which are not persistent), we just have the subscription tree. When we send data out, we first subscribe to the tree, and then we send it up the tree; we wait for success or a collision. Perfect. I will send more detail if necessary in the near future. -- 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/20050920/7b924e2d/attachment.pgp>
