adam.connelly
Hi,
This is a question about the way that the DataAdapter, etc works. I've implemented a DataAdapter and a IExtendedTableListener. In the DataAdapter I create a hashtable to store the update information. Not all of the update information changes every time.
Would it be fair to say that lightstreamer does not include items in the dictionary that have not changed since the last update? If so, is there any way to force it to always send all data passed to IItemEventListener.Update() regardless of if it has changed or not?
Cheers,
Adam
adam.connelly
I've done a bit more investigation, and found out a bit more about how everything's meant to work. From what I can see, a client can request the mode that they are subscribing to something when creating an ExtendedTableInfo object to pass to SubscribeTable.
I've tried setting the mode to ExtendedTableInfo.RAW, but this doesn't appear to work properly. I still have missing items being passed to the OnUpdate method (for items that haven't changed).
I'm not particularly concerned about bandwidth, so I would like to be able to force the server to send the whole update every time.
Am I correct in my understanding? Thanks for any replies.
Adam
Dario Crivelli
You are correct, but, from our perspective, we say it in a different way.
The Server-Client communication protocol, in order to save bandwidth, forces unchanged fields not to be sent, but to be replaced by flags that identify unchanged fields.
We consider this as a not configurable implementation detail, as the client receives enough information to be able to retrieve the unchanged values from previous updates.
However, some of our client libraries lack support for this task and just forward the "unchanged" notification to application code, rather than resolve unchanged fields under the hood.
This is what I expect that happens in your case. Note that the "unchanged" notification is expressed differently depending on the kind of listener you are using.
Fortunately, this limitation is going to be removed with the forthcoming 3.5 release of Lightstreamer (announced in our July 2008 newsletter)
where a new listener type will be introduced for this purpose, for all client SDKs that are currently affected by the above limitation.
