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.