pv%sun@CUNYVM.CUNY.EDU (11/15/88)
>Posted-Date: Mon, 14 Nov 88 15:13:22 PST
I've been looking at 1988 P3. Are there any co-ordinating rules for
P3? May both ends of a P3 association be acting as masters
simultaneously? Must each end act as both master and slave
simultaneously?
For example, can an MTS user invoke a DeliveryControl operation on an
association created by an MTA? Can it do so at any time? Must the MTA
be prepared to handle a DeliveryControl operation at any time? In
fact, must the MTA be prepared to handle the whole range of operations
such as MessageSubmission, CancelDeferredDelivery and Register?
Similarly, may an MTA invoke operations like MessageDelivery on an
association created by the MTS user? Must all MTS user programs be
written to handle SubmissionControl, MessageDelivery and
ChangeCredentials at any time even on associations initiated by it?
There are two issues here that make implementation tricky. First, the
initiator may not be equiped to handle the operations invoked by the
responder. For example, consider a program doing ChangeCredentials.
This MTS user would want to bind to the MTS, do its operation and
unbind. But once the bind has happened, it appears legal for the MTA
to do MessageDelivery or any of its other operations which this poor
MTS user would have to handle. While some of these operations can be
blocked by using control operations, not all can.
Second, the dual master-slave relationship implies that a program must
be prepared to handle incoming invoke indication at any time even while
one of its own operations is in progress. For example, if a MTA has a
message for some MTS user, the MTA has to be prepared to handle a
DeliveryControl operation before, during or after its MessageDelivery
operation. A simple, "send message and wait for response" paradigm
won't hack it.
The use of RTS turn management allows for synchronization of a half
duplex session but provides no help above ROSE. An entity cannot
postpone responding to an invoke until its own invoke is completed
because, if both entities did so, deadlock would result.
So what are people doing? Has anybody implemented full P3?
BTW, does P3 use ROS Operation Class 1 or 2? E.g. must the MTA wait
for one MessageDelivery operation to complete before invoking another?
PeteP4403@QZCOM.BITNET (11/17/88)
>X-Bitnet-Sender: "Johan Lundberg TeleDelta (Swedish Telecom)" <P4403@QZCOM.BIT
I think that you are correct about your statements reagarding
P3. P3 is not a true client server protocol. To overcome most
of these problems you stated P7 was developed. My understanding
is that with P7 the client has full control.pv%sun@CUNYVM.CUNY.EDU (11/17/88)
>Posted-Date: Wed, 16 Nov 88 13:43:06 PST > I think that you are correct about your statements reagarding > P3. P3 is not a true client server protocol. To overcome most > of these problems you stated P7 was developed. My understanding > is that with P7 the client has full control. P7 has a similar problem but on a smaller scale: the Alert operation is invoked asynchronously by the message store and so, if implemented, the client would have to act as slave for alerts at the same time it acted as master for the rest of the operations. Also, P7 implies a message store which must talk P3 to the MTS (unless co-located) so you've really only pushed the problem back a notch. Pete
P4403@QZCOM.BITNET (11/20/88)
>X-Bitnet-Sender: "Johan Lundberg TeleDelta (Swedish Telecom)" <P4403@QZCOM.BIT >P7 has a similar problem but on a smaller scale: the Alert operation is >invoked asynchronously by the message store and so, if implemented, the >client would have to act as slave for alerts at the same time it acted >as master for the rest of the operations. > >Also, P7 implies a message store which must talk P3 to the MTS (unless >co-located) so you've really only pushed the problem back a notch. I think you are correct about the alert function. However I do not think that it is that big problem that you make it. I guess that one could just "ignore" it. Concerning message store talking P3, I do not think that this will be the "normal" implementation. What I guess is that you will replace todays non- standard access protocol with P7 in the case of co-located UA and MTA.