At the moment, our swapping implementation works like this: Every ~ 2 seconds, the node checks whether it is locked. If not, it sends out a swap request. Swap requests are routed randomly for 6 hops. If the destination is locked, that's the end of the request. If not, the destination replies, the source replies, the destination replies (2 round trip commit/reveal protocol designed to make it obvious whether a node is selectively rejecting swaps; no detection yet nor security because we don't know the topology), and they decide whether to swap. If they swap, this is executed simultaneously by both sides and each tells its peers its new location.
This is why the vast majority of swap attempts fail in "swapsRejectedAlreadyLocked" on the stats page: # swaps: 11 # noSwaps: 1166 # startedSwaps: 3315 # swapsRejectedAlreadyLocked: 6962 # swapsRejectedRateLimit: 12 Proposal: We queue swap attempts. If a node is already locked when it receives a swap request, and its queue isn't full, it either doesn't respond until it gets through the queue, or it sends back a message indicating that the swap will be delayed, and perhaps by how long. Once it gets through the queue, it sends back a reply and the swap proceeds normally. This should result in many more swaps for the same number (or slightly more) messages. -------------- 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/devl/attachments/20061212/d749db26/attachment.pgp>
