[Council] JEP - 0023
dj.adams at pobox.com
Sun May 12 14:41:34 CDT 2002
On Wed, Apr 24, 2002 at 01:38:00PM -0600, David Waite wrote:
> -1, I would like to see it explicitly stated that the TTL is only valid
> within a hop (e.g. TTL is not the total time to live for routing that
> goes between servers), and is only processed for delayed messages, such
> as offline messages.
/me continues to catch up with mail - sorry for the delay.
Ok, first thing, I appreciate the thoughts that DW always puts into these
JEPs and so on. So my disagreement is, as usual, a peaceful one :-)
So, I've noticed that relating to these issues that DW has stated above, and
the resulting point that has been inserted into JEP0023 (point 4.2: "A
physical, time-based TTL is not implemented by this JEP, and would not be
possible across systems without synchronized time.").
As always, I will gladly stand corrected, but permit me to quote some
code at you ;-)
from jsm/modules/mod_offline.c (1.4.2):
mreturn mod_offline_message(mapi m)
if((cur2 = xmlnode_get_tag(m->packet->x,"x?xmlns=" NS_EXPIRE)) != NULL)
if(j_atoi(xmlnode_get_attrib(cur2, "seconds"),0) == 0)
void mod_offline_out_available(mapi m)
/* check for expired stuff */
if((x = xmlnode_get_tag(cur,"x?xmlns=" NS_EXPIRE)) != NULL)
expire = j_atoi(xmlnode_get_attrib(x,"seconds"),0);
stored = j_atoi(xmlnode_get_attrib(x,"stored"),now);
diff = now - stored;
if(diff >= expire)
log_debug(ZONE,"dropping expired message %s",xmlnode2str(cur));
sprintf(str,"%d",expire - diff);
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
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).
Err, I think that was it :-)
More information about the Council