I've been thinking about how federation should work with regard to the commit notice.
Here's a scenario to explain my thinking: 1. Remote sends three deltas to Host. It persists the deltas and does not remove them from the outbound queue until the Host acknowledges receipt. 2. Host persists the deltas to a FIFO input queue before acknowledging them to the remote. 3. Host applies the deltas and associates the applied delta with the original that is still on the input queue. 4. Host sends applied deltas to the Remote 5. Remote persists applied deltas to a FIFO input queue before acknowledging receipt. 6. Remote applies the deltas and marks them as processed, in memory, but does not delete them from the input queue. 7. When the Host commits the applied deltas it deletes from the input queue the associated original deltas, all in a single transaction, then sends commit notice. 8. Remote receives commit notice. It persists applied deltas and removes them form the input queue in a single transaction, then acknowledges the commit notice. If the Host dies after applying and sending the deltas to Remote, but before committing them: 1. When Host restarts, it will begin processing all deltas it finds on the input queue. 2. After application it will send out new applied deltas. 3. When the Remote receives these "duplicate" deltas, it will compare them to the previously received set of applied deltas. 4. If the new applied deltas is identical to the original applied delta with the exception of the timestamps, then the Remote will update the timestamp on the original but do nothing else. 5. If the new applied deltas does not match the original the Remote will mark the Wavelet as broken. This should not happen unless the Host fails to reapply the deltas from the input queue in the order in which they where received. If the remote dies before it has committed the deltas, then it will reprocess items from the input queue. In order to ensure that the persisting of messages in inbound queues does not slow things down, the need to allow for multiple "in flight" messages. Basically a server would send all new messages before old ones have been acknowledged, but would have some upper limit on the number of allowed "in flight" messages. It would also back off on transmission rate based on the delay between sending the message and when it is acknowledged. If the delay between oldest sent message exceeds some amount, then all furthor transmission is halted and the oldest message is re-transmitted repeatedly until it is acknowledged. The retry rate should back off logarithmically but the lower limit should probably not go below once per day. -Tad -- You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
