Re: iSCSI: large keys during login?

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

The mechanism is uniform. Spanning and multiresponse PDUs are different issues though. Julo Spanning is not happening often at login (not many keys extend above 8k).
TTT is now the mechanism for target having more key=value for a single key=value query. Spanning is far simpler> We could colapse them and use TTT for both and if there is a bit needed it can't be F as F is the end of a sequence not a single negotiation. I think however that the simple string delimiter search that we have now is sufficient and the two mechanisms are sufficiently different to be kept separate.

Julo

Santosh Rao <santoshr@cup.hp.com> Sent by: owner-ips@ece.cmu.edu 05/01/2002 08:46 PM Please respond to Santosh Rao

To:        ips@ece.cmu.edu         cc:                 Subject:        Re: iSCSI: large keys during login?

Bill Studenmund wrote:
> 
> On Wed, 1 May 2002, Julian Satran wrote:
> 
> > I pointed to that earlier. TTT are needed only for multiple answers to one
> > query (like SendTargets).
> > Spanning responses  over several PDUs can be handled in different ways.
> > Here is a simple example:
> >
> > I->T Key=a
> > T-> Key=bbbbb (and does not end here i.e., no null in the PDU)

                                            ^^^^^^^^^^^^^^^^^^^^^^^^^
Hello,

I don't know how the above would work. Every string (in this case, the
key=value string) is assumed to be NULL terminated. If this is not the
case, the usage of standard string routines like strlen(), strcpy(),
strstr(), etc will have problems in the iscsi login/text parsers.

I think the multi-pdu fragmentation and re-assembly mechanisms must be
uniform across both the login and text pdu's allowing the same code to
be re-used in both the login and text parsers.

Hence, it would be better to have the TTT and F bit in the login pdu.
The receiving side must not interpret any received keys, but simply
store them, send an empty login/login_rsp pdu back with the TTT set and
eventually perform re-assembly until the sending side sends a pdu with
the F bit set. When the 'F' bit PDU is received, the keys may be
interpreted, negotiations performed, and if necessary, another
login/login_rsp pdu be sent indicating the appropriate (CSG, NSG, T)
setting.

Regards,
Santosh


-- 
We have enough people who tell it like it is
Now we could use a few who tell it like it can be.

-  Robert Orben