Shared workers support?

[puzrin]

This is technically interesting thing, but probably not so useful on practice

pros

• Zero downtime of shared realtime server connection when user closes mastered tab.

cons

• More complex setup
• Need duplication of client code (server connector)
• Still needs iframe for cross-domain comm

problems to solve

• No master tab. How should we deal with it, to make work both LS and SW modes?
  • If we don't emulate legacy master events, then user MUST create SW client with server connector. If we emulate legacy master events, tab (LS) clients can conflict with SW client.
  • Problem not exists, if we DON'T place connector in userland - use it in router frame.
• Simplify config for single domain
  • try to create SW via blob and pass it's ID trough LS or cookies (don't require user to prepare additional file).

If you need SharedWorkers support - post your use case in this ticket, with explanation, why that's really needed.

[puzrin]

Preliminary conclusions

1. If SharedWorker used, it MUST contain server connector, or major advandages will be lost. So, it can be master forever, and don't broadcast !sys.master at all. So, no conflict with LS-clients happen.
   • that will work both for local domain & foreign domain via iframe.
2. Note in doc that !sys.master event is specific to LS router.

[STRML]

Hey @puzrin - thanks for making this repo, I saw your comment on the Primus Webworker ticket.

I think SharedWorker support would be great for applications utilizing realtime data that can't afford downtime on the link without an expensive re-image. For example, I run a trading site that has a lot of real-time book and trade data coming down the feed (we actually have 12 live feeds at once per tab). I'm investigating using tabex to fix the multi-tab use case but of course if the master is terminated a reconnection will need to happen. During the time taken for the reconnection, we have no choice but to emit a 'disconnected' event in our app so that it knows to reimage all data from the HTTP endpoint when the websocket reconnects.

SharedWorkers sound like the best of all worlds here but it is unfortunate that there is no support planned by Microsoft. And the use is different enough that it could be difficult to keep in sync with the traditional LS method.

So it seems like more of a "nice to have" then a "need to have", but as browser support grows it would be really great to have a library like tabex keeping the use case simple and the fallbacks available.

Perhaps an SW integration would involve changing tabex to explicitly support the leader election use case via something like an onMaster callback option. This would e.g. create the Faye connection and wire message events into the tabex. In SW mode, this would get turned into a Blob and executed in the SW. In LS mode, we can then implicitly execute this on '!sys.master', doing the data.node_id === data.master_id check automatically.

Thoughts?

[STRML]

Just thought of an additional advantage to SharedWorker - we're currently running into a timer deferral issue on Safari and mobile browsers in Primus because of power saving. This is causing problems with heartbeats (Primus heartbeats are sent by the client on a timer) which causes disconnects. This could mean that if the master tab is unfocused, the websocket could disconnect, causing events to stop to the other tabs. I haven't checked specifically, but a SharedWorker should not be subject to this throttling as it is technically still active.

[puzrin]

https://github.com/nodeca/tabex/issues/5 if heartbit sucks, it worth to improve heartbit logic first. All browsers with SharedWorker support have no problems with timers when those are created via WebWorker.

Since we had no special requirements for delivery guarantees, we postponed SW implementation to volunteers. In our case LS router is more simple to use. All tickets in this repo are for records - if someone wish to extend.

[STRML]

Thanks for the reply. I think this will be a good reason for Primus to move heartbeating to the server as the timer delay problem is only getting worse with time.

Nice implementation re: WW timers. This may be a good candidate for a separate module or as part of tick-tock so we can delay the damage for a while.

Would you be okay with me using your code and refactoring the timers to another module for use in other projects?

[puzrin]

Would you be okay with me using your code and refactoring the timers to another module for use in other projects?

No problem. Use it as you wish.