I have two meteor applications connected via DDP on different servers and server A send data to server B. This is the way they work.
Server A
Items = new Meteor.Collection('items');
Items.insert({name: 'item 1'});
if (Meteor.isServer) {
Meteor.publish('items', function() {
return Items.find();
});
}
Server B
var remote = DDP.connect('http://server-a/');
Items = new Meteor.Collection('items', remote);
remote.subscribe('items');
Items.find().observe({
added: function(item) {
console.log(item);
}
});
Every time I call Items.insert(something) on server A, on Server B I got a log on the console with the object I saved on Server A. But if Server B lost Internet connection, the data inserted on Server A doesn't appear anymore on Server B when it reconnect to Internet.
Server B is connected to Internet through a router. This problem only happen when I disconnect and reconnect the router, not when I disconnect and reconnect the server from the router. Both servers are on different networks and connect via Internet.
I created a timer on Server B that call remote.status() but always get { status: 'connected', connected: true, retryCount: 0 } when connected or disconnected from Internet.
Update: steps to reproduce
I created a project on github with the testing code https://github.com/camilosw/ddp-servers-test. Server A is installed on http://ddpserverstest-9592.onmodulus.net/
My computer is connected to Internet through a wireless cable modem.
Run mrt on server-b folder
Go to http://ddpserverstest-9592.onmodulus.net/ and click the link Insert (you can click delete to remove all previous inserts). You must see a message on your local console with the added item.
Turn off the wireless on the computer and click the insert link again. (You will need to click on another computer with Internet access, I used an smartphone to click the link)
Turn on the wireless on the computer. You must see a message on your local console with the second item.
Now, turn off the cable modem and click the insert link again.
Turn on the cable modem. This time, the new item doesn't appear on the console.
I also did it with an android smartphone using the option to share Internet to my computer via wireless. First I turned off and on the wireless on my computer and worked right. Then I turned off and on the Internet connection on the smartphone and I got the same problem.
Update 2
I have two wireless router on my office. I found that the same problem happen if I move between routers.
Emily Stark, from the Meteor Team, confirmed that this is due to a missing feature on the current implementation (version 0.7.0.1 at the moment I write this answer). Their answer is here https://github.com/meteor/meteor/issues/1543. Below is their answer and a workaround she suggest:
The server-to-server connection is not reconnecting because Meteor currently doesn't do any heartbeating on server-to-server DDP connections. Just as in any other TCP connection, once you switch to a different router, no data can be sent or received on the connection, but the client will not notice unless it attempts to send some data and times out. This differs from browser-to-server DDP connections, which run over SockJS. SockJS does its own heartbeating that we can use to detect dead connections.
To see this in action, here is some code that I added to server-b in your example:
var heartbeatOutstanding = false;
Meteor.setInterval(function () {
if (! heartbeatOutstanding) {
console.log("Sending heartbeat");
remote.call("heartbeat", function () {
console.log("Heartbeat returned");
heartbeatOutstanding = false;
});
heartbeatOutstanding = true;
}
}, 3000);
remote.onReconnect = function () {
console.log("RECONNECTING REMOTE");
};
With this code added in there, server-b will reconnect after a long enough time goes by without an ACK from server-a for the TCP segments that are delivering the heartbeat method call. On my machine, this is just a couple minutes, and I get an ETIMEDOUT followed by a reconnect.
I've opened a separate task for us to think about implementing heartbeating on server-to-server DDP connections during our next bug week. In the meantime, you can always implement heartbeating in your application to ensure that a DDP reconnection happens if the client can no longer talk to the server.
I think you are not passing DDP connection object to the Collection correctly, try:
var remote = DDP.connect('http://server-a/');
Items = new Meteor.Collection('items', { connection: remote });
It might be useful for debugging to try all these connection games from the browser console first, since Meteor provides the same API of connection/collections on the client (except for the control flow). Just open any Meteor application and try this lines from the console.
I revised a sample of communication between two ddp server, based on camilosw's code.
Server A as Cloud Data Center. Server B as Data Source, if some data changed, should be send to Server A.
You can find the code from https://github.com/iascchen/ddp-servers-test
Related
Is there a way in dart to get notified (listen to) when the network disconnecting and do action only if it off?.
I do not want to check internet connection so no need for pinging google.com (connection to router without internet is still good).
Searching for simple way that interact with the network interfaces of the device and listen to change or return True/False about the network state.
In worse case I can use Process.run(...) with bash commend but this ugly fix.
No flutter here only pure dart (dart Console Application).
If you are running the program on linux you can use bash commend like this
// Check if connected to network, if there is a connection than return network name
Future<String> getConnectedNetworkName() async {
return await Process.run('iwgetid',
['-r']).then((ProcessResult results) {
print(results.stdout.toString());
return results.stdout.toString().replaceAll('\n', '');
});
}
This will return network name even if the network does not connected to the internet
In the offline capabilities section for Web, it is described here how to detect if the client is connected to the internet or not. However, Firebase doesn't seem to call the event handler every time a client connects or disconnects when running in Node environment. It works as expected when running in the browser i.e. it calls the event handler every time the client is connected or disconnected from the internet.
Check out this jsFiddle. Once you run the fiddle and you connect or disconnect from the internet, you will see a corresponding 'connected' or 'disconnected' message in the console.
I ran the below code in Node which is exactly same as the code I ran in browser. While running in Node environment, I observed that I received the initial 'connected' and 'disconnected' message but if I connected and disconnected from the internet again, no messages are printed meaning that the event handler is not called
var Firebase = require('firebase');
var ref = new Firebase("<FIREBASE-APP>");
var connectedRef = ref.child(".info/connected");
connectedRef.on("value", function(snap) {
if (snap.val() === true) {
console.log("connected");
} else {
console.log("not connected");
}
});
I just ran the same script in node on my system:
$ node connected.js
not connected
connected
not connected
connected
The first two come from the initial start of the script. The last two log lines came after I turned the wifi of my laptop off for a minute and then on again.
It may take some time before the Firebase client detects that it lost the connection to its servers, so be patient. The reason for the time it takes depends on the environment (browser/node) you run in, since the Firebase client depends on that environment to provide the WebSocket and detect time-outs.
I'm using Chrome's Serial Port API (http://developer.chrome.com/apps/serial.html) in a Web App.
The problem I have is that pretty much all serial ports now are implemented via USB devices. If the user disconnects (or just resets) the USB device, I don't have any way of knowing. Not only that, because the app hasn't disconnected in Chrome (because it didn't know), if the USB device is plugged back in, bad things happen (on Linux it just gets a different name, but in Windows it is not usable at all).
The best I can manage is:
var checkConnection = function() {
chrome.serial.getControlSignals(connectionInfo.connectionId, function (sigs) {
var connected = "cts" in sigs;
if (!connected) console.log("Disconnected");
});
} // called every second or so
Is there a better way? a callback would be ideal!
It looks it should be safe on all platforms to assume that getting a read callback with 0 bytes means EOF, which in turn is a good indication that the device has been disconnected.
chrome.serial.read(connectionId, function(readInfo) {
if (readInfo.bytesRead === 0) {
/// Safely assume the device is gone. Clean up.
chrome.serial.close(connectionId);
/// ...
}
});
The serial API will be improving over the next few weeks (in Canary at least) to add stability improvements, an event-based read API, and the ability to more clearly detect timeouts and error conditions (like a disconnected device). You can track that progress at http://crbug.com/307184.
I would want to send a message from the server actively, such as using UDP/TCPIP to a client using an arduino. It is known that this is possible if the user has port forward the specific port to the device on local network. However I wouldn't want to have the user to port forward manually, perhaps using another protocol, will this be possible?
1 Arduino Side
I think the closest you can get to this is opening a connection to the server from the arduino, then use available to wait for the server to stream some data to the arduino. Your code will be polling the open connection, but you are avoiding all the back and forth communications to open and close the connection, passing headers back and forth etc.
2 Server Side
This means the bulk of the work will be on the server side, where you will need to manage open connections so you can instantly write to them when a user triggers some event which requires a message to be pushed to the arduino. How to do this varies a bit depending on what type of server application you are running.
2.1 Node.js "walk-through" of main issues
In Node.js for example, you can res.write() on a connection, without closing it - this should give a similar effect as having an open serial connection to the arduino. That leaves you with the issue of managing the connection - should the server periodically check a database for messages for the arduino? That simply removes one link from the arduino -> server -> database polling link, so we should be able to do better.
We can attach a function triggered by the event of a message being added to the database. Node-orm2 is a database Object Relational Model driver for node.js, and it offers hooks such as afterSave and afterCreate which you can utilize for this type of thing. Depending on your application, you may be better off not using a database at all and simply using javascript objects.
The only remaining issue then, is: once the hook is activated, how do we get the correct connection into scope so we can write to it? Well you can save all the relevant data you have on the request to some global data structure, maybe a dictionary with an arduino ID as index, and in the triggered function you fetch all the data, i.e. the request context and you write to it!
See this blog post for a great example, including node.js code which manages open connections, closing them properly and clearing from memory on timeout etc.
3 Conclusion
I haven't tested this myself - but I plan to since I already have an existing application using arduino and node.js which is currently implemented using normal polling. Hopefully I will get around to it soon and return here with results.
Typically in long-polling (from what I've read) the connection is closed once data is sent back to the client (arduino), although I don't see why this would be necessary. I plan to try keeping the same connection open for multiple messages, only closing after a fixed time interval to re-establish the connection - and I hope to set this interval fairly high, 5-15 minutes maybe.
We use Pubnub to send notifications to a client web browser so a user can know immediately when they have received a "message" and stuff like that. It works great.
This seems to have the same constraints that you are looking at: No static IP, no port forwarding. User can theoretically just plug the thing in...
It looks like Pubnub has an Arduino library:
https://github.com/pubnub/arduino
I have a multi-process TCPServer which creates (by fork() on linux) one process (child) per client's request, and in the meanwhile it is listening other connection's request. So I have a 1 to 1 mapping between client and server.
Suppose that one client crashes...is it possible to reconnect it to the same child server process?In other terms..is it possible to restore a pre-exhistent connection which is failed or the attempts to reconnect create a new connection (and then a new child server process)? thank you...
Without some knowledge (by the forker) of the interior session-related details (of the forkee), you have to make assumptions about external details being adequate to determine which remote connections get re-associated with which local connection end-points.
You could change the way things work in your application, though. Oracle SQL*Net does this on some platforms (due to platform limitations).
The initial connection to the TCPServer causes a fork and then opens up a new listening socket, sends back a redirection instruction to connect to the new listening socket & identifying details (to avoid someone else connecting and impersonating the original connector). The client then connects to the new socket, and uses this socket to do any re-connections upon disconnects before their time.
I have done something very similar to this in .NET platform. If you have something which is unique for every connection (for example IMEI of the connecting device this can be done).You should have some global two-dimensional array variable with combination of ProcessID and IMEI. So when device is disconnected and then the device reconnects you only search in this array for this IMEI and you have the process for this device. You should be very carefull with this global variable.
Edited:
I gave an example of some unique identifier. In my case that was the IMEI of the devices. In your case that could be something else which you know it is unique.
I had to do this because I had very big problem with devices breaking up the connection. Every new device was new connection so afterward I ended up with very big CPU usage.
Maybe you can refer https://eternalterminal.dev/howitworks/. Both the client and the server need change.