I think we need a reliable 1:1 stream as a complement to the 1:many streams. For many applications, for instance for sending a message *to* an in-freenet IRC server, we need a 1:1 stream. It would also be very useful in other situations. It could also be bidirectional, and provide higher reliability. Equally importantly it would use less bandwidth than abusing a 1:many stream.
How do we do this? We have two types of subscribe for 1:1, both of which are essentially identical, but opposite. ConnectionSubscribeRequestA and ConnectionSubscribeRequestB, perhaps. These are both routed towards the rendezvous key, just as a subscribe request is for a 1:many stream. If they do not meet their counterpart, they will continue until they reach HTL, and leave a pointer on each node. So, one side sends out a ConnectionSubscribeRequestA. This reaches HTL nodes. Then the other sends out a ConnectionSubscribeRequestB. When this reaches a node with a pointer for the key for the ConnectionSubscribeRequestA, it sends a ConnectionSubscribeSucceeded to both ends, and a DropConnectionSubscribe to the "tail" of nodes which are no longer needed. Once we have established the stream, we can exchange data. Data is sent in packets of 1kB with serial numbers. The connection does not need to remain up when either side terminates, so we do not require excessive caching. We can ask for any packet to be resent. This request will be propagated as far as is needed to find the packet, and either the packet will be sent back, or a failure message (possibly the originator forgot it). Just as with the 1:many broadcast rendezvous-at-a-key streams, we will need to devise a means to control the bandwidth usage of such things. -- 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/20050917/623df5ae/attachment.pgp>
