Is unique StreamId required when consumer and provider want to communicate with each other with mess
I am using UPA libs for FeedSim. Facing issues while communicating RSSL_MC_UPDATE message to subscribed clients. I checked sample applications and started debugging rsslVAProvider and rsslWatchlistConsumer applications to understand messages/ communications sent to and fro e.g. RSSL_MC_UPDATE/ RSSL_MC_STATUS. I have observed that when rsslWatchlistConsumer creates the Stream Id and sends it to rsslVAProvder, rsslVAProvider receives that information through a call-back function. Then Stream Id is fetched from StreamInfo. However this StreamId is greater than 1 what rsslWatchlistConsumer has sent to server. e.g. if rsslWatchlistConsumer sends Stream Id as 5, in rsslVAProvider its being received as 6. Is this a standard or expected behaviour?
rsslVAProvider and rsslWatchlistConsumer are the standard applications I was refering from Examples.
I would also like to understand why this happens and will I be able to use custom feed application with rsslWatchlistConsumer.
Best Answer
-
Stream IDs are used to represent multiple data streams within a connection, and each ID must be unique to that stream. For example, if a consumer opens a login stream, a directory stream, a stream requesting item TRI.N, and a stream requesting item GOOG.O, each of those four streams must use a Stream ID different from the other three (the Login could use ID 1, Directory 2, TRI.N 3, and GOOG.O 4). The UPA Dev Guide has more information; see the "Stream Identification" section.
The rsslWatchlistConsumer leverages the Consumer Watchlist Value-Add component which provides message routing, fanout, and recovery features for the application. To do this it creates and manages its own streams, which aren’t necessarily 1-to-1 with application streams, which it why it remaps stream IDs it sends to the provider. If you connect unmodified rsslWatchlistConsumer and rsslVAProvider examples directly, you should see that the rsslWatchlistConsumer receives the requested content with the Stream ID it used even if the ID reported by rsslVAProvider is different. Examples that do not use the Watchlist component (e.g. rsslConsumer, rsslVAConsumer) write messages directly to the connection and so will not see their IDs modified.
0
Categories
- All Categories
- 6 AHS
- 37 Alpha
- 161 App Studio
- 4 Block Chain
- 4 Bot Platform
- 16 Connected Risk APIs
- 47 Data Fusion
- 30 Data Model Discovery
- 608 Datastream
- 1.3K DSS
- 577 Eikon COM
- 4.9K Eikon Data APIs
- 7 Electronic Trading
- Generic FIX
- 7 Local Bank Node API
- Trading API
- 2.7K Elektron
- 1.3K EMA
- 236 ETA
- 519 WebSocket API
- 33 FX Venues
- 10 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 20 Messenger Bot
- 2 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 59 Open Calais
- 264 Open PermID
- 39 Entity Search
- 2 Org ID
- PAM
- PAM - Logging
- 8.4K Private Comments
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 20 RDMS
- 1.4K Refinitiv Data Platform
- 367 Refinitiv Data Platform Libraries
- 3 Refinitiv Due Diligence
- LSEG Due Diligence Portal API
- 3 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.1K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 10 World-Check Customer Risk Screener
- 990 World-Check One
- 44 World-Check One Zero Footprint
- 45 Side by Side Integration API
- Test Space
- 3 Thomson One Smart
- 1.2K TR Internal
- Global Hackathon 2015
- 2 Specialists Who Code
- 10 TR Knowledge Graph
- 150 Transactions
- 142 REDI API
- 1.7K TREP APIs
- 4 CAT
- 21 DACS Station
- 117 Open DACS
- 1.1K RFA
- 103 UPA
- 172 TREP Infrastructure
- 224 TRKD
- 886 TRTH
- 5 Velocity Analytics
- 5 Wealth Management Web Services
- 59 Workspace SDK
- 9 Element Framework
- 5 Grid
- 13 World-Check Data File
- Yield Book Analytics
- 46 中文论坛