Datasocket handle and updates

[JGS]

Hello all,

I'am using CVI 6.0, and I am just building my first datasocket application.
For measurement applications I want to build some blocks for a datasocket writer, that exports a panel-image as BMP-formatted data to a datasocket server. Typical this is a panel that shows the progress of a measurement. The data will be typical 500 kBytes. Although this seems a lot for - sometimes only - a few values, I can use the same building blocks for all my measurement applications regardless of the progress indicators.
I want to build a separate reader, that retrieves such a BMP image from the datasocket server and displays it as a kind of progress-indicator. I am starting this development with reader, writer and server at one computer i.e. all refer to dstp://localhost/bmp. As general evaluation: it works fine for a first test but it is not yet finished.

I have started with the data-socket CVI samples and have build my own two applications. However from the CVI examples reader.prj and readerattr.prj it is not clear to me what the optimal use of dshandle is in the DScallback function. Both examples use a global variable for the dshandle. However the DScallback function has a function parameter that also is a dshandle; I assume that this function parameter value is send by the server. Especially readerattr.prj uses its global variable to check if it has connected previously to the datasocket server, but it uses the function parameter to retrieve information from the server.
Should these two handles be equal ?
Should I check that they are equal ?
Which is best to be used when reading the data from the server ?

I have some update-problems with the reader application. From the non-auto-update writer I occasionally send new data to the server using DS_SetDataValue() and afterwards call the function DS_Update(). With the server shown, I can see that the packet counter is always incremented with each update. The reader is configured as ReadAutoUpdate. Often it gets the message (DSCallback) from the server and starts to download and update the new image data. However sometimes (irregular) it does not get this message; if so, this keeps so until I re-connect the reader application to the server. Meanwhile I retrieve regular (with a timer) the last message from the server. As I get a proper reply from DS_IsConnected() and DS_GetLastMessage() is does not seem as if the connection is broken. After I re-connect, the reader application is always able to read at least once - and mostly multiple times - the updated images. I do not yet see a pattern in the loss of read-auto-update.
Do you know of any reason why the reader application does not gets the call to DScallback ?
Do you know additional techniques to verify the reader-server connection ?
Are there any other methods to check for the update without bothering the server each few seconds ?
If you advise to use non-auto-update for the reader and use DS_GetDataUpdated(), will this also work when two or more reader-applications request the same data from the server ?

Are there functions available to see more server information e.g. a server monitor that shows all available data and that shows connected computers-applications ?


Thanks for any contribution, and regards
Jos

[cosmo]

Hi JGS,
You really have two options, or two styles, for how you use the DS callbacks. You can either setup multiple DS items to go through a single callback, or you can setup multiple DS items to each have their own callback. And of course, you can use a combination of both if you like. It kind of depends on what you want to do, but I tend to use the single callback method when there is a low volume of updates.

So, if you consider the shared callback style, you might have completely different logic that needs to be run depending on the DS item that is generating the callback. In that case, you use a SWITCH or IF...ELSE construct to make sure that only the appropriate logic is used. i.e. When the callback for DS item 'X' is fired, do logic 'X', and if the DS item for 'Y' is fired, then do logic 'Y', etc. The sample project that you referred to verifies that logic 'X' only gets run for DS item 'X', but will do nothing if you add your on DSS items 'Y' or 'Z'.
On the other hand, you might have multiple items that need practically identical logic, so the DS item itself becomes the identifying element. In this case, you specify unique callback values in the callback data parameter. i.e. When the callback for any DS item using the callback is fired, run identical logic regardless of the DS handle, except turn on/off the LED for DS item 'X' or 'Y' or 'Z'. You will know which LED needs to be changed by looking more to the DS callback data value than the DS handle--even though you could use the DS handle anyway. If you rely more on the DS callback data value, you could remove the sample project's DS handle IF construct completely.

As you are starting to find out, there are some difficulties with using DataSockets. The status of the client-server link (technically 'client writer'-'DS server'-'client reader') might involve the writer changing a value every few seconds. If the reader doesn't see the value change in xyz seconds, then be aware that the link may be stale. I use the term 'stale' here because as long as the server is running (the DSS), the values will persist for all connected clients. That is mainly good, but it can sometimes be not what you wanted. So you have to code around it.
Another very dangerous landmine: you can't always rely on the returned status from DS function calls (especially if the DSS is not running when the clients attempt to connect to it). Last time that I spoke with NI, they seemed to have no intention of fixing the problem. Their workaround was to call DS_GetLastError() after every single command. This bad-return code problem with an offline DSS was verified by NI in CVI version 7.0, 7.1, and 6.x (even though one of my CVI 6.x returns an error code correctly). Just be aware of how you need to program around the limitation.

I don't think they have any functionality that allows you to see what other clients are connected natively in DS. You can try to do this yourself, i.e. every client reader sends a unique ID to the server to show you who 'should' be online (assuming the link to that client isn't stale). You shouldn't have problems with multiple client readers requesting updates for the same information, whether you use ReadAuto or Read. If you need multiple client writers, look to other articles and the KnowledgeBase as others have already solved this problem for you.

Good luck,
Orlan Franks