Open Stack

On Thu, 2013-04-25 at 14:42 -0400, Eric Windisch wrote:
> We do have true concurrency. It might not be used everywhere, but we
> have it.  
> 
> You could run multiple copies of nova-scheduler on the same host. They
> could both generate the same timestamp + source, assuming that source
> was 'service_name + hostname'.  The only workaround for that would be
> to make the source include the PID as well… until/unless we get
> in-process concurrency, at least. Does the remote system really need
> to know the PID? That could be a security thread. Perhaps we should
> hash it… wait, this is getting complicated...
> 
> Why block everything synchronously on a single source of time or
> counter when we can simply use a nonce?

The main reason was to avoid having to store many records on the
receiving side. Using a monotonic timestamp you just need to keep around
the last received one and if a message with an equal or older timstamp
comes around you simply discard it.

Is it possible to receive 2 valid messages from the same source in the
wrong order through the massage queue ?

If that is possible I guess using a nonce will be necessary, but I dread
having to keep a dictionary of received packets, search through it every
single time you receive a message, scrub it regularly to prune old
entries and so on.

I have witnessed how the replay database was cause of various
performance issues in the past in libkrb5 and would like to avoid
complex replay detection schemes if possible.

Keep in mind this database would have to be on shared if you really run
multiple processes with the same name on the same host as they all have
to share the replay database, so you need to use shared memory or IPC
and some sort and locking ... which tends to slow done processing and it
is usually a blocking operation.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York