This may be obvious to some, but it is posted for the benefit of the rest. This distributed programming project is beginning to directly pass some state between nodes. One thing we _can_not_ assume is that all node's clocks will be synchronized. It is Wrong to ever send an absolute timestamp (wall-clock time) in any message between two nodes. It IS valid to use relative times; however, there may be incoming messages in transit, at the point in time when another message is sent out. So the receiver can only "obey" this message once it is received. The issue is that we do not have atomic (send+receive) operations. As messaging begins to address very small timescales (say, under two seconds), we run the risk of discounting the network latency. This is why I would encourage data variables in messages to reference time in larger scales. For instance, a rate can be specified in events/second , or events/hour. While a rate can be scaled to use any other unit of time, if this rate involves network communications, it /may/ be beneficial to name variables in units that are greater than a second.
As an example, you may wish to say "please don't send me any messages of type X from now on," but there may already be one on the way. The word now has a different meaning to the sender and the receiver.
I just want people to keep this in mind, before writing code to pass messages that involve time. If we begin to make measurements of a remote node's willingness to obey our desires, we must recognize that these commands _cannot_ be obeyed "perfectly," and must take account of this fuzziness.
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
