Re: TIP - node rules

Tom Freund <> Fri, 08 August 1997 10:28 UTC

Received: from cnri by id aa04065; 8 Aug 97 6:28 EDT
Received: from ( []) by (8.8.5/8.7.3) with SMTPid GAA21261 for <>; Fri, 8 Aug 1997 06:26:48 -0400 (EDT)
Received: by (8.6.12/suntan5.970212) for tip-relay id CAA16767; Fri, 8 Aug 1997 02:58:28 -0700
Received: from by (8.6.12/suntan5.970212) for <> id CAA16764; Fri, 8 Aug 1997 02:58:25 -0700
Received: from by (AIX 4.1/UCB 5.64/4.03) id AA34320; Fri, 8 Aug 1997 10:55:11 +0100
Received: by UK.IBM.COM (Soft-Switch LMS 2.0) with snapi via D06AU009 id 5060100004788417; Fri, 8 Aug 1997 09:59:07 +0000
From: Tom Freund <>
MMDF-Warning: Parse error in original version of preceding line at
MMDF-Warning: Parse error in original version of preceding line at
Subject: Re: TIP - node rules
Message-Id: <5060100004788417000002L072*@MHS>
Date: Fri, 8 Aug 1997 09:59:07 +0000
Mime-Version: 1.0
Content-Type: text/plain


> There might also need to be something about the relation between the
> and the particulars would be in the TIP + application protocol P spec
> (which I agree will be bilateral in the first instances), but there are
> some rules that it might be useful to state for guidance.

> One kind of rule, essential because of the two-pipe mechanism, is making
> sure the top-node (the travel agent in the requirements example) does not
> initiate commitment until all the subordinates have registered.
> Generalising this precisely may not be that easy. A particular might be:

      Doesn't the general rule need to also state that all applications
messages must have been
received by a server ... this would be the equivalent of the
OTS/implicit/checked behavior?

     Another case, not specifically on this point but related is
out-of-sequence messages ... i.e. a failure
in the server causes the server to restart at some random point in the
application message flow (btw a
point which is not covered in the OMG/OTS specification).

Tom Freund