Open Stack

>  
> 2. A random number can repeat but it is very unlikely that will happen
> if you have a good random generator that has uniform distribution.  
>  
> I think you mean 2, because the chance we get out of the hat 2 identical
> numbers chosen at random within the same hundredth of a second on the
> same machine if the numbers are big enough, say 2^64, are very, very
> low, so we might decide to ignore that it may happen.
>  
> However, how bad is it is it *does* happen ?
I mean the latter and I believe this is sufficient. I believe worst case is that a message is rejected by the endpoint as a potential replay. In theory, we should be pretty resistant to lost messages, especially at the very low rate of occurrence we'd expect it.

I gag any time we mention interprocess locking, global counters, or state. I recognize might need to compromise here, especially in regard to multiple services on a remote machine receiving the same message, although I'd be careful about how we implement that.  The implementation details will be vastly different for AMQP, versus ZeroMQ.

For instance, the ZeroMQ driver could do first-pass replay detection in the ZmqProxy, which is a machine-global process. We'd still want to verify signatures in the consuming services, but as all messages pass through the ZmqProxy, it can outright reject duplicates. (This won't stop someone from killing the ZmqProxy and doing a MITM to allow replays - not but outright injection - but if that happens, the server is likely compromised already…)

The AMQP drivers won't be able to filter their replays centrally on the host unless it added a per-host consumer and local distribution pattern like we use in ZeroMQ. Without that, we'd need a local datastore with all the locking issues that brings with it.

Regards,
Eric Windisch