Is there any difference b/w sdk-dotnet adapters of Moderato & commercial editions

[DarioCrivelli]

May you please provide us with more details on the expected and observed behaviour? What makes you feel that the update sequence is unnatural?
Note that if your application sends 2-3 kb fields and there are as many as 256 fields in an item and the fields change frequently, then the bottleneck might be on the client side as well.
Are those fields images that the client renders on the screen?
If the different fields are not meant to be updated by the client at the same time, you could rather try to define 256 items with one field each and see if the final effect is better.

[indrajit]

hi,

our scenario is like this,
we are continuously capturing screen shots and pushing them to server(we are capturing a screen shot for every 250 milli seconds).

So, for that we made an application which divides each screen shot into 256 image blocks and push them onto server continuously one by one in base64 format by using tcp/ip socketing.
And when client browses to LS Server URL he sees the screen shots which we are capturing at other end.

We are capturing & sending the screen shots and client can see those screen shots perfectly but client is taking some time( 8 to 10 seconds) to see what we captured.

So,here my question is that can we do any thing at LS server end to reduce that time taken by client browser to see captured images(ie.8 to 10 sec).

[DarioCrivelli]

Is 10 seconds the total time from taking the screenshot to seeing it displayed on the client? Is the client at 100% CPU during the process? Are you using the Javascript Client Library? (note that the Javascript Client Library is not meant for getting large amounts of data and may not be efficient for this task).

Lightstreamer allows you to operate in two directions:

• Sending the image slices independently. If you can display the image slices independently, then you can request them in such a way that each one comes in a different update and can be displayed as soon as possible, without the need to wait for the other images.
• Slowing the frequency of the screenshot updates. The Javascript Client Library has a mechanism to adaptively slow down the update frequency when the client can't keep the pace of the updates, though it has never been tested on very big updates.

But I'm not sure that the above is the kind of manipulation you are looking for. May you please clarify furtherly?

[indrajit]

yes,

we are using Javascript Client Library , is there any replacement for this because every 250 millisec. we are pushing the 256 image blocks. OR shall we go for dotnet client library to make image appearence as live.

[DarioCrivelli]

The Javascript Client Library was designed with textual data in mind; more generally, it was not designed with huge amounts of data in mind. Hence, we have no benchmarks for a usage of your kind. May you please confirm that your client CPU reaches 100% during the processing?
May you also please confirm that you are not interested to an adaptive slowdown of the refreshing frequency based on the client capability?
If this is the case, then we just suppose that part of the overhead is due to the Javascript interpreter, so that a dotnet based client may be more efficient. By the way, if you just turn off image rendering on the client but still subscribe to all the data what do you observe on the CPU of the client machine?

[indrajit]

on client side the Usage of CPU is not 100 %

when I subscribe to images on client side CPU's average usage is 7% and
when I subscribe to data without images CPU's average usage is 5%.

[DarioCrivelli]

As you have removed all bandwidth limits (which, with very huge data, could introduce significant delays)
and you haven't put any stringent frequency limit,
there is nothing in Lightstreamer that can cause delays of several seconds.
Therefore, there must be a bottleneck or a blocking behaviour somewhere else.
However, Lightstreamer may be involved only in concurring to causing a CPU bottleneck; but the client (which is the most sensitive part) seems not to be overwhelmed (unless you are using a multi-CPU machine; please confirm).
Hence, there is still no evidence that Lightstreamer is involved in the overall delay.
Before investigating further, may you please try reducing the load (requesting and rendering only one of the 256 subimages, for instance) and see if there is no delay in this case?