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

["Thomas Crowe" <tcrowe@ctsinc.net>]

Team;

Working from the implementation side of the house.  The more error codes the
better, and the more verbosity the better.  With any new technology, error
conditions seem to be the last thing implemented, however in a
troubleshooting scenario the error codes are the most important thing that
we can have.  The team has put together a very robust set of error
conditions and error codes, but there should always be room for more.

____________________________________________

Thomas Crowe
Technical Director, Research and Development
CTS - Atlanta Office
770-664-3900 ext. 45
____________________________________________


-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]
Sent: Wednesday, February 28, 2001 11:13 AM
To: julian_satran@il.ibm.com
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
>
>
>
>
>
<
BEGIN:VCARD
VERSION:2.1
N:Crowe;Thomas
FN:Thomas Crowe
ORG:CTS
TITLE:Technical Director
TEL;WORK;VOICE:(770) 664-3900
TEL;WORK;FAX:(770) 664-3914
ADR;WORK:;;11600 Alpharetta Highway;Roswell;GA;30076;United States of America
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:11600 Alpharetta Highway=0D=0ARoswell, GA 30076=0D=0AUnited States of Americ=
a
EMAIL;PREF;INTERNET:tcrowe@ctsinc.net
REV:20010228T161349Z
END:VCARD