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.
Related
currently, I'am using dpdk by sending and receiving the packets in to the rte-rings. I'am having difficulty of finding the proper way of to notify the application that the DPDK received incoming messages.
In order to check the whether the rte_ring has received the data or not, I run a busy loop on the rte_ring.
here is the example below
while (1) {
if (rte_ring_dequeue(rx_ring, &_msg) < 0) {
usleep(5);
} else {
recv_msg = (char *) _msg;
if (chara_debug) printf("[%d] Server merge data::[%.24s...]__length::[%ld]\n", batched_packets, recv_msg, strlen(recv_msg));
collect_packets++;
if (collect_packets > MERGE_PACKETS) break;
}
}
However, my fellow developers say that this is not a efficient way nor the proper way of checking received messages. Busy polling should be only done in the DPDK API and not in the application.
Is there a way for DPDK to send a signal to the application so that the application can only check the rte_ring only when there is a received message?
Well, direct answer is to use DPDK event library: http://doc.dpdk.org/guides/prog_guide/eventdev.html
But it is not that smooth. Unless you have a hardware which directly supports the event model, you still need at least one RX core to poll (i.e. do the busy loop) as shown on this picture:
http://doc.dpdk.org/guides/prog_guide/eventdev.html#api-walk-through
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 created a simple persistent socket connection for our game using TcpClient and NetworkStream. There's no problem connecting, sending messages, and disconnecting normally (quitting app/server shuts down/etc).
However, I'm having some problems where, in certain cases, the client isn't detecting a disconnection from the server. The easiest way I have of testing this is to pull out the network cable on the wifi box, or set the phone to airplane mode, but it's happened in the middle of a game on what should otherwise be a stable wifi.
Going through the docs for NetworkStream etc, it says that the only way to detect a disconnection is to try to write to the socket. Fair enough, except, when I try, the write passes as if nothing is wrong. I can write multiple messages like this, and everything seems fine. It's only when I plug the cable back in that it sees that it's disconnected (all messages are buffered?).
The TcpClient is set to NoDelay, and there's a Flush() called after every write anyway.
What I've tried:
Writing a message to the NetworkStream - no joy
CanWrite, Connected, etc all return true
TcpClient.Client.Poll( 1000, SelectMode.SelectWrite ); - returns true
TcpClient.Client.Poll( 1000, SelectMode.SelectRead ) && TcpClient.Client.Available == 0 - returns true
TcpClient.Client.Receive(buffer, SocketFlags.Peek) == 0 - when connected, blocks for about 10-20s, then returns true. When no server, blocks forever(?)
NetworkStream.Write() - doesn't throw an error
NetworkStream.BeginWrite() - doesn't throw an error (not even when calling EndWrite())
Setting a WriteTimeout - had no effect
Having a specific time where we haven't received a message from the server (normally there's a keep-alive) - I had this, but removed it, as we were getting a lot of false-positives due to lag etc (some clients would see between 10-20s of lag)
So am I doing something wrong here? Is there any way to get the NetworkStream to throw an error (like it should) when writing to a socket that should be disconnected?
I've no problem with a keep-alive (the default case is the server will notify the client that it hasn't received anything in a while, and the client will send a heartbeat), but at the minute, according to the NetworkStream everything's hunky-dory.
It's for a game, so ideally the detection should be quick enough (as the user can still move through the game until they need to make a server call, some of which will block the UI, so the game seems broken).
I'm using Unity, so it's .Net 2.0
is to pull out the network cable on the wifi box
That's a good test. If you do that the remote party is not notified. How could it possibly find out? It can't.
when I try, the write passes as if nothing is wrong
Writes can (and are) buffered. They eventually enter a block hole... No reply comes back. The only way to detect this is a timeout.
So am I doing something wrong here?
You have tried a lot of things but fundamentally you cannot find out about disconnects if no reply comes back telling you that. Use a timeout.
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
i have an application that detects a USB 3G Dongle that will be used for sending SMS. My application queries the Dongle via AT Commands to determine if it is the RIGHT dongle, this means that that certain dongle can only be used in my application (even if the Dongle is of the same model). Sending and receiving is fine, no problems or whatsoever. If the 3G Dongle is removed from the USB port, the system detects this and executes the proper procedures.
Here's my problem. When the 3G Dongle is re-inserted, say on the same port (COM5), my application detects this and executes some AT Command to determine that the re-inserted dongle is the RIGHT dongle. But an error occurs stating:
THE RESOURCE IS IN USE
The application must be terminated or closed to be able to use the same port (say COM5). Then I encountered an application, almost with the same function, but is able to use the dongle when re-inserted.
BTW, my dongle is ZTE MF190, and the application I saw is from Huawei. I am using C#. Is there any work around on this? or better, is there a better logic on this? say using a service, etc..
EDIT:
every query done to the Dongle is done in a separate thread so as to be able to use my application while sending and receiving..
Thanks!
I too had a similar issue with the windows serial port component. There appears to be bugs in the C# code.
Long story short, I managed to get around this by closing the port in a background thread.
Here is my code, note that you may need to modify to fit your application:
private bool ClosePort()
{
_Closing = true;
_SerialPort.DiscardInBuffer();
_SerialPort.DiscardOutBuffer();
if (!_SerialPort.IsOpen) return true;
//We run this in a new thread to avoid issue when opening and closing
//The .NET serial port sucks apparently - and has issues such as hanging and random exceptions
System.Threading.Thread t = new System.Threading.Thread(new System.Threading.ThreadStart(DoClosePort));
t.Start();
//here we wait until is **SHOULD*** be closed - note the better way is to fire an internal event when its finished
//We may need to tinker with this wait time
System.Threading.Thread.Sleep(500);
return _SerialPort.IsOpen;
}
private void DoClosePort()
{
try
{
//System.Threading.Thread.Sleep(500);
_SerialPort.Close();
}
catch (Exception ex)
{
MessageBox.Show("Error closing " + _SerialPort.PortName + ". Error Message: " + ex.Message + "\r\n");
}
}
Note that if you try sending/receiving while you are closing, check the _Closing class variable before you attempt the send.
Hope this helps anyone.