RE: iSCSI - Change - Login/Text commands with the binary stage co de

["Julian Satran" <Julian_Satran@il.ibm.com>]

Stephen,

That can happen as the target may set-up completely new TCP connections
(the old sockets are still there and look OK).
Untill the login is  progessing he assumes that this is just another
open-session attempt. Then he checks the old session and the session is
dead (initiator has closed the connections).

The target has to distinguish only between a session that is alive (and
reject the new one) and one that its dead in which case it can clean-up.

Julo

"Wheat, Stephen R" <stephen.r.wheat@intel.com> on 23-08-2001 22:50:56

Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>

To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI - Change - Login/Text commands with the binary stage co
          de



Julian,

I don't understand your answer.  For the scenario given, I would presume
then that the target would reject the new session attempt, as it sees the
previous session still "alive".  What is there to tell the target that this
is any different from when the Initiator is erroneously using the
repetitive
session id?

Thanks,
Stephen

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, August 23, 2001 11:15 AM
To: ips@ece.cmu.edu
Subject: Re: iSCSI - Change - Login/Text commands with the binary stage
co de


Stephen,

1.If the initiator goes away for a while and reboots and there was no
activity on the connections
the target may see a session alive (I am not sure that it has to appear on
the state diagram but maybe).

2.Again - I am not sure that the curent state diagram includes death of the
initiator

Julo

"Wheat, Stephen R" <stephen.r.wheat@intel.com>@ece.cmu.edu on 23-08-2001
19:58:34

Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  Re: iSCSI - Change - Login/Text commands with the binary stage co
      de



Julian,

1.3.6 ISID states that the target should check to see if the old session is
still active when a duplicate session is detected.

I have two questions, the second only if you answer in the affirmative on
the first ;^)

1. Is there a properly executed sequence of events (i.e., no coding error
on
the target side) where the session is not active, but the target hadn't
taken notice of it?  It appears this as a protocol-specified means to work
around a flaw in a target's implementation.  I interpret the state diagram
transitions as being atomic wrt other commands.  I.e., the last logout
would
result in the various transitions of the connection/session prior to the
initiator starting the session up again.  And the target would have
completed the transitions prior to handling a new session request.

2. If you answered (1) in the affirmative, then the word "Active" is not
consistent with the 6.3 Session State Diagram.  Does this mean the target
got lost, due to transport failures of any sort, in its transition from
Q3-to-Q2-to-Q1?  It sounds like the intent is to close the old session if
the session was in Q2 or Q4, presuming if it were in Q1,  it would not have
been found as a duplicate.

Stephen