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 (§4.1.1.1); 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/