Pubnub subscription calls need to be shut off to save sub message traffic

[mmehr2]

After a reply from Vladamir at PN Support, I am aware that the empty-response completion of pn subscribe calls is a feature of the server whose timeout we have no influence over. Thus, keeping a continual subscribe listening at all times is guaranteed to generate message traffic. We need to throttle this back, perhaps over various times, or otherwise limit the use of subscribe() calls.

This is a side effect of using the PN cloud system, which only tries to simulate point-to-point communications.

[mmehr2]

One idea I toyed with is having "office hours" for the SECONDARY. User could configure times of the workday (and which weekdays those are) during which subscribe polling would happen. It would be shut off at other times to save traffic. Perhaps an intermediate setting would also be advisable for weekday use in non-intense situations, to guarantee eventual hookup.

Or we could configure that REST API we had explored with the ReadyCam customer, for controlling the equipment via their local equipment rack controllers, to have a command to alert the SECONDARY to start accepting calls. Hardly ideal, but it could work. We'd need some kind of local mini-server socket listening on HTTP port 80 for these local commands. This brings back the work on the CustomSocket API. See other issue yet to be posted about this requirement from the customer, not the client.

[mmehr2]

There is one thing I can easily do to fix some of this. The Primary does NOT need to be doing any subs normally. It may even be possible to prevent them from doing any at all (one-way communications always except when we know an answer is coming). This should cut usage on the Primary a lot.

However, there will normally be many more Secondaries in the field, and they will all be subscribing, so the previous ideas about office hours, etc. WOULD still apply to their code.

The Primary usage we see DOES show how much happens during a scrolling session, so the overall traffic numbers are still also valid for tracking monthly usage for sessions regarding billing. See issue #13 about related work.

[mmehr2]

Work tasks:

• [x] - Primary shutoff - once we know we are in a Primary confugration (compile time), don't start up the sub channel (local) until connect time, then do both. REQUIRES Dual config issue #19
• [x] - Secondary shutoff: don't start local channel until Login button pressed, and no need for Remote channel at all (yet) unless talk back is required (2-way protocols)
• [ ] - ENH: Office hours config: needs better definition, but for now, shutoff listening during nights and weekends. Engineer to edit this in the INI file for now.
• [ ] - ENH: Remote kickoff by ReadyCam controller or some other method to get the attention of the Secondary.
• [ ] - ENH: Scheduled Session Times: This feature deserves its own comment (see below).

[mmehr2]

Scheduling Session Times

This would allow the Primary user to program the response times for the Secondary (when it would listen for links). Basically, the Primary could set up faster response times by sending the schedule of Studio Session Use to the Secondary (or somehow have it tap in). When the Talent was in the studio, it would start listening for connections.

Perhaps just the manual Login button would be okay tho.

Or maybe ECS can sell a simple IoT presence sensor that would start the listening when the lights were on or something. Or ReadyCam engineers can program this signal from their rack controllers somehow.

This is all trying to save billing generated by having each machine constantly listening with traffic every 280 seconds, 24/7/365.