Quick Connect only: Stack does not properly close TCP connections upon receipt of Forward_Close

Quick Connect defines that if the scanner closes a running IO connection via a Forward_Close message
the adapter must additionally close the tcp connection.
This way the scanner does not have uncleaned tcp resources on his side.

If there is only one IO connection running, the Quick Connect functionality runs properly without errors.
This misbehavior shows up only if the scanner establishes more than one connection
(e.g. one exclusive owner and one additional input only connection).

What happens:

1) The scanner opens a tcp connection tcp_1 to the adapter.
2) The scanner opens an encapsulation session ecap_1 to the adapter using tcp_1.
3) The scanner opens an IO connection conn_1 to the adapter using tcp_1 and encap_1.
4) The scanner opens a second IO connection conn_2 (no matter what type it is) using tcp_1 and encap_1.

The connections are running, everything is ok so far.

At some point, the scanner wants to power down the adapter.
This is where the issue starts:

5) The scanner sends an Forward_Close request using tcp_1 (encap_1) to close conn_1.
6) The adapter receives the Forward_Close request, closes connection conn_1 and additionally closes encap_1 and tcp_1,
since these are linked to conn_1. This behavior is defined by the spec and is ok so far.
7) Now the scanner needs to open a new tcp connection tcp_2 and encapsulation session encap_2 in order to be able
to close conn_2 (since tcp_1 and encap_1 have been closed already).
8) Using tcp_2 and encap_2 the scanner sends a second forward_close request to the adapter using tcp_2 and encap_2.
9) The adapter receives the second Forward_Close request, closes connection conn_2 but DOES NOT additionally closes encap_2 and tcp_2
since these are NOT linked to conn_2 (conn_2 was opened using tcp_1 and encap_1, which are already closed).
So all IO connections have been closed. There is only one tcp connection and one encapsulation session open (tcp_2 and encap_2).

At this point the adapter will be powered down. And after a while it will be powered up again.
In order to open the connections to the adapter real quick again (Quick Connect), the scanner knows
the exact time at which the adapter is ready to accept incoming connections again.
So after waiting for that time to run up the scanner now wants to open the connections conn_1 and conn_2 again.
The problem now is, that he tries to use tcp_2 and encap_2, which are still open from the scanners point of view.
but since the adapter was powered down and up, tcp_2 and encap_2 are not open on the adapter side.

So this is what happens then:

10) The scanner sends a Forward_Open to open conn_1 using tcp_2 and encap_2.
11) The adapter rejects this frame since he does not have any open tcp connections.
12) The scanner runs into his internal scan list timeout and closes tcp_2 and encap_2.
13) After some seconds ( time is scanner dependend) the scanner open a new tcp connection and
encapsulation session and all connection can be established again.

The the actual issue is that the scanner runs into that timeout (point 12).
This delays the quick connection buildup!

###################################################################
This behavior can be seen in the attached WireShark trace:

Both connections conn_1 and conn_2 are running at the beginning of the capture.

Frame #

5545: The scanner closes connection conn_1 (point 5 above)
5546: Adapter acknowledges
5547: Adapter closes encap_1 (internally) and tcp_1. (point 6)
5556-5560: Scanner establishes tcp_2 and encp_2 (point 7)
5561: Scanner closes conn_2 (point 8)
The adapter does not close tcp_2 at this point!

Adapter is powered down and powered up.

5650: The adapter starts up again.
5654: The scanner tries to open conn_1 using tcp_2 and encap_2 (point 10).
5657: Adapter rejects Forward_Open (point 11).
5731- 5749: After about 3 seconds the scanner starts establishing both IO connections successfully (point 13).