|
|
| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] |
|
I believe Ken explains it well though you
need to have a good understanding of exactly when the state transitions take
place. The actual session reinstatement should not take place until
precisely the moment that the new session reaches full feature phase. At
that point, the original (now reinstated session) should reach Carlos Carlos Rimola From: Sandars, Ken
[mailto:ken_sandars@xxxxxxxxxxx] Hi Paul, Section 5.3.5 [RFC3720] para 2 states:
In your scenario the initiator violates
this rule since both are in state FREE (Q1). The part of your question explores what
happens at the target if this scenario does occur. The connection and session state machines
for the target show that the session begins life in the ACTIVE state (Q2) when
the login phase of the leading connection starts (S4). Once the leading
connection transits (T5) to LOGGED_IN (S5), the session performs the equivalent
transit (N2) to LOGGED_IN(Q3). In your scenario, there are two new
sessions in ACTIVE state, racing towards LOGGED_IN. A sensible target
implementation waits until a connection makes the T5 transition (corresponding
to the session's N2 transition) before enacting the session reinstatement
action. Afterall, it would be a shame to nuke a potentially viable session with
a dodgy login attempt. Some sort of implementation-specific
mutual exclusion mechanism must be used on the target to ensure only one party
manipulates the session state. Hence one connection reaches the T5 transition
point and runs the session reinstatement algorithm. At this point the other session is in Q2
and its connection is in S4 (albeit on the cusp of its transition). While not
listed as a T7 reason, I'd think a resilient target would take that action on
the connection. The session would make the N9 transition (again, not explicitly
listed as a reason, but follows as a consequence of the T7 transit). In other words, the first one to reach
full feature phase survives and the other gets trashed. Sound fair? Cheers Ken From: Paul
Hughes [mailto:phughes@xxxxxxxxxxxxxx] Is
there any text in RFC 3720 or the implementer's guide that prevents an
initiator from simultaneously logging-in on two connections to the same target
portal using the same InitiatorName, ISID, and TSIH=0? If the logins were
done sequentially, the second login would re-instate the session created by the
first login, but I can see how a target might not do session re-instatement if
the sessions are being created simultaneously. Thanks,
|
_______________________________________________ Ips mailing list Ips@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ips
|
|