[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: configurable keepalive setting through libldap?

Anton Bobrov wrote:

i always thought that having a separate, specific NOOP operation would
be helpful in such cases [not to be mixed up with NOOP control] because
similar kinda problems tend to surface in various scenarios and while
there are workarounds, they are well, workarounds. some deployments out
there might want to have such operation disabled since it can be abused
by clients, in which case it can have a response defined and servers
can send unwilling to perform or something similar if that is the case.

Yes, given the spotty nature of network connectivity it probably should have been part of the original spec. (Then again, prople probably weren't thinking about long-lived sessions or persistent search back then...) But at this point it's too late; adding a new NoOp request probably isn't going to get sufficient adoption/deployment to actually be useful to any clients.

For the purpose of detecting a failed TCP connection, Abandon ought to be sufficient. No LDAP-level reply is needed since TCP will ACK the message. As an alternative you could send a Search request (as noted in ITS#5133) against the rootDSE, if you wanted to also measure the latency. The advantage of using Abandon is that it could easily be hidden from any applications by doing it invisibly in the library. For any other request with a reply, you'd also have to intercept / discard the result. (Though you could always send the request immediately followed by its own Abandon, I suppose.)

Hallvard B Furuseth wrote:
Ralf Haferkamp writes:
Btw, you mentioned that sending Abandon 0 will be sufficient as a no-op. How's
that going to work?

It's a no-op, thus it can be sent when you just want to send some message:

* The Abandon request has no reponse.
* rfc4511 §4.11: "Servers MUST discard Abandon requests for messageIDs
   they do not recognize, for operations that cannot be abandoned, (...)
* No request may have Message ID 0 (§; 0 is reserved for
   Unsolicited Notifications.  Yet Message IDs are just defined as
   0..2^^31-1, so abandon(0) is not a protocolError.
Thus abandon(0) is a no-op.

I can imagine some implementation treating it as protocolError anyway
though.  It's not as if everyone agrees what the letter of the standard
means, and follow it to the letter.

  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/