mmehr2
commented
6 years ago The discussion needs to be updated with Pubnub in the mix. Since every connection with Pubnub is outbound from the device (PRIMARY or SECONDARY), there should be no objection here, or need to do this feature.
However, the middle step (2, above) may still prove useful in dealing with some other misfeatures of Pubnub, for example, the sub loop's message traffic being excessive if left on 24/7. We need some way for a signal to wake up the SECONDARY from its seldom-polling mode. Perhaps this is a keystroke on the machine, perhaps something more complicated.
For now, we'll let this go as Will Not Fix. Reopen if it becomes a priority for this or future customers.
This is a copy of an unsent email draft I wrote to document the discussions we had with the customer at an early stage of the project.
Hi Steve,
We talked (Lee and Brent from ReadyCam, Eric and I). I understand their scenario better, and we brainstormed what works for their security requirements between their main office and the remote studios.
They have a rack of equipment at each control room site that has a master controller computer, which controls each camera, light, etc., according to the APIs and comm channels it wants. They are all on a LAN together.
They say it's easy for them to punch a hole in their firewall (main office) for a custom port on their end, but not on their customer's (control booth's) end. So we developed this method of establishing a link between the Primary (main office) computer running MSW and any Secondary on a teleprompter device.
The third actor here is the Controller (rack mount computer controlling all the equipment). Easiest access method is via RESTful APIs over http locally (behind the firewall), so:
Primary sends an HTTP REST command to Controller to establish a connection, provides callback IP and port, and Secondary number (could have more than one) - requires new development by ReadyCam engineers; config - Primary needs to know what IP to send this request to (URI?)
Controller responds to this, looking up the IP and port of the MSW Secondary specified, and sends it another HTTP REST command to establish the connection to the provided IP and Port
Secondary responds to HTTP REST command, and sets up outbound connection request to provided IP and Port of Primary.
This sets up the channel between Primary and Secondary and they talk using what I said I would do in the prior email.
Assuming I'm on track, I figure there's no need to operate with a human user in the lights-out control booth at all. I verified with this customer, at least, that the teleprompter is the only device on their rack that isn't fully automated yet. So, the comm link will be the only thing giving operational commands to the Secondary MSW program.
We can always implement a watchdog timer to reset things in case of latchup, and that sort of thing.