assurance-tunnel
assurance-tunnel
assurance-tunnel
assurance-tunnel

FR: Websockets actor



  • Scenario I need this for: I am using an Augmented Theatre App during the shows, in which the audience's smartphones are controlled by the server using OSC protocol. For realtime immediate action on hundreds of the devices, I found that OSC is not the best tool. Theoretically, I think the websockets protocol is better: the connection between the server and the client does not have to be established on every command. I think websockets will be better for the task. I could have a standalone websocket server up and running in a few minutes (which itself is controlled by Isadora using OSC) , for example, using node.js, however, in the field maintaining another layer should be avoided.

    --8


  • I agree to some degree, but if you analyze the data topology of a show, it would make a lot of sense to offload the websockets communication to another layer, or better yet computer. In this scenario if possible I would run it on another machine, not adding this proces in Isadoras non-threaded environmnet, rather letting izzy just send a command to run a service.

    Node-red is your friend here, super easy and fast to configure and it will do everything you need. You could run it in the background or on another machine (even an Rpi, but it is worth checking the performacne but a 3 should do it fine)
    I also had excellent and very fast connectivity with websockets even over 3g internet....it is a great technology.


  • Thanks @Fred for validating my desire to start using websockets.

    Regarding the architecture: It's a realtime TJ application, which already runs on a separate computer / dedicated Isadora. My goal is to switch it to websockets so that operator does not have to be re-trained. Installing and maintaining node js layer, for example, would mean a risk of operator's not being able to bring the whole system up before the show.
    --8


  • Check node-red, you can make it start on boot very easily.


  • Tech Staff

    If you are sending OSC via udp a connection shouldnt need to be established for each message.

    Sockets are great for larger sets of data. I've used them for a number of things... need to be dealt with in a non blocking way.


  • @DusX

    _If you are sending OSC via udp a connection shouldnt need to be established for each message_
    You may be right there, however UDP itself does not guarantee the message delivery: either way, I am seeing not all messages delivered to all devices, or delivered at different times.
    Yeah, for the large data, non–blocking can be important.
    @Fred: will check node-red, thanks.
    --8