How can an interprocess communication be estabilished between a browser extension and a native application? Is there any cross-platform (Linux and Mac OS X) and cross-browser solution (Firefox, Chrome, Safari)?
The only idea that comes to my mind is using native Web technologies, i.e. embed a HTTP server in native application and use XmlHttpRequest or WebSockets. However, this sounds like clunky overkill with handful of issues (e.g. security). Is there a better alternative?
I believe the most commonly used method is websocket connections. Two examples I can think of are 1Password and LiveReload (source code available).
As far as I know, you need to open the websocket connection from within your global page to avoid cross-domain restrictions.
Also, in the past I have seen other apps watch and modify an extension's settings file. The extension just reads and writes from it's own settings store, while the other process watches the preferences file for changes. I believe this is less reliable and doesn't conform to sandboxing requirements for the Mac App Store so I would recommend the websockets method.
Related
There question about this before, the answer is no. But now, with browserify/webpack, can I just write code like I would on server and it will run in browser, or is there any restriction that would make this impossible?
No, you cannot. Starting a server in a browser requires access to low level functionality that simply to does not exist in a browser. Browserify cannot add fundamental low-level features to the browser that it does not have that would require additional native code support in order to make work.
Browserify can only package code that is either pure Javascript or is built on top of infrastructure that already exists in the browser or can be simulated with some pure javascript built on top of the features that do exist in the browser.
So, for example, you could take a crypto hash library from node.js that is pure javascript and does not rely on any capabilities that are not present in a browser and you could browserify it (e.g. repackage it) to use it in a browser. But, you could not take a node.js package that uses low-level UDP communication because the underlying access to UDP is not present in a browser.
In general, if the node.js code does I/O or manipulates other processes or uses any module that has native code, it will likely not work with browserify (there are a few work-arounds with some file I/O).
For additional info, see:
Does Browserify have any limitations?
Browserify Compatibility
So you don't say what your actual problem is that you're trying to solve, but usually you would start an actual server somewhere and have the browser connect to that server. If you wanted one particular browser session to appear to be the "master", you could certainly make your client/server behave that way. One client could be the master (appearing to essentially be the server itself) to other clients that connected to that same server. This would all be done by how you programmed your server and how it communicated with the various clients that connect to it. Actual servers can be made to be proxies for other clients where the client gets access to server-like functionality via the proxied connection to an actual server.
I have built a multiplayer game with real time leader board. The game is in PHP(Backend) + Flex(Front end).
I have used socket.io for real time communication with a node.js server. But I am facing a lot of problem with respect to proxy settings on my client network configuration. Most of the time my application doesn't communicate with my node(socket) server. It is not able to establish a connection because of proxy configurations.
What alternatives can I go with? I tried to search a lot for alternatives. I came across services like pusher and pubnub, but those are little expensive. Have anyone tried Amazon SNS, is it suitable for this?
Thanks!
The reason that you cannot connect through proxies, is because socket.io is using web sockets. See Socket.io and firewall Software (that page also includes a link to test websocket connectivity). There are a number of ways you can mitigate this problem:
Use secure websockets (wss://)
But this does also not guarantee for 100% that it will work.
Use one of the fallback mechanisms of socket.io: Flash, Ajax, iFrame, JSONP, ...
For more information, see Configuring Socket.io.
There is SocketCluster: https://github.com/topcloud/socketcluster
It runs on multiple CPU cores and it's good with error-handling (workers auto-respawn). It has no identified memory leaks (just make sure you use latest version of Node.js).
How can I send low latency data to a server and back with phonegap?
Considering I don't have access to php files locally, and don't have experience with node.js or WebSockets I don't know which ones I should use.
WebSockets aren't natively supported by the browsers in Android or older versions of Cordova under iOS, which means you'll need to use a PhoneGap plugin if you want to use them on the client.
There's more information at: http://remysharp.com/2010/10/04/websockets-in-phonegap-projects/
However, I'm not sure (even with the plugin) how resilient WebSockets are likely to be when the device moves between network connections (WiFi -> 3G -> WiFi), so using a simple polling web service may be a more reliable option if your app needs to continue receiving data as your users move around.
If you need to receive data initiated by the server, consider using push notifications instead: both iOS (APN) and Android (C2DM) provide APIs to do this which make more efficient use of the battery than having your app poll your server constantly.
You can use WebSockets in PhoneGap with iOS and Android. WebSockets are natively supported on iOS within Safari. For Android you will need to use a polyfill.
See: https://stackoverflow.com/a/13527585/39904
The answer above provides information about how to make a WebSocket object available within the Android WebView used by PhoneGap and also provides a link to a sample project which you can use to get started.
WebSockets were developed as a solution to 'Comet' hacks. As such they provide a very low latency solution for realtime bi-directional communication between a client and server. This means low bandwidth and low resource usage - battery on mobile - since you are holding a single connection open rather then opening and closing multiple HTTP connections. A polling solution which makes requests at regular intervals is likely to drain the battery much faster than a WebSocket solution. If you are polling at lower intervals then it may be fine - it depends on your use case.
In terms of WebSockets working as you change between network and network type (WiFi -> 3G -> WiFi) then if you are using WebSockets natively you need to detect the onclose and reconnect. You will also need to determine the best type of connection; unsecure (WS) or secure (WSS). I would highly recommend you use WSS for mobile since some mobile network providers use transparent proxies which interfere with WS connections. This might sound complicated but there are a number of libraries that handle this for you. Such as the Pusher JavaScript library (note: I work for Pusher). Libraries such as these also provide fallback to a less efficient HTTP-based solution when the environment will not let any WebSocket connection occur.
Also see: realtime web technology guide.
I'd agree with #rmc47 that you should consider native push notifications if it's for infrequent single notifications
Refer to this link to see WebSocket Support by Browsers and devices : html5test.com site - iOS 4.2+ already supports WebSocket
See this doc that explains how to develop a simple application with WebSocket.
Unfortunately the content is in the Portuguese (Brazilian) language but you can leave comments which I will answer.
I'm not sure what you mean by "access to PHP files locally". The use of node.js and web sockets is also not mutually exclusive.
If you have not made a decision on the server implementation you could go for either node.js or ASP.NET.
node.js has good support for sockets with Socket.io, which abstracts the client implementation for you. So it will use WebSockets if there is support, else it will fall back to long polling.
ASP.NET has a library called SignalR which does something similar for the .NET platform.
I have a client-server relationship between two apps: a web application and an OCX. What I want to do is communicate the client part of the web application, running on the local PC, with the OCX, also installed in the same PC. The server app (the OCX) is not mine (I can't change its source code) and offers 2 ways of communicating with client apps: through an intermediate file or through a socket. There are lot of restrictions in the PCs where the apps have to be executed (the users, for example, are not administrators of their own PCs) so it's even more difficult than it seems. My doubt is which technology would be better to handle this communication from the cliente app (JavaScript, Java Applets, another OCX, etc.) and which option could be handled easier (file or sockets) by this technologies. And also which would be the security and permissions settings that should be taken into account to make it all work properly. You must know that, in case of using an intermediate file, I must be able to write in specific positions of that file from the web app (I'm not sure if Javascript's FileSystemObject can do this, for example). Thanks in advance.
Working with Sockets is realy easy. I only don't know the security options of sockets. May be you can take a look here: Oracle Sockets
I'm trying to connect a browser extension (Firefox, Chrome, IE...) with an external application. Using a non-polling system to notify the messages between the components.
I've already seen several approaches, but I'm not sure which ones are possible and which ones are the best.
One solution could be trying to use a IPC (Os-dependant) solution, as named pipes or sockets, but I'm not sure if I can open a named pipe in a firefox or chrome extension. Moreover, I don't know if there are any "event based" system not to need polling as a mechanism for handling the communication.
The other solution (only if I use firefox) is to use XPCOM, I think with this approach, I should instantiate a XPCOM component, implemented in the browser extension, from the External Application. I think should need the XPCOM thing as a dependency in my External Application, right?
But, using this method, is it possible to handle the communication in a asynchronous way?
Thanks in advance ;)