[Council] JEP - 0023

DJ Adams 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)
            return M_PASS;



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 mailing list