Nonce-sense

At http://www.teaminfocenter.com/ProgrammingNotes2/HowToExample/groovenonce.htm, John Giudice introduces what I interpret as the kernal of Groove replication thinking - the nonce. As far as I understand it, all events are relative to that value, which is written uniquely when a Groove client first starts. The matter comes to mind partly because somehow even from the early days Groove has had a history of replication issues. Granted that 99.999% of Groove replication is by and large a wonderful thing, it has to be asked under what circumstances could it fail steadily over such a long period? Also granted that the main task of Groove is replication, so if it is going to "fail", then that's the area of focus.

As I look at my Groove inbox I see one message from someone with a datestamp ahead of others. New IMs are coming in and being religated, according to datestamp as earlier that this message that actually came in some hours ago. I am not saying that Groove is wrong in the way it presents this wierd event. I have taken part in live Groove Chat sessions where peoples responses are inserted above the latest posts. But is it right?

Everything is displayed in date order. But date order is not the order in which events happen. Of course why nonce's exist is to avoid the human interpretation. but at some point Groove must create an interface between the nonce and human dates. As far as I understand it the nonce is trying to be an independent way of replacing time-stamp thinking. Given the fickleness of human time-stamps including incorrect clocks, time-zones etc you can see the logic.

The result however is to put the nonce on a pedastel. The fact is that in some parts of Groove coding, at some level things are not perfect. Let me not paint a picture of Groove is unreliable, when the opposite is true. But my guess is there are nonce-related gremlins in there. My guess is that Groove's engineers have found many of them over the products life-span. However my guess also is that there are still a few left.

And where do these gremlins occur? Trying to imagine where the lack of nonce-sense lies I would guess it is in assuming information about the remote computer. Visibly errors typically do not in core data replication - not that that such a thing for a normal user to confirm! With Groove you see data arrive, you do not know what does not arrive! Issues that are obvious tend to occur in the messaging around that replication, invitations, IMs, notifications. These are the obvious manifestation of Groove's transport.

An important note is that a challenge for Groove is performance. And does it perform. Groove can replicate very effectively. But at what cost? Are there assumptions in that replication made to boost performance that are not being trapped, or the cost of trapping is too much to consider?

Am I talking nonsense? Probably, but my gut feeling is that solving this kind of puzzle is a lateral thinker's dream challenge. Oh, and by the way, in case anyone is unclear - the above is my supposition based on experience. I have no access to Groove internals. And in some (non-)senses perhaps that is a strength :-)

posted by Andy Swarbrick/PopG at 4:49

(Update. Looks like I may be way off beam on the above. Hugh Pyle (and he should know) pointed out that the nonce is a security measure for GWS, and that's all it is. It is nothing to do with dynamcs. Oh, well, it sounded good to me. - thanks Hugh.)