peer to peer communication between mobile app and pc browser - javascript

I am working on a project where i need my mobile application to talk to my web browser on a pc, where both devices are connected over wifi. The app would send data which would be received by the computer browser followed by some client side code execution. The browser then may send some feedback.
My initial approach is to make the app talk to an endpoint which in turn talks to client side of the browser (javascript).
What could be the best approach to do this ?
Update
I am not sure if Socket.io is a possible solution since it requires a server to be hosted. Is it possible to solve this using sockets ?

You've now edited your question to mention P2P. That's quite hard to achieve PHONE TO BROWSER (i.e., by hard I mean 6 to 12 man-months of work - and/or plain not possible). However in MOST situations you can instantly (ie "one line of code on each platform") resolve the problem by using a service like pubnub. Much as nobody has back-ends anymore and everything is just done with parse.com or game center, networking like you mention is now just done with pubunb (or any competitor).
This is an extremely common use case problem - and everyone just uses PubNub as mentioned below or one of its competitors.
These days it couldn't be easier, just use pubnub.com
It's the world's biggest data-messaging service for a reason!
There's essentially no other realistic approach, it's so simple - a few lines of code.

So short answer would be: A real peer-to-peer (P2P) communication is currently not possible with all browsers. So instead you have the following options:
App + Server with a WebUI (maybe)
App + Chrome App (Chrome Apps can start an web server, see http://www.devworx.in/news/misc/chrome-apps-can-now-run-a-web-server-135711.html)
App + WebApp with Plugin (Flash, Silverlight or Java)
I personally would prefer solution 1.

You need a server. If you consider this problem strictly from the typical firewall point of view, a PC or a mobile device are going to ignore connections unless they initiate the connection themselves. So neither the PC nor the mobile device can start a connection with the other.
My understanding is that web browsers do not support standard sockets within javascript. You can use the analagous websocket, but sockets and websockets are not directly compatible.
You can setup a simple server on the PC, and have this server relay messages between the mobile device and the PC browser. Both the mobile device and the PC browser connect to the server. This is basically what an external service will do for you.

PeerJS is what you're looking for:
http://peerjs.com

Related

How to make a Command Line application with WebRTC in Linux?

I have an idea for a side project where i will connect two terminals(clients) using WebRTC and they will share some data with each other(assume a CLI chat app) using Node.js. But wherever i read about WebRTC it always says that it works only in browsers. Like the fact that if a machine does not have a browser that supports WebRTC then it would not work in the machine. Do statements like these mean that WebRTC can only work in the browser. If not then how should i approach making something like this?
The functions i want the application to have :-
1.) It should connect with the peer when i write "node client.js" in the terminal (client.js will be the client script).
2.) The terminals should be able to send each other messages.
3.) No need of the browser.
I've made such applications using WebSockets and i dont intend to use them in this project.
Yea this is possible, and people are doing it today!
Check out ascii it is a command line WebRTC client that does camera capture and encoding. It uses the Golang library pion/webrtc
I am sure it is possible with nodejs as well, but don't know how much work it would be.
Also if you are doing chat only it is even easier! See pion-to-pion really easy example to have two processes communicate via WebRTC.

VNC server and vnc browser client

I am looking to add vnc connectivity into a web application to view VM thats are on a server. I have investigated a few projects such as no-vnc and angular-noVNC for the front end frameworks. These look quite simple and easy to implement but i am concerned around the backends and how to implement. Now from what i can see people tend to be using websockify to convert the traffic over to websockets for the browser to handle.
My current arch is windows servers with Vmware hosting the Virtual machines. VNC is out of the box with VMware and i would like to make use of it to view the virtual machines
Can anyone point in the right direction to achieve a suitable backend system to allow my angular front end to connect into. I would prefer it to be open source but would consider a commercial bit of software.
I don't mind what the backend technology is used but would prefer Node or Asp.net.
many thanks
I have found a solution and opted for guacamole server, running on ubuntu server.
The also have client which is built in Js and hence should be fairly straight forward to implement in angular.
All information can be found : - https://guacamole.incubator.apache.org/
Also found that this script was helpful to get install - Tested and confirmed working on Ubunutu 16.04
https://www.chasewright.com/guacamole-with-mysql-on-ubuntu/
Now just need to figure out how to connect different clients with different settings, but i expect it will be fairly straight forward.
Thanks

How to detect a server in the network using JS?

Basically, I want to make a peer to peer architecture, using JavaScript (Ionic).
Since, JS cannot create sockets/etc; a NodeJS server has to be introduced between the clients; acting as the Socket.IO server between the clients.
The problem with this, is that the Socket.IO (NodeJS) server would need to be automatically found within the local network -- by the clients (instead of hardcoded/configured).
Are there any ways to implement such a thing; or alternatives to this architecture?
Thanks for the help!
Are there any ways to implement such a thing; or alternatives to this architecture?
Currently your architecture is using a browser app plus a Node app that users need to have on their network just to create TCP connections.
What you can do instead is create an Electron app that combines a Node app, a browser app, and a browser itself. See:
https://electron.atom.io/
With Electron you can write your frontend code almost the same way as for the regular browser, but you can use the entire Node API including the TCP sockets so there will be no need to create a separate Node app and to search for that app in the network. This can greatly simplify your architecture.
Note: this is not an answer to the first part of the question: "How to detect a server in the network using JS?" but to the second part of the question: "Are there any ways to implement such a thing; or alternatives to this architecture?" Detecting the servers on the local network with client-side JavaScript will not be easy - and in fact it shouldn't be even possible because websites being able to scan your LAN for active services would be a serious problem for privacy and security.

Server sent event vs web sockets?

I'm working on a web app that is accessible to users via multiple platforms from smartphones to desktops which needs to sometimes make a communication between two clients for example if I want my friend to join my network I'd send him a friend request but I want that request to be seen by my friend without him having to refresh the page.
In this scenario which would be a better choice?
And also since I want this to work on as many platforms and browsers as possible which has more browser support?
Is there a better option?
Some things to keep in mind when making this choice.
Attempting to fetch content over a WebSocket connection is a poor
design decision because WebSockets is a different protocol nested
inside an HTTP connection and it can't leverage caching (neither the
browsers nor CDNs).
Some older proxies won't pass on a Websocket connection unless its hidden within a secure connection while Server
Sent Events remains an HTTP connection and won't suffer from
this.
Neither WebSockets nor SSE are supported in the native Android
browser until 4.4 (when they switched to using Chrome) - thus if
you're considering a hybrid mobile app, you will need a fallback such
as SocketIO since, as of this writing, 4.4 is only 20% of the market
and hybrid apps use the native Android browser.
WebSockets is the
most battery efficient protocol for mobile devices, since all other
options require many HTTP connections and it is the repeated
negotiating of the headers that will burden the cpu and drain the
battery.
Another option may be notifications. All mobile devices now support notifications that can be targeted to an App and a number of browsers have as well. In all cases a connection already exists from the client to the messaging center (Apple, Google, Microsoft, etc) and all notifications are sent over this channel.
Here's a good overview of WebSockets vs. SSE:
http://www.html5rocks.com/en/tutorials/eventsource/basics/
Server Sent Events: A persistent connection server-2-client only, for sending text messages and that is implemented in all major browsers, but Internet Explorer. It can reconnect itself if connectivity is lost. http://caniuse.com/eventsource
WebSokets: A full duplex persistent connection capable of transmitting UTF8 text and binary data. http://caniuse.com/websockets
WebSocket is better, and the future.
From what I understand, SSEs are simpler and easier to implement, whereas WebSockets offer bi-directional data transfer but are their own protocol/API you need to understand to take advantage of. Honestly I've never really bothered with SSEs, Socket.IO does all I've needed as far as real time web app communication fairly easily and is built to be cross-browser.
If you just want him to be able to see a notification, then SSEs should be fine. If you want him to be able to reply to your friend request from the same page, then have the server send you a notification that he's accepted, you'll probably want to use a WebSockets implementation.

Help with android to chrome communication

I have been working on creating an application that sends a string from an android phone to a server and from there sending it to a Chrome extension. I am sitting with a few options to continue, I can convert everything to websockets, I can use normal sockets for android to computer and websockets for extension to server, or I can do some HTTPRequest stuff.
I am looking for suggestions on the best way to pull off this communication. I have a php server an android application and a chrome extension that need to be connected. If there is a way to connect the android application to the chrome extension without the server I would be happy to hear that too.
I need something secure and something that can be organized based on the correct person asking or sending information. So when someone sends a string from the android application the server stores it (probably using their gmail) and when the extension asks for it the server sends it along.
Also could the server just push the string to the extension without the extension calling it? This would occur after the initial websocket connection. I guess it would just store the IP address or something like that.
Any suggestions or comments would be appreciated I am just trying to make the most efficient and secure system I can come up with. I have done a significant amount of research about every aspect so I'm more suffering from information overload then anything.
Thanks in advance :]
Look into Windows Communication Foundation Services (WCF). That's what I have been using for my android applications working with a database - the .NET framework is great, and the services seem to be fairly dynamic.
http://msdn.microsoft.com/en-us/netframework/aa663324

Categories

Resources