Implement suspend/resume mechanism

[MichaelWedel]

As outlined in #144 and #145, the way disconnecting/re-connecting the device worked as of 1.0 it was more or less a suspend/resume mode.

In PR #170, this is fixed, but now there is no suspend/resume mode anymore. We should think about introducing that mode explicitly, but it's probably not that urgent since we did not have this mode in mind when we did the original implementation.

[MikeHart85]

I don't think this should be backlogged, since (while implemented accidentally) suspend/resume is a desirable feature that we want to have. It doesn't seem right to have a release that removes existing and useful features.

[MichaelWedel]

If we move this to Release 1.1, we need to have a somewhat better idea what suspend really means. We can't "implement" it in the way we did before, because that doesn't resolve #144.

Is this protocol specific? How do we model "hanging" devices?

[MikeHart85]

We also already have pause and resume commands for hanging the simulation of the device itself. But that leaves the interface alive and responding normally. I wonder if this should be part of that, or separate functionality specific to the connection.

The implementation will definitely be protocol specific in any case. That shouldn't be a problem though, it's the same for connecting and disconnecting. From a Stream TCP perspective, I think the correct behaviour would be:

• Current connections stay open
• New connections are rejected or time out
• Commands from current connections are flushed/discarded on resume

[MichaelWedel]

Good question regarding pause/resume...I haven't made up my mind about this yet. On the one hand it seems logical that a paused device would not respond to commands, on the other hand it could still be useful behavior (e.g. to pause the device before or after some failure and see what "it says").

Probably it's not only depending on the protocol, but also on the device. I think EpicsAdapter is a good example for what I'm trying to say here - suspending communication would be roughly equivalent to some problem in the IOC, while the underlying device would of course continue to function. In some cases of StreamAdapter that might be similar, if the device has some sort of higher level computer thing that manages a network connection (or is connected via a serial to ethernet adapter that can have its own problems).

Having written all that I begin to think that these are different things and should be separate: One aspect is the device simulation (for which we have pause and resume) and one is the communication, which would be suspend/resume.

Can we find another terminology for suspend/resume to make it more clear what we mean?

As a side note, I think for the EPICS case it is enough to stop calling handle.

[MichaelWedel]

As those will be methods of Simulation, we should maybe stick to the naming we've used so far. We have pause/resume for the simulation itself, while we have connect_device and disconnect_device for interacting with the device. Maybe it could be suspend_communication/resume_communication?

[MikeHart85]

I don't know... it all seems very verbose and not very consistent. connect_device and disconnect_device really only affect the communication (adapter) layer as well. I can't recall... was there a reason we didn't call those connect and disconnect?

[MichaelWedel]

I'm not 100% sure but I think that was to make it clear that it's affecting the device, not the control client or any other thing that is running.

[MikeHart85]

Another thing to think about (as if it's not enough) is that we keep floating the idea of supporting multiple interfaces simultaneously. Perhaps each interface (eventually; for now just the single one) should be a top level object in the control interface? So alongside device and simulation?

[MichaelWedel]

That would certainly resolve the ambiguity in the different suspend/resume things. What about disconnect/connect though? Given that this is supposed to be "physically cutting the cable" it might affect all interfaces. But then one device could be connected to multiple "boxes" that do communication via separate wires...for the sake of simplicity and ease of use we should probably allow both - one "big red button" that disconnects/suspends all interfaces (I think this is the most common use case although I can't provide evidence), but also allow doing that for each interface separately.

This means that we'd still have to have a method on Simulation to do this.

[MikeHart85]

For completeness and convenience, each interface could have connect / disconnect and simulation could have connect_all / disconnect_all.

[MichaelWedel]

Yes, that's exactly what I meant - we have it as connect_device and disconnect_device now. What do we call the convenience suspend_all/resume_all?