Hi,
I am developing a C++ INDI client and I am wondering how a client should behave when a device has restarted because of a crash. To react properly a client should get notified but I didn't find anything in the specification except handling of timeouts. But how to distinguish between a network disconnection and a device restart?

Possible solution: After restart the server sends def{Property} messages . So if a driver is connected (as seen by the client) and the client receives def{Property} messages, then the driver must have been restarted. Is this a proper approach, or is there a better solution?

Another thing I was thinking about is about watching a device. It seems that you have to register the devices "for watching" before the server connect. But at that tine I usually don't know which devices are connected to the server. Wouldn't it be better to first connect to the server, get the names of the connected devices and then register the devices which I want to watch with my client ?

Thanks,
Klaus

Hi Klaus,

I think it would be better to send an email to INDI Development list to discuss these issues, there it would get more exposures to the developers.

Yes, you are right. I sent a mail to the indi-devel list. Thanks!

Hi Jasem,
I've sent a proposal how to solve this issue to the indi-devel mailing list. I think it is a bug ...

Thanks,
Klaus

Yes Klaus, I saw that but there is one issue. delProperty cannot be used to signal that the driver has crashed, it simply means the device is not available for whatever reason, and can be available later. When the client explicitly requires to stop a driver, the delProperty makes sense in this instance. But for a crash again, it has to be something else, but I don't want to add something to INDI server unless Elwood and everyone else agree to it so that the behaviour is consistent among all clients , so please try to contact Elwood directly to discuss a solution.

Jasem, I have the same problem and think that the cleanest solution without any change to INDI protocol is that indiserver will present itself as a special device with properties related to the status of the drivers. What do you think about it? Peter

OK. In my proposal I weakened the requirement in the sense that the client does not need to distinguish between restarts and temporary unavailability of the drivers. Therefore I added a delProperty at all places where a shutdownDvr follows in the code. You are right, a shutdownDvr with a restart option means that the driver will be available later, but the connection to the client is lost and with that all property settings. Or is the idea that the client automatically tries to reconnect to the driver with all property settings which were set before the shutdown? That would be smart but quite complicated and requires the client to know that the driver was shutdown.

Yes that would be an elegant solution. I would appreciate if you send this proposal to the imdi-devel mailing list.
Klaus

I was actually about to file a bug report about this as I noticed that hot-plugging doesn't seem to be supported by the Atik driver (haven't tested anything other than the Atik driver and some simulators). I've realised now that I can work around that by running in fifo mode and having it start the driver over the fifo in response to user interaction, but we need to know when the device is disconnected also.

I note that INDI has some standard properties, one of which is the connection switch. Could we not use this switch for this purpose?

Cheers,
Lee

Hi Lee, INDI drivers are typically libusb based and hotplug is not in general supported in libusb. CONNECTION switch is quite unreliable for driver failure detection.

Look at my changes in indiserver (conditionally compiled for OSX port only) and how I monitor driver status in OSX INDI Server app ( CMAppDelegate.m ).

Peter