I have couple issues with the subject:
1) Setting nakMount to RSSL_TRUE should force rsslAccept return NULL, according to rsslTransport.h:822: “If a clients connect message is not accepted, a negative acknowledgment is sent to the client and no RsslChannel is returned.” But it is never NULL, one must invoke rsslInitChannel with nak-ed channel, it’ll return -1 and “Error: 1006 Connection refused” error object. Why rsslAccept returns valid RsslChannel in nak-case?
2) Also, in DOS-mode, when consumer in no-wait loop initiates connection and provider rejects it immediately with nak-rsslAccept-rsslInitChannel sequence, at some point (try #9717 in my case) I get: “ERROR - Error RSSL_RET_FAILURE (-1) (errno: 9) encountered with rsslInitChannel. Return code: -1. Error text: <Impl/ripcsrvr.c:3830> Error: 1002 Could not set EL_LINGER on socket. System errno: (9)”. Than almost immediately: “unknown location(0): fatal error in "Run": memory access violation at address: 0x00000018: no mapping at fault address”, and provider crashes.
1) It sounds like the comment in the rsslTransport.h header file is incorrect. The developers guide does indicate the correct use and behavior.
To explain why you need to go through the rsslInitChannel calls to complete this, it is mainly because rsslAccept is only completing the underlying transport handshake, but not progressing the RSSL connection handshake that needs to happen. The RSSL connection handshake is where things like compression, ping timeouts, and protocol versioning are negotiated. This is also where we have the ability to NAK a client connection. As a result, you would have to tell rsslAccept that you want to NAK the connection so the correct settings are enabled inside of the RsslChannel that is returned; the rsslInitChannel handshake then receives the clients RSSL connection request and will respond with a NAK. If we do not send a NAK with our information in it, the client cannot distinguish between a lost connection and an intentionally NAK’d connection.
2) I am not certain what you mean by DOS Mode.
For the first question.
1) The "no RsslChannel returned" only apply to blocking I/O connection. For non-blocking connections to successfully complete rejection, the channel initialization process must still be completed. This is stated in the Developer Guide. The comments of rsslAccept in rsslTransport.h has already been changed to reflect this too.