Subject: Re: iSCSI: large keys during login?

From: "Julian Satran" <[email-masked]>
Date: Wed, 1 May 2002 19:39:20 +0300

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)

I->T      (empty or something else)
T->I bbbb(0) .... (something else)

Julo

Bill Studenmund <[email-masked]>
05/01/2002 07:14 PM
Please respond to Bill Studenmund

        To:     Julian Satran/Haifa/IBM@IBMIL
        cc:     andy currid <[email-masked]>, <[email-masked]>, 
<[email-masked]>, "THALER,PAT (A-Roseville,ex1)" 
<[email-masked]>
        Subject:        Re: iSCSI: large keys during login?

On Wed, 1 May 2002, Julian Satran wrote:

> Andy,
>
> The data part is the same on both text and login.
> I will make o note to say this again in chapter 9.

Julian, I think the grit of Andy's question still stands. At least I'm now
puzzled by a question he raised. :-)

I agree that the section you quote, 9.12.10, describes what keys can be
used when & refers to the correct chapters.

I think Andy's question, or the question I now have, is how do we do the
equivalent of the multi-part exchange shown in section 9.10.3 (towards the
bottom of page 156) with Login PDU's? We don't have a Target Transfer Tag
field?

Do we need to add one?

Take care,

Bill

---

From: Bill Studenmund <[email-masked]>
Date: Wed, 1 May 2002 09:53:57 -0700 (PDT)

> T-> Key=bbbbb (and does not end here i.e., no null in the PDU)
                                       ^^^^^^^^^^^^^^^^^^^^^^^^
That's the part that was missing! Thanks. Could we please clarify this in
the text?

> T->I bbbb(0) .... (something else)

Could we have an example of this please?

Also, I'd like to suggest that the I->T PDU be empty, or at least not
include new negotiations. For one side to be able to inject new
negotiations while the other is trying to send its last negotiated set
will make negotiation handling complicated.

Take care,

Bill

---

From: Santosh Rao <[email-masked]>
Date: Wed, 01 May 2002 10:46:16 -0700

> > 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

---

From: Bill Studenmund <[email-masked]>
Date: Wed, 1 May 2002 13:05:04 -0700 (PDT)

> strstr(), etc will have problems in the iscsi login/text parsers.

Before you start processing key/value pairs, you look to see if the last
byte in the PDU is NUL (note, NUL, not NULL). If it is not, then there's
more text comming. You save what you have, ack what you got, and wait for
more. When you get more, you append it in the buffer, and then check to
see if this blob was terminated by a NUL. If not, you have yet more to do,
so loop. If you get more than you can accept, bail.

When you get the last bit (NUL terminated), you then parse.

> be re-used in both the login and text parsers.

I agree it would be nice to have the same mechanisms, but I think we can
live without. We can do either. :-)

> login/login_rsp pdu be sent indicating the appropriate (CSG, NSG, T)

Why do we need BOTH the TTT field and the F bit? One or the other would
suffice, and I'd vote we use TTT (we already have something at the F bit
position).

Take care,

Bill