[Spread-users] Max time delivery?

Jonathan Stanton jonathan at cnds.jhu.edu
Fri May 17 17:19:09 EDT 2002


On Fri, May 17, 2002 at 02:48:12PM -0400, Theo Schlossnagle wrote:
> My two cents... partially unrelated.  Clocks being out of sync?  Not 
> Spread's problem.  I think it is safe for any application to rely on 
> the system clocks of its cluster being in sync to the nearest 100ms or 
> so... It is a solved problem. "It's NTPs responsibility... not Spread's".

I certainly agree that providing clock sync is not Spread's problem.
However, right now Spread will correctly function if clocks are not
synchronized (with one very esoteric exception that noone currently cares
about), so I would be reluctent to add anything that would create such a
dependancy.

I have seen many cases of machines which are not synced (even if they run
ntp, i've seen timezone problems, network outages, and other wierdness).
Well managed clusters should have good syncronization. Since Spread is used
in places that are not all controlled clusters, I wouldn't want someone to
rely on a feature like that.

Sort of what bothered me about it is that if the time is screwed up that
way you won't see a clear error, all that will happen is messages will get
silently dropped.

> 
> As for having this feature in spread:  I guess I can see the advantage 
> of doing this in the daemon, because the user doesn't need to get the 
> message and then discard it, but aside from that, it is trivial to 
> implement this at the application level.  Unless there is a really 
> compelling reason to implement this in Spread (like reducing network 
> traffic tremendouly because you have many non-local clients and many 
> late messages, then I think it should be handled in the app -- it is 
> much more flexible.

Completely agree. It can certainly be done at app level and that is by far
the better place. The one advantage of a daemon implementation is taking
advantage of the already buffered messages and filtering before delivering
over slow links.

Jonathan
-- 
-------------------------------------------------------
Jonathan R. Stanton         jonathan at cs.jhu.edu
Dept. of Computer Science   
Johns Hopkins University    
-------------------------------------------------------





More information about the Spread-users mailing list