harald.alvestrand@elab-runit.sintef.no (08/06/90)
Can someone help me out on this one?
I have tried to make a "robust" TP0 server that functions according to the spec
(well, actually it is RFC1006....)
The standard (X.224, Blue book version) claims that Appendix A, the
state tables,
gives "a more concise definition....".
A bit too concise for me, it seems. Watch this:
- A network connection is set up.
- A CR TPDU arrives. Transition: CLOSED to WFTRESP, indicate TCONind to user.
- The user refuser using TDISreq. Transition: WFTRESP to CLOSED, send a DR.
Now what?
I cannot close the connection, because that will likely eat the DR.
Besides, there
is no close indicated in the table.
An NDISind on this connection (Transport connection is identifiable
because I am
in class zero) will hit the empty field where CLOSED and NDISind meet in
the matrix, indicating a protocol error.
There is no timeout given, so I cannot close the connection after a timeout.
What is the opinion of the standards writers on when the network
connection should
be closed, if the sender part does not take proper action and closes it?
Harald Tveit Alvestrand
Hacker of ISO-everythingajw@mel.dit.csiro.au (Andrew Waugh) (08/07/90)
In article <1990Aug6.111420.13755@idt.unit.no> harald.alvestrand@elab-runit.sintef.no writes: >- A network connection is set up. >- A CR TPDU arrives. Transition: CLOSED to WFTRESP, indicate TCONind to user. >- The user refuser using TDISreq. Transition: WFTRESP to CLOSED, send a DR. (All references are to the Blue Book, X.224). Section 6.7.4 covers this: 6.7.4 Procedure for implicit variant [of normal release] In the implicit variant, either transport enitity disconnects a transport connection by disconnecting the network conncection to which it is assigned. When a transport entity receives an N-DISCONNECT indication, this should be considered as the release of the transport connection. Class 0 Transport only uses the implicit variant of normal release (see 6.7.1). andrew waugh
harald.alvestrand@elab-runit.sintef.no (08/07/90)
In article <1990Aug6.235903.23530@mel.dit.csiro.au>, ajw@mel.dit.csiro.au (Andrew Waugh) writes: > Class 0 Transport only uses the implicit variant of normal release > (see 6.7.1). Sorry, but no. This bit me too, once. DRs ARE used in class zero, but ONLY to refuse incoming CRs. This is done so you can pass the disconnect code, I think. The procedure in ISO 8073-1986 (I think this has the same numbering as X.224) is in chapter 6.6 (connection refusal), not 6.7 (normal release). So my question, rephrased, is: After completing the refusal procedure in 6.6.3, when, if ever, should the responder disconnect the network connection? Harald Tveit Alvestrand ISO hacker
tozz@hpindda.HP.COM (Bob Tausworthe) (08/08/90)
> / hpindda:comp.protocols.iso / harald.alvestrand@elab-runit.sintef.no / 12:32 am Aug 7, 1990 / > In article <1990Aug6.235903.23530@mel.dit.csiro.au>, > ajw@mel.dit.csiro.au (Andrew Waugh) writes: > > > Class 0 Transport only uses the implicit variant of normal release > > (see 6.7.1). > > Sorry, but no. This bit me too, once. > DRs ARE used in class zero, but ONLY to refuse incoming CRs. > This is done so you can pass the disconnect code, I think. > The procedure in ISO 8073-1986 (I think this has the same numbering as > X.224) is > in chapter 6.6 (connection refusal), not 6.7 (normal release). > > So my question, rephrased, is: > After completing the refusal procedure in 6.6.3, when, if ever, should > the responder > disconnect the network connection? > > Harald Tveit Alvestrand > ISO hacker > ---------- When I read the spec, the statement which kept going around in my head was: In TP0, the lifetime of the transport connection is directly correlated with the lifetime of the network connection. I see two possibilities: 1) Send DR then disconnect the network connection. This has one small problem that depending on the X.25 implementation, the NDISind could be received by the other side before the DR (or the DR would never be received). If this isn't a problem on your implementation, then go for it. 2) Send the DR and go into CLOSED. When the other side receives the DR it will disconnect the network connection. So just add the following to your state table: If present state is CLOSED and you receive a NDISind, clean up network connection datastructures, and goto state CLOSED. Something like this is well within the conventions stated in A.1.3 (what to do if a state intersection is blank [like NDISind/CLOSED]) I like (2) better than (1). bob tausworthe ------------------------------------------------------------------------------ These are my own opinions, unfortunately, not my employers.
S.Walton@CS.UCL.AC.UK (Simon Walton) (08/08/90)
The network connection will normally be closed by the initiating entity when it receives the DR-TPDU. Table A-6 says that when in state `waiting for CC' event DR happens one should take action [1], which table A-5 defines as `If the network connection is not used by another transport connection assigned to it, it may be released.' The situation is similar to that if a TP1-3 connection is disconnected normally, the transport entity may keep the network connection for future use, or may close it - the decision is a local matter. I agree that the protocol error for event NDISind in state `closed' is a bit strange. I suspect this is an error. Simon
Isaac@gui.consumers.com (08/09/90)
I think we can look at Note 4 in 6.7.5 for guidance here. Execpt in Class 4, it is suggested that if a transport entity does not receive acknowledgment of a DR TPDU within time TS2, it should either reset or disconnect the network connection, ... Also, according to Note 3 in 6.1.3, It is suggested that only the owner of ... a network connection should release it. Therefore, it is up to the sender of the CR TPDU to disconnect the network connection after receiving the DR TPDU. But if the network connection is not release after TS2 time, the sender of the DR TPDU can release it. I think the transport spec is the way it is because it was written with multiplexing and splitting in mind. These elements of procedure, of course, do not apply in the Class 0 case so you will have to read between the lines sometime. Isaac Chan, Consumers Software Inc. isaac@gui.consumers.com
kc@oz.rci.dk (Knud Christensen) (08/10/90)
harald.alvestrand@elab-runit.sintef.no writes: >In article <1990Aug6.235903.23530@mel.dit.csiro.au>, >ajw@mel.dit.csiro.au (Andrew Waugh) writes: >> Class 0 Transport only uses the implicit variant of normal release >> (see 6.7.1). >Sorry, but no. This bit me too, once. >DRs ARE used in class zero, but ONLY to refuse incoming CRs. >This is done so you can pass the disconnect code, I think. >The procedure in ISO 8073-1986 (I think this has the same numbering as >X.224) is >in chapter 6.6 (connection refusal), not 6.7 (normal release). >So my question, rephrased, is: >After completing the refusal procedure in 6.6.3, when, if ever, should >the responder >disconnect the network connection? > Harald Tveit Alvestrand > ISO hacker If you look at procedure 6.1 "Assignment to network connection" you will find that only the owner "initiator" of a network connection should release it. So when you have sent the DR-TPDU, the transport connection from your point of view is closed. The NDISind arrives it affects a network connection which is no longer used, so no action should be taken. Knud Christensen RC International, Denmark kc@rci.dk Inside every large program is a small program struggling to get out. - Hoare -