I am working with a Meteor mobile application with Cordova and PhoneGap.
My app is working fine over a Wi-Fi connection. But whenever I use it on mobile networks, 2G or 3G, it stops working. Meteor.status() returns disconnected all time on mobile cellular networks.
What is the solution for this problem?
This could occur if you have a bad connection. The Meteor in the device's browser can't really tell what network it's on. It just uses whatever it gets.
As soon as it can get a connection back it should reconnect. Keep in mind with 2G (EDGE/GPRS) connections you might have to wait a bit longer for the HTML/JavaScript to connect to the DDP server as all the client HTML/JavaScript data needs to be downloaded first. This can take quite a while.
The other thing is to ensure your (3G) connection isn't over some kind of proxy, especially if you're hosting the application yourself on an unusual port number (websockets usually fall back to long polling, though).
Related
Both Android and iOS will route requests through mobile data if WiFi has no internet connection.
I'm trying to route requests to a WiFi device (192.168.1.1 IP), and I hoped that the OS would be smart enough to route internal IP requests through the WiFi (which shares the same submask), but I hoped wrong. Even in this case, mobile data will be used.
Sadly, neither fetch nor RNFetchBlob support anything to indicate where to route the requests through.
On the other hand, I have found some articles (https://android-developers.googleblog.com/2016/07/connecting-your-app-to-wi-fi-device.html) that explain how to do this in Android, but adding a native integration that allows some requests to go through WiFi, while others through Mobile (the app still needs internet for other tasks) seems like a very complicated implementation task, mostly because I would need to re-implement the fetch API with this behaviour. Basically, I would need to implement a full HTTP client and expose it to react.
https://www.npmjs.com/package/react-native-android-wifi
This npm package helped me with this issue forcing to fetch data over wifi instead of mobile network. May be useful for you.
I have two applications that need to communicate with each other running on the same system.
I've been using the very strange practice of opening a TCP COM channel between the two applications for communication.
Is this practice frowned-upon in anyway? Is there any alternative (apart from using stdio, not possible due to other reasons).
Is there a restriction on maximum transfer rate and/or any latency involved (compared to piped stdio)?
I'm using the local (127.0.0.1) address for both server and client, will the connection be guaranteed to stay within the local machine itself or could it relay off the nearest router before coming back to itself and does the network card influence the properties of the connection at all?
I worked on a system a while ago with Java. and I was looking for the same question. I don't have much experience with it. But I ended up using tcp connections for communications for the following advantages:
1) The ability to put the different application in different servers in the future if needed to.
2) The applications are totaly independent. one application could crash without effecting the other one. If the working application then tries to connect it gets an error and you can handle that.
I saw this used in many other type of applications. So I went with it and it is working fine. But you have to be carefull and handle networks errors and IO errors and closing all open sockets after finishing with the connection. I was only closing the socket from the client end so I ended up with many CLOSE_WAIT ports in the server.
Regards,
It's pretty common to use TCP for inter-application communication.
Performance should not be an issue.
Sockets On Same Machine For Windows and Linux
You should consider security. What will happen if another user on the machine connects to the port, how will the application authenticate etc.
I am working on a project that involves triggering actions on various internet connected devices such as phones, computers, home automation devices, etc. What technologies/general actions are available to connect devices like that? From my limited knowledge I can think of constant poling by all the devices, or making use of a prolonged HTTP connection (I believe that is somewhere along the lines of how Facebook does their notifications).
What other options do I have? What frameworks are there out there? Which option is the best when it comes to time from when the server wants to contact the device to when the device is actually contacted? Which option is easiest on the battery life of the devices?
For battery life, there's not much that beats a plain TCP socket connection. If you can do all the device's polling over a single connection, there is very little overhead besides a few bytes every x seconds for a keepalive packet (which you probably should either enable in the TCP stack or generate as a part of your protocol) This is afaik similar to what Apple uses for iOS notifications.
If you're in an environment where socket communication may be blocked by a firewall, I'd go for websockets with a fallback of long polling (which you mentioned in the question). Combined with proxy support, this should be able to traverse just about any firewall without much complication.
I have to devise a push notification plan for some mobile devices where push is not yet officially supported by C2DM / APNS / BES ,etc. MQTT was also a good option but I could not get an MQTT Client for my required platform. (Blackberry Playbook, ActionScript only)
Going back to basics, I had the options of Long Polling and streaming. Streaming using a high keep-alive value seems good to me, as the development of the mobile app (it is not a browser) and the server code are both in my control. To maintain the connection open, I just need to ping the server occasionally.
What issues I may be facing in this approach ? I understand this would constantly open an HTTP connection from the device to the server. Would the battery life of mobile device drain quickly just by persistently opening a server connection ? ...Afterall the data is not being transferred, just by keeping the connection open...right ?
You might want to consider Urban Airship or take a look at this realtime technologies guide.
If realtime really matters, I'm talking about seconds or milliseconds, then a realtime web technology using WebSockets or HTTP Streaming is your best option as they deliver updates the instant they are available. This sort of thing is best suited to the sort of application that a user is actively using during a reasonable period of time where they need instant notifications or are collaborating/chatting with others.
WebSockets are probably a better standard to be using with longer term technology considerations in mind since they are the first standard for full duplex bi-directional communication between a client (mobile, web, desktop) and server.
What platform could you not find an MQTT client for? http://mqtt.org/software lists clients in just about every language I can think of and more than I'd like to bother using. The mosquitto C client library is very portable.
For battery life, it really depends what you're doing between the keepalives...
If you app runs in a country where the network isn't in the best shape, then having all your clients keep a connection open can put strain on their infrastructure (assuming you are that popular).
Battery life is the other consideration, yes, a lot of devices aren't that efficient in keeping an idle radio/3g connection open and it drains the battery a lot faster than not having a connection open.
If you sign up for the RIM developer alliance program, you have the special BIS-B connection type available to your Blackberry applications.
Is this connection type more available, stable, and reliable than the other methods? We're connecting to web APIs, if that makes any difference.
Getting the other methods (Direct TCP through APN gateways, WAP, WAP2, Unite) to work properly in all cases is a bear so I'm hoping BIS-B is a good way to solve this issue for our app and help some customers that have a financial incentive not to connect through WAP connections.
BIS connections have worked pretty well for us. However, some customers (especially the once using Enterprise Servers) have BIS connections disabled and force all traffic through their MDS. So I'd always make sure your application has more then one way to connect to the web. But be careful - when your application tries using MDS connections as well as BIS connections, you might run into a probmel known as 'split-pipe', which is extremly hard to debug.
For security reasons some devices block applications to do both internal and external connections (MDS and BIS), they do this silently (so you're connections just fail) and it's permant as long as the application is on the device. There is a policiy on the BES to activate/deactive this and I havn't seen it always happening, sometimes BIS/MDS works just fine, but keep that in mind.