refactor the WebSocket server for LSE

[xiaoyachong]

We plan to move the WebSocket listener and the Tiled image publisher from LSE to arroyoXPS. I have a few questions:

1. Instead of keeping both the WebSocket server and listener in arroyoXPS, should we remove them and replace them with a ZMQ server that sends RawFrameEvent directly to LSE?

frame_event = RawFrameEvent(
            image=SerializableNumpyArrayModel(array=shot_mean),
            frame_number=self.frame_counter,
            tiled_url=tiled_url,
        )

My concern is that this may break the arroyoXPS frontend, since the frontend app may still expect WebSocket messages.

2. For the Tiled publisher, would it make more sense to add it in timepix_splash instead of arroyoXPS? Adding the Tiled publisher to arroyoXPS instead of timepix_splash may introduce two potential issues:

• This would cause sending large images, potentially tens of MB (depending on bin size), from timepix_splash to arroyoXPS.

• There may be a synchronization issue. For example, if timepix_spash starts before arroyoXPS, it may send images before arroyoXPS is ready. This could cause indexing issues when reading from Tiled. If timepix_spash has already sent 10 images by the time arroyoXPS starts, the 11th frame might be written to Tiled as the first image, while the reader may request ?slice=10:11, which would fail. One possible workaround is to write to Tiled only after a start message is received from splash_timepix.

[dylanmcreynolds]

Yes, I like the idea of both arroyo units listening to ZMQ in parallel instead of the current solution of chaining one to the other.

My concern is that this may break the arroyoXPS frontend, since the frontend app may still expect WebSocket messages.
This is super confusing and separting things out should make it simpler. Let's make two publishers:

• one to publish images from arroyoXPS to the browser
• one to publish LSE information from LSE to the Dash Browser

They really are different, so let's make them different.

This would cause sending large images, potentially tens of MB (depending on bin size), from timepix_splash to arroyoXPS

Let's not prematurely optimize this. If it becomes a problem, we can use ZMQ multi-casting to avoid sending the same payload multiple times on the network (http://api.zeromq.org/master:zmq-epgm)

There may be a synchronization issue.

Good point. What if we make a rule that any independent application doesn't try and display a scan until it gets a start document? If things startup and miss, fine.

Another Thought

Websockets are great but have some limitations, like the default size limit we found at beamtime last week. They are a little tricky to scale because they don't natively support backpressure. This means that it's really undefind what will happen if the client can't keep up with the server.

There is another technology called Server Size Events (SSE). It is natively supported in web browsers. Essentially, the browse makes a GET request that stays open indefinitely, and when the server has data for it, it sends it.

The downside is that it's one-way...server to client. Client to server would have to be another REST endpoint.

I would love to try building one.

You may not know this because the idea was hatched this morning, but @alisonscheng is going to look at converting the LSE to a finch-ified React app with a backing REST service.

So, if you like my idea above of making separate publishers, one for ArroyoXPS and one for LSE...I would really like to try doing the ArroyoXPS.