Imported from previous forum
An apparently insoluble Logout incident concerning simultaneous triggering of Logouts:
A: Session end-time notified, issue TestRequest
B: Receive TestRequest, issue Heartbeat
B: Session end-time notified, issue TestRequest
A: Receive Heartbeat
A: Issue Logout
B: Receive TestRequest
B: Receive Logout, issue Logout response
A: Receive Logout, close connection
A: TestRequest left pending
The issue is that B’s TestRequest goes unresponded at the point of closure so A thinks the session improperly closed whereas B thinks it’s clean.
PROBLEM: generally speaking if A’s Logout were issued before any new message is received from B there’s apparently no way to stop logout processing therefore there’s no way to avoid asymmetric closure if the new message requires a protocol-level response. Right or wrong?
CURE (workaround?): allow a TestRequest to inform the recipient that a logout is in train: a new field perhaps? If this applied, B in this case would know not to send any new messages, ie. no TestRequest, so the problem wouldn’t arise.
Also, in considering this scenario we looked closely at the Logout message itself. Consider the case of perfectly interleaved logout attempts where two logouts are on the wire at precisely the same time. Both sides will see the other’s Logout as a response, not a Logout initiation. This could have ramifications if there were intervening new message traffic as above.
Would the following be a useful addition to the Logout message: add field 112 and use it as with TestRequest/Heartbeat (this would avoid premature closure as each side could identify the response to its own Logout, excepting pathological conditions such as both using the same text in 112!) – or better, have a new field in Logout which identifies the messages as Initiator or Response.
Cheers
Keith
[ original email was from John Cameron - jc@cameronsystems.com ]
Hello Keith,
In practice I think that the solution to the problem you describe is that one party needs to be nominated as being responsible for initiating the scheduled logout.
The problem you outline is caused because both parties are simultaneously trying to initiate the logout.
This is similar to Logon. With logons only one party is the initiator. The other party just responds passively.
Another analogy is the creation of a socket connection. There one party is passively listening while the other party actually initiates the connection.
John
> An apparently insoluble Logout incident concerning simultaneous triggering of Logouts:
>
> A: Session end-time notified, issue TestRequest
> B: Receive TestRequest, issue Heartbeat
> B: Session end-time notified, issue TestRequest
> A: Receive Heartbeat
> A: Issue Logout
> B: Receive TestRequest
> B: Receive Logout, issue Logout response
> A: Receive Logout, close connection
> A: TestRequest left pending
>
> The issue is that B’s TestRequest goes unresponded at the point of closure so A thinks the session improperly closed whereas B thinks it’s clean.
>
> PROBLEM: generally speaking if A’s Logout were issued before any new message is received from B there’s apparently no way to stop logout processing therefore there’s no way to avoid asymmetric closure if the new message requires a protocol-level response. Right or wrong?
>
> CURE (workaround?): allow a TestRequest to inform the recipient that a logout is in train: a new field perhaps? If this applied, B in this case would know not to send any new messages, ie. no TestRequest, so the problem wouldn’t arise.
>
>
> Also, in considering this scenario we looked closely at the Logout message itself. Consider the case of perfectly interleaved logout attempts where two logouts are on the wire at precisely the same time. Both sides will see the other’s Logout as a response, not a Logout initiation. This could have ramifications if there were intervening new message traffic as above.
>
> Would the following be a useful addition to the Logout message: add field 112 and use it as with TestRequest/Heartbeat (this would avoid premature closure as each side could identify the response to its own Logout, excepting pathological conditions such as both using the same text in 112!) – or better, have a new field in Logout which identifies the messages as Initiator or Response.
>
> Cheers
>
> Keith
>
John,
I agree with you in the case of Logon since there is a defined role for each party. Indeed it’s difficult to see it happening any other way; the acceptor of a Logon being the equivalent of a socket listener. With Logout it’s different in that there could be legitimate reasons for either party to close.
In the scenario I presented, the acceptor of the original logon is a gateway, the intitiator is a gateway client (but I suspect you’d already realised that, John!). You could argue that the Logon initiator should also be responsible for logout however in reality the gateway has fixed operating hours therefore it will also need to logout connected clients at shutdown-time.
You could then argue that the client should be passive in regard to logout but to my mind that’s avoiding the issue: there will always be this hole in the protocol because either side has the absolute right to initiate a logout and there’s currently no way to prevent simultaneity.
Therefore I believe there is a problem with Logout sequencing – and this is a real-life problem: it happened. I’m not altogether sure whether signalling to prevent synchronous Logout attempts is sufficient, there may be a need for deadlock prevention too. I do think encoding a textual response in the response Logout is entirely appropriate – field 112? – since, tautologically, the response is a response and will certainly enable either party to determine whether a Logout is an initiating or response message.
Best …
Keith
> Hello Keith,
>
> In practice I think that the solution to the problem you describe is that one party needs to be nominated as being responsible for initiating the scheduled logout.
>
> The problem you outline is caused because both parties are simultaneously trying to initiate the logout.
>
> This is similar to Logon. With logons only one party is the initiator. The other party just responds passively.
>
> Another analogy is the creation of a socket connection. There one party is passively listening while the other party actually initiates the connection.
>
> John
>
>
> > An apparently insoluble Logout incident concerning simultaneous triggering of Logouts:
> >
> > A: Session end-time notified, issue TestRequest
> > B: Receive TestRequest, issue Heartbeat
> > B: Session end-time notified, issue TestRequest
> > A: Receive Heartbeat
> > A: Issue Logout
> > B: Receive TestRequest
> > B: Receive Logout, issue Logout response
> > A: Receive Logout, close connection
> > A: TestRequest left pending
> >
> > The issue is that B’s TestRequest goes unresponded at the point of closure so A thinks the session improperly closed whereas B thinks it’s clean.
> >
> > PROBLEM: generally speaking if A’s Logout were issued before any new message is received from B there’s apparently no way to stop logout processing therefore there’s no way to avoid asymmetric closure if the new message requires a protocol-level response. Right or wrong?
> >
> > CURE (workaround?): allow a TestRequest to inform the recipient that a logout is in train: a new field perhaps? If this applied, B in this case would know not to send any new messages, ie. no TestRequest, so the problem wouldn’t arise.
> >
> >
> > Also, in considering this scenario we looked closely at the Logout message itself. Consider the case of perfectly interleaved logout attempts where two logouts are on the wire at precisely the same time. Both sides will see the other’s Logout as a response, not a Logout initiation. This could have ramifications if there were intervening new message traffic as above.
> >
> > Would the following be a useful addition to the Logout message: add field 112 and use it as with TestRequest/Heartbeat (this would avoid premature closure as each side could identify the response to its own Logout, excepting pathological conditions such as both using the same text in 112!) – or better, have a new field in Logout which identifies the messages as Initiator or Response.
> >
> > Cheers
> >
> > Keith
> >
>
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
I think there’s a mistake in the parties listed here. Let me restate this according to what I think is happening:
A: Session end-time notified, issue TestRequest
B: Receive TestRequest, issue Heartbeat
B: Session end-time notified, issue TestRequest
A: Receive Heartbeat
A: Issue Logout
A: Receive TestRequest
B: Receive Logout, issue Logout response
A: Receive Logout, close connection
B: TestRequest left pending
> The issue is that B’s TestRequest goes unresponded at the point of closure so A thinks the session improperly closed whereas B thinks it’s clean.
That isn’t necessarily the case. A issues a Logout and receives a Test Request. Some session-level messages can be processed even if a logout is pending. For instance, the spec specifically seems to require processing of a Resend Request even if a Logout is pending. I would think that a Test Request would fall under the same category. If A responded to the Test Request, the situation would appear as follows:
A: Session end-time notified, issue TestRequest
B: Receive TestRequest, issue Heartbeat
B: Session end-time notified, issue TestRequest
A: Receive Heartbeat
A: Issue Logout
A: Receive TestRequest, issue Heartbeat
B: Receive Logout, issue Logout response
B: Receive Heartbeat
A: Receive Logout, close connection
A and B: Both have their TestRequest’s acknowledged
> PROBLEM: generally speaking if A’s Logout were issued before any new message is received from B there’s apparently no way to stop logout processing therefore there’s no way to avoid asymmetric closure if the new message requires a protocol-level response. Right or wrong?
I don’t necessarily know if the protocol requires one to stop processing business messages immediately while the Logout is pending. I think doing so can get around this problem.
> Also, in considering this scenario we looked closely at the Logout message itself. Consider the case of perfectly interleaved logout attempts where two logouts are on the wire at precisely the same time. Both sides will see the other’s Logout as a response, not a Logout initiation. This could have ramifications if there were intervening new message traffic as above.
This scenario is very unlikely, and is genarlly avoidable. You’ve stated that both sides can initiate a Logout, which is most certainly true. But in standard practice, a Logout is issued either:
A. At a pre-determined time, or
B. If manual intervention requires shutting down the connection.
For the A case, one simply must make sure both sides are not configured to drop the connection at exactly the same time. Either one side does it, or the times can be staggered. Also, this is generally configured to be outside normal business hours, so there shouldn’t be any business messages on the wire.
For the B case, the likelihood of it happening at the same time is slim.