[Council] JEP - 0023

David Waite mass at akuma.org
Mon May 13 12:02:02 CDT 2002

DJ Adams wrote:

<snipped comments and code>

>So, what mod_offline.c does here is calculate based on pure seconds, rather
>than a physical timestamp. I'm assuming this was intentional for the very
>reason you state. A 'secret' attr 'stored' is used to work out the number of 
>seconds the message was in storage (/me thinks of Eddy Murphy's dusty porsche
>in "48 Hours" for some reason) and subtracted from the 'public' attr 'seconds'
>when it gets finally forwarded. 
>So the argument about a time-based TTL across non-synchronized servers is
>perhaps not appropriate, as the T is expressed in neutral seconds. This is
>of course assuming (now, as before) that the time taken between storage events
>is negligible (otherwise a cross-server TTL would be virtually impossible to 
I think my comments stand; the expiry information is only processed for 
offline messages within the existing implementation, meaning that a 
twenty second delivery path will not cause messages with a one second 
delivery expiry to be tossed; they will be delivered unless they are 
sent to offline. Even without this, time would need to be synchronized 
between machines in order to have accurate TTL; the best you could do is 
change the original seconds stamp before rebroadcast, but that is not an 
ideal solution (besides changing the message, you will be ignoring 
network transmission time).

Its easier to just say what this really does; it allows offline messages 
to time out, or to not be delivered if the recipient is unavailable. It 
does not affect delivery to available delivery endpoints in current 
implementations, and really cannot without imposing some manner of time 
synchronization between components and between server across the internet.

>Secondly, I wonder how useful a per-hop TTL (as you suggest) would be. It's
>the originator that usually sets the TTL for obvious reasons, and one can
>hardly expect either the intermediate stations to (re)impose a further TTL
>(if that makes sense) or the originator to know the number of hops, or more
>relevantly the number of offline storage events, a message might take
>(especially for example in the light of the new component-related offline 
>storage feature in 1.4.2).
I don't think a per-hop TTL would be very useful at all - one across all 
hops including the recipient client might be (if they look at this 
meeting request within five minutes, it doesn't make sense for them to 
ever get it). Even then - in the realm of IM, you would probably end up 
wanting to have the message for UI reasons.

-David Waite

More information about the Council mailing list