Subject: Re: Washington Issue 14 - Errors when parsing

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 29 Nov 1999 13:59:19 -0500

> > Let's see....
> >
> > You can send an error at the Transaction level:
> > message              = MegacopToken SLASH Version SEP mId SEP
> >                        ( errorDescriptor / transactionList )
> >
> > The real question is whether we want to create some
> > explict TransactionError which could get you finer grain
> > isolation of the error.
> >
> > I'd say no, this is one of those pretty fatal errors (the
> > initiator can't really recover from this kind of error
> > except in some way ignoring it, which has to be wrong).
>
> (1) I agree with you that error in TransactionReply is a
> fatal error and it will
> be difficult to recover from this kind of error. So what are
> the various
> possibilities of recovery:
>
> a) the entity receiving erroneous TransactionReply sends back
> an error message.
> This as you have pointed out above will not help.
>
> b) an alternative can be that the entity can keep a count of
> the no. of times
> such an error occurs and breaks the association  when the
> count exceeds a
> particular threshold.
>
> Chances of errors in TransactionReply should be rare (coding error or
> configuration problem) but we should define some mechanism of
> dealing with it
> when it occurs.
> Please give your feedback.
>
I think a) is the best course of action in this case.  It won't recover,
but it gives the most direct response possible.  b) simply delays the
inevitable and is less desirable IMO.

> (2) In one of the previous mails on this thread, you had
> mentioned the following
> additional error codes:
>
> 540 - Syntax Error in Transaction Reply
> 541 - TransactionIDs in Reply do not match Request
> 542 - Missing command in Transaction Reply
> 543 - Illegal Duplicate Transaction Request
> 544 - Illegal Duplicate Transaction Reply
>
> I am not sure of the usefulness of error codes 543 and 544.
> When we have ALF/UDP, we can have cases of duplicate
> transaction request and
> duplicate transaction reply and those shuld not be treated as errors.
>
> In the first case (543), either a reply is resent or the
> transaction is ignored
> (if ack for the receipt of reply has been recieved - concept
> of ResponseAck).
>
> In the second case (544), one can not know that it is a duplicate
> TransactionReply as the first TransactionReply would have closed the
> transaction, at best it can be transaction reply for an
> unknown transaction id.
> I suggest in such a case it would be better to ignore the
> reply rather than to
> send an error message back.
Hmm, probably correct.  I'll think some more about it.

Brian

---

From: Harpreet Singh Anand <[email-masked]>
Date: Tue, 30 Nov 1999 15:57:42 +0530

> inevitable and is less desirable IMO.

Option a) is better if we define the action to be taken by the entity receiving
error message for a TransactionReply to be breaking the association.

If there is no action defined, then a) is not achieving anything.

Regards,
Harpreet

_________________________________
Harpreet Singh Anand
Ficon Technology
E-mail :  mailto:[email-masked]
Web    :  http://www.ficon-tech.com