directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu (JIRA)" <>
Subject [jira] Commented: (DIREVE-323) Extended operation for Notice of DIsconnect (Unsolicited Notification)
Date Wed, 18 Jan 2006 03:48:06 GMT
    [ ] 

Alex Karasulu commented on DIREVE-323:

I have no idea how I'm going to properly test this functionality.  I might just write a simple
extended operation that returns immediately but sends a notice of disconnect to the client
before shuting down the cients session in some number of milliseconds.  This is a real PITA
so I'll just wait until DIRMINA-166 is complete to follow up on this.

> Extended operation for Notice of DIsconnect (Unsolicited Notification)
> ----------------------------------------------------------------------
>          Key: DIREVE-323
>          URL:
>      Project: Directory Server
>         Type: New Feature
>     Versions: 0.9.3
>     Reporter: Alex Karasulu
>     Assignee: Alex Karasulu
>      Fix For: 0.9.4

> From RFC 2251 here
> Section 4.1.1 (Small snippent on sending NoD)
>    If the server receives a PDU from the client in which the LDAPMessage
>    SEQUENCE tag cannot be recognized, the messageID cannot be parsed,
>    the tag of the protocolOp is not recognized as a request, or the
>    encoding structures or lengths of data fields are found to be
>    incorrect, then the server MUST return the notice of disconnection
>    described in section 4.4.1, with resultCode protocolError, and
>    immediately close the connection. In other cases that the server
>    cannot parse the request received by the client, the server MUST
>    return an appropriate response to the request, with the resultCode
>    set to protocolError.
> 4.4.1. Notice of Disconnection
>    This notification may be used by the server to advise the client that
>    the server is about to close the connection due to an error
>    condition.  Note that this notification is NOT a response to an
>    unbind requested by the client: the server MUST follow the procedures
>    of section 4.3. This notification is intended to assist clients in
>    distinguishing between an error condition and a transient network
>    failure.  As with a connection close due to network failure, the
>    client MUST NOT assume that any outstanding requests which modified
>    the directory have succeeded or failed.
>    The responseName is, the response field is
>    absent, and the resultCode is used to indicate the reason for the
>    disconnection.
>    The following resultCode values are to be used in this notification:
>    - protocolError: The server has received data from the client in
>    which
>      the LDAPMessage structure could not be parsed.
>    - strongAuthRequired: The server has detected that an established
>      underlying security association protecting communication between
>      the client and server has unexpectedly failed or been compromised.
>    - unavailable: This server will stop accepting new connections and
>      operations on all existing connections, and be unavailable for an
>      extended period of time.  The client may make use of an alternative
>      server.
>    After sending this notice, the server MUST close the connection.
>    After receiving this notice, the client MUST NOT transmit any further
>    on the connection, and may abruptly close the connection.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message