SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: iSCSI: keys/parameter dependence



    Robert:
    
    You are, of course, absolutely correct.  There is no mention
    in the current drafts of "order" applied to the processing of keys
    -- there used to be such an "order" requirement, but that went out
    when draft 8 came in, and is now ancient history.
    
    My apologies to the entire list for mistakenly bringing it back.
    
    I do, however, have a question about one small point in what you said:
    
    > If you want to order processing, you would
    > have to send them one at a time without the C bit set.
    
    Is this true?  When the C bit is not set, there appears to be
    no requirement in the standard that the receiver is forced to
    reply to the keys it has received at that time -- it MUST reply
    to every key eventually, but just having the C bit = 0 does
    not seem to require it to reply then -- it could send an empty
    reply PDU, or could offer new keys of its own at that time
    and delay responding to anything until "everything is on the
    table".  Comments/corrections please.
    
    Thanks
    Bob Russell
    
    
    > Picking up on this in the middle of a thread, I
    > find the following reply from Bob Russell
    > interesting:
    >
    > > > It's
    > > > probably irrelevant, since due to the introduction
    > > > of the C-bit, parameters can be accumulated and
    > > > processed one "batch" at a time, without any
    > > > specific order within the "batch" and they will
    > > > quite likely not be processed PDU by PDU.
    > >
    > > I don't see this either.  Nowhere does the newly added text
    > > describing the C-bit say anything about doing away with the
    > > specific order of the key=value pairs within the "batch".
    > > Why should it -- even if you don't process PDU by PDU you still
    > > have to process batch by batch, a batch still has to be scanned
    > > to find key=value pairs, and the natural way to scan is from the
    > > beginning of the batch, since the next key starts after the
    > > delimiter of the previous key in the batch.
    > > This is also a non-issue.
    >
    > Skimming over rev 12, I have not found the word "order"
    > applied in the context of processing a string of
    > key=value pairs.  While they
    > must clearly be parsed linearly, it is perfectly reasonable
    > to process the parsed values in any order, or even in
    > a vendor-specific order than makes sense to a particular
    > target.  That is why key=value pairs are used in the
    > first place, so that one does not have to worry about
    > ordering.  In this context, batching would be normal behavior
    > and out of order processing within a batch would also be
    > normal behavior.  If you want to order processing, you would
    > have to send them one at a time without the C bit set.
    
    
    
    


Home

Last updated: Tue Jun 04 11:18:37 2002
10486 messages in chronological order