RsslAcceptOptions::nakMount issues

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.
Best Answer
-
Answers:
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.0
Answers
-
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.0
Categories
- All Categories
- 3 Polls
- 6 AHS
- 36 Alpha
- 166 App Studio
- 6 Block Chain
- 4 Bot Platform
- 18 Connected Risk APIs
- 47 Data Fusion
- 34 Data Model Discovery
- 685 Datastream
- 1.4K DSS
- 615 Eikon COM
- 5.2K Eikon Data APIs
- 10 Electronic Trading
- Generic FIX
- 7 Local Bank Node API
- 3 Trading API
- 2.9K Elektron
- 1.4K EMA
- 252 ETA
- 556 WebSocket API
- 38 FX Venues
- 14 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 23 Messenger Bot
- 3 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 60 Open Calais
- 275 Open PermID
- 44 Entity Search
- 2 Org ID
- 1 PAM
- PAM - Logging
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 22 RDMS
- 1.9K Refinitiv Data Platform
- 652 Refinitiv Data Platform Libraries
- 4 LSEG Due Diligence
- LSEG Due Diligence Portal API
- 4 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.2K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 12 World-Check Customer Risk Screener
- 1K World-Check One
- 46 World-Check One Zero Footprint
- 45 Side by Side Integration API
- 2 Test Space
- 3 Thomson One Smart
- 10 TR Knowledge Graph
- 151 Transactions
- 143 REDI API
- 1.8K TREP APIs
- 4 CAT
- 27 DACS Station
- 121 Open DACS
- 1.1K RFA
- 104 UPA
- 193 TREP Infrastructure
- 228 TRKD
- 917 TRTH
- 5 Velocity Analytics
- 9 Wealth Management Web Services
- 90 Workspace SDK
- 11 Element Framework
- 5 Grid
- 18 World-Check Data File
- 1 Yield Book Analytics
- 46 中文论坛