>> You can make it this way by having a subscription request have a unique ID so >>that multiple subscriptions to the same data will each have their own ID on >>the >>request. Then a subscription request will not join to itself if it collides >>with itself, but will join and discontinue if it collides with another >>subscription graph. A malicious attacker may be able to create cycles however >>by repeating the subscription ID. > > > Well, technically, but then you need to have every single subscription > go through every node on the chain. Which is very bad.
No, not every node. Now would be a good time for an animation, but since I don't know how to make them: Every subscription request hops along until either its HTL expires or it encounters a node where that subscription request exists. If that node has that subscription from that request ID, it won't connect to that tree. If it does not, it will connect to the tree. Perhaps understanding will have to wait for an animation or at least a series of graphs. >> Properties of the subscription 'stream' >> no packetizing, dissolution of packet boundaries in the stream. > > Even TCP packetises. It has to. With TCP, the reading application can't tell where the boundaries of the packets carrying TCP were. The writing application can't tell what will end up in what packets of the TCP stream. That's what I mean by 'no packetizing'. Yes, TCP has to create packets to be carried on a packet network, but I refer to the level of interface presented to the user of TCP.
