How to communicate between servers

[neurobe]

FEATURE REQUEST Re-opening this with apologies. I'm using Meteor Streamer in my app ( it's a core feature and works well thanks) but now have a need to use it from server (acting as a client) to server (acting as master). This scenario is allowed by DDP and is explicitly referenced here (https://guide.meteor.com/structure.html#sharing-data) and of course one server can happily call another server's Method over DDP.

So I start with a question as to whether there is any inherent reason why Streamer could not do this?

[In my understanding the recent change to Meteor-Streamer to allow connection to multiple servers does not allow one server, acting as a client, to subscribe to a master server. The Streamer seems to be declared not in common code, but with distinctions for client and server code.]

I can also reference this which added multi-server capability to Arunoda-Streams with a common code approach to declaration (as per Collections) and possibly allowing server-server connections (not sure about this).

USE CASE Why is server-server needed? I refer to my use case... My application is built for real-time instrumentation - typically about 256 packets per second, each packet being about 10 bytes. [DDP/Streamer is comfortable doing this and the efficiency is not outrageously bad.]

There is a meteor server on the PC adjacent to the Instrument for two reasons

• the server is needed to give the web app access to the USB ports
• the data needs to get to the adjacent web app with minimal jitter (300mS max - for logging etc)), whilst other clients, remote to the instrument, can more loosely monitor the data and can absorb web latency, but they do need to have the ability to command the instrument - >> and this is the blockage <<.

My current implementation is for the local server adjacent to the instrument to take the data and send to the adjacent client via Streamer. In parallel, it calls a method on a central server to send a packet of instrument data to that central server which then broadcasts the data via a second, globally accessible Streamer. This works ok since we know the fixed web address of the central server.

The problem arises in the the other direction when global clients want to send commands to the instrument. We cannot use methods without NAT complicating address finding for local instrument servers in the network (there will be many). A Streamer created by the Local Server would overcome this issue, and also the transport of the instrument data would be more efficient (than calling methods).

It seems that to transport a press of a button on the instrument I will be needing to use Collections. Possible, but overkill I think.

bruce.

[neurobe]

Arunoda-Streams multi-server reference.. https://github.com/foxdog-studios/meteor-streams

[neurobe]

Pull request submitted to allow server-server topology. Existing functionality and code unchanged. https://github.com/RocketChat/meteor-streamer/issues/9

closing this.