Re: iSCSI: large keys during login?

[Bill Studenmund <wrstuden@wasabisystems.com>]

On Wed, 1 May 2002, Santosh Rao wrote:

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

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.

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

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

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

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