SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: max connections exceeded (was yet another login question)



    
    
    Mark,
    
    Keep in mind though that you have to strike a balance between being
    friendly to
    a new implementation (initiator and target) to wasting to many resources
    for what will be used only during debugging.
    Protocol errors could be detected if you ran initiator/target again a
    friendly partner (with detailed error logs).
    You don't want to burden running things with all the clutter.
    
    Regards,
    Julo
    
    Mark Burton <markb@ordern.com> on 28/02/2001 18:12:39
    
    Please respond to Mark Burton <markb@ordern.com>
    
    To:   Julian Satran/Haifa/IBM@IBMIL
    cc:   ips@ece.cmu.edu
    Subject:  max connections exceeded (was yet another login question)
    
    
    
    
    
    Julo,
    
    In general, I would prefer to have reasonably specific error codes
    rather than "catch alls". What do other people think?
    
    In this particular case it is arguable that the initiator is in error
    rather than the target because the maximum number of connections per
    session has been previously negotiated and, therefore, the initiator
    should not try and open a new connection.
    
    I therefore suggest: 0207 'No Free Connections' (or similar)
    
    Other login error situations not particularly well matched to the
    existing codes are:
    
    1 - Connection duplicates a CID value already used in the session - I
        suggest: (0208 'Initiator CID Error')
    
    2 - A mandatory parameter has not been specified but the F bit is
        set in a Login PDU. A helpful thing for the target to do in this
        situation would be to return the key(s) of the missing mandatory
        parameters in the data segment. This could be made an optional
        capability. I suggest: (0209 'Mandatory parameter missing')
    
    3 - A value is specified for a session parameter that conflicts with a
        previously negotiated value (negotiated by the leading
        connection).  A Reject response could be used in this situation
        (preferably with a new reject reason code).
    
    One other question is: how should a target respond if it receives a
    Login command on a connection that has already reach full feature
    phase? Rejecting the command seems obvious but with what code?
    
    Regards,
    
    Mark
    
    From: julian_satran@il.ibm.com
    Subject: Re: yet another login question
    Date: Wed, 28 Feb 2001 14:53:37 +0200
    
    >
    >
    > Mark - you don't have to apologize.
    >
    > The 0300 (2.11.4) response is supposed to cover this type of error.
    >
    > If you and others feel that we have to be more specific - speak out
    loudly.
    >
    > Regards,
    > Julo
    >
    >
    > Mark Burton <markb@ordern.com> on 27/02/2001 22:43:39
    >
    > Please respond to Mark Burton <markb@ordern.com>
    >
    > To:   ips@ece.cmu.edu
    > cc:
    > Subject:  yet another login question
    >
    >
    >
    >
    >
    > Hello again,
    >
    > sorry to be a pest but I have another query re the login command:
    >
    > If an initiator opens a new connection and subsequently submits a
    > login pdu that identifies an existing session that is already
    > supporting the maximum number of connections, what error code should
    > be returned to the initiator? Perhaps "target conflict", or maybe a
    > new code yet to be defined like "No free connections".
    >
    > Apologies if this is covered in the spec but I have missed it.
    >
    > Thanks,
    >
    > Mark
    >
    >
    >
    >
    >
    <
    
    
    
    


Home

Last updated: Tue Sep 04 01:05:29 2001
6315 messages in chronological order