and we don’t have it.
The NAT-side server can send Method calls to central server. However the central server can’t initiate same to NAT server.
USE CASE
Instrumentation/IOT… NAT-side meteor server needs to be adjacent to instrument feeding its data over USB, to exclude network jitter, thus logging is accurate. (Also many other reasons for NAT-side server: standalone option, granting Web access to USB port, NAT side user needing jitter free signal (eg biofeedback with remote monitoring)
Central meteor server provides remote client access to instrument to control it (like pushing buttons). This is not possible AFAIK - the remote client access should not be dependant on their being a NAT-side client present (but there may be)
reporting on outcomes for those IOT types that might bump into this problem.
Recap: the issue is how to provide two-way comms between meteor servers across a NAT boundary, given that there does not appear to be a streams package (ie .emit & .on) that does server-server, even tho DPP supports the scenario, and remote Methods are hard because the address of the NAT-side server is not generally known.
The solution for me was in two parts:
1.)
For the direction NAT-side server to Network server, which for my Instrumentation App had to carry a significant continuous data stream, I have used remote calls to methods on the Network server (which has a known address).
2.) For the direction Network server to NAT-side server I have had to use a Collection on the Network Server with, on the NAT-side server this subscription…
remote.subscribe('networkEventCollection', {
onReady: function () {
NetworkEventCollection.find().observeChanges(
{ changed: function (id, fields) {}}
and on the Network-side server, this…
Meteor.publish(‘networkEventCollection’, function () {
return NetworkEventCollection.find();
});
Two points of note here.
1.) remote.subscribe on the NAT-side server works. [meteor API docs report Meteor.subscribe as Client-side only, which I guess is kinda true.]
2.) NetworkEventCollection = new Mongo.Collection(null, remote); does not work. That is, it seems that one cannot remote subscribe to a ‘local’ server-side minimongo Collection, it needs to be a real Mongo Collection. It reports error “Can’t publish a cursor from a collection without a name”. For my needs (carrying remote key-presses), a server-side minimongo solution almost certainly would have been more performant.
I’m new to all this so your mileage may vary. cheers.