Is unique StreamId required when consumer and provider want to communicate with each other with m...

Susan Genoray

...essage updates

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.

Bondy_Bo

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.