search

spacetelescope / catkit2

Package for controlling testbed hardware.
https://spacetelescope.github.io/catkit2/
BSD 3-Clause "New" or "Revised" License
3 stars 0 forks source link

Remote access to the TestbedProxy ? #160

Open a-sevin opened 7 months ago

a-sevin commented 7 months ago

Hi all,

This is more of a discussion thread than an issue.

I tried to define the IP of the 'Testbed' as 'INADDR_ANY' (0.0.0.0) and, at the same time, defined the variable 'testbed' as 'TestbedProxy('server_ip', 8768)'.

When I tried to access the remote camera with 'cam = testbed.science_camera', I received an error message: 'AttributeError: Something went wrong while creating shared memory.'

Is this expected behavior?

Cheers,

Arnaud

ehpor commented 7 months ago

So, the testbed proxy has to be on the same computer as the testbed server and the service itself.

I'm not sure if by "remote access" you mean accessing the camera from a separate computer or not?

a-sevin commented 7 months ago

Yes, I hoped to separate the bench and its services from the client (testbedproxy).

It seemed possible since a testbedproxy requires an IP address upon creation.

It could be a very nice feature, as every user wants to have their own environment, including their preferred operating system, libraries, and custom tools. However, this would require a lot of work.

ehpor commented 7 months ago

Yes, but this would require all shared memory communication to be emulated over TCP or similar. Which is a huge undertaking. Also, fast access to datastreams would not be fast anymore.

We've thought about having a TunneledService which does exactly that. This was when we had a hardware device (our IrisAO DM) that potentially wouldn't work on a newer version of Windows. Our backup plan was to have two testbed servers running, one on computer A with all other services and one on computer B with the IrisAO. We'd have a tunneled service client that mimics the IrisAO on computer A, that communicates to the tunneled service server on computer B that in turn communicates with the IrisAO service. The only concern would be latency. It turned out that the IrisAO worked fine on the new operating system, so we never started any implementation for this. Also, this would be on a service-by-service basis. We never considered a testbed-server-wide implementation.

Now that I'm thinking about it, you could have a single tunneled server service on the server-side and many tunneled client services on the client-side. As long as they're written well (ie. threaded), the communication should be as seamless as a single server per service would be. I'm not an expert in interconnects, so I have no sense of expected latency / throughput here. I see some minor but solvable complications with how config is managed, but that'd fine.

I'm not sure if all of this makes sense.

a-sevin commented 7 months ago

I think it's important to mature it a bit before to doing anything...

Have you heard of RPyC (https://rpyc.readthedocs.io/en/latest/index.html)? It's a great solution for manipulating remote Python objects, which I think works better than Pyro.

Although I'm not entirely sure about the overall architecture, I believe it has a lot of potential. I'll definitely keep it in mind for future works.