I have some devices which provide small webserver applications for users to access from their phone or laptop using a browser or thin client. All that the thin client does is a UDP broadcast to find devices on the local network and then connect a browser to the device(s) when found - or notify when no devices are found after a timeout.
Would it be possible to implement this thin client as a webpage served from a known host, so that the users' device wouldn't need any software installed beyond a browser and a link to the known host? The webpage would broadcast some UDP packets and wait for (appropriate) responses from any devices on the local network, if/when device responses are received present a list of devices to connect to, so the user can just select from a list, instead of having to determine the device addresses and type them in for themselves or install and use the thin client.
I can see how this sort of thing might be abused, and therefore made difficult or impossible by browsers, but no more than so many other technologies that are currently wide open for use...
Any help getting started with this kind of solution would be appreciated, thanks!
Unfortunately, this can't be done directly. I think it would be really great if there were some sort of "local peer" API to enable simple WebRTC connections without going through servers, but this doesn't exist.
You do have some options:
Write a browser extensionThis needs to call some native code to shuffle your data around, but it can work.
Deploy a server on the networkThe server can do all the initial connection/negotiation.
Related
We recently implemented the webHID API for one of our sites (it is such a godsend) and have the client asking if they can use the devices over a Microsoft RDP connection?
I imagine this would depend on the RDP client and whether they can/do send HID events over the RDP connection.
From some initial research it looks like you can redirect USB over RDP but don't think this will work for us as I couldn't get my device mapping done with the webUSB API.
If anyone has any input on this it would be greatly appreciated.
Thx
WebUSB, WebHID and Web Serial should work with a remoted USB device.
That said, there may be bugs if these devices don't appear to applications like Chrome in quite the same way they do when connected locally. If they don't, it would be interesting to get logs from chrome://device-log and see how the device appears in the Windows Device Manager.
Please file a bug at https://crbug.com/new and let us know so that we can keep track of this issue.
I want to make an HTML5 game that can be controlled with mobile. So how to communicate between mobile and browser on PC?
I think of the following ways:
Bluetooth This may be the most easy way to use. But I searched and found that Chrome made bluetooth API proposal last year but is now available only on Chrome dev, which means I cannot make the game popular for everyone.
WiFi I don't know how to set up a host on browser using WiFi information. If so, I can then connect my mobile to WiFi. This is considered to be faster than web socket since it's local network.
Web Socket There're a lot of information about how to use this. But as this use WAN, it is considered to be slower and is my last choice.
So, does anyone know how to achieve this with the former 2 ways?
trying to create a program that works as following .video is captured by web cam of laptop and it is streamed to android phone using wifi .According to the video displayed, user types some messages and sents back to laptop simultaneously.
googled and found that making an ad-hoc wireless network will work,but forum
discussions says its not supported by android.want my app to work from 2.2 onwards
Which Socket communication protocol (UDP or TCP) protocol should be used to stream video?
Since want to implement two way communication, which one must be the server (laptop or mobile device)
Please guide me how to implement this
use connectify or any virtual router to get connected to your android phone.so app can be connected with your laptop or desktop.
go for UDP its fast and recover data even if it's lost and also use a proper data streaming strategy or a protocol.
According to your application design , i will recommend you to make your laptop work as a server. Also it would be best if you choose to use threading in both application and recommend your app to act as server or client as it's required shows more robustness..!
So I have been thinking about building quite a complex application. The idea of building an html5 version has become quite an attractive possibility. I have a few questions about it first however.
My first concern is how reliable the offline application API's are at the moment. I have been looking into this standard: http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html and it looks pretty easy to implement and use, but I am wondering how easy it is to use? And assuming you set up the manifest etc, is the web application just accessed (offline) by going to the same url you originally downloaded the application from?
My other concern is the use of sockets. This offline application still needs to be able to communicate with local servers, I ideally wanted to avoid having to host a web-server, a socket connection however would be plausible. How well do websockets currently work when the browser is offline? Is it possible, to have a fully networked / interactive browser application running even without an active internet connection? (after the app is first downloaded)
Any insight would be great!
That's a lot of questions, you may want to consider breaking it up into more easily answerable portions more directly related to what, exactly, you're trying to achieve. In the meantime I'll try to provide a short answer to each of your questions:
My first concern is how reliable the offline application API's are at
the moment.
Fairly reliable, they have been implemented for a number of versions across most major web browsers (except IE).
is the web application just accessed (offline) by going to the same
url you originally downloaded the application from?
Yes. Once the offline app has been cached, the application is served from that cache. No network requests will be made unless you explicitly request URLs from the NETWORK or FALLBACK sections of the manifest or aren't covered by the manifest at all, apart from to check whether the manifest itself has changed.
This offline application still needs to be able to communicate with
local servers, I ideally wanted to avoid having to host a web-server,
a socket connection however would be plausible.
A Web Socket still requires a web server. The initial handshake for a Web Socket is over HTTP. A Web Socket is not the same thing as a socket in TCP/IP.
How well do websockets currently work when the browser is offline?
They won't work at all, when you've set a browser to offline mode it won't make any network requests at all. Note that a browser being set to offline is not the same thing as the offline in 'offline API'. The offline API is primarily concerned with whether or not the server hosting the application can be reached, not whether the the browser is currently connected to a network or whether that network is connected to the internet. If the server goes down then the app is just as 'offline' as if the network cable on the user's computer got unplugged. Have a read through this blog post, in particular the comments. My usual approach to detecting offline status is to set up a pair of files in the FALLBACK section such that you get one when online and the other when offline - request that file with AJAX and see what you get.
Is it possible, to have a fully networked / interactive browser
application running even without an active internet connection?
Yes, but I don't think that means what you think it does. Separate instances of the app running on different browsers on different machines would not be able to communicate with each other without going via the web server. However, there's no requirement that the web server be 'on the internet', it will do just fine sitting on the local network.
Is it possible ?
Peer-To-Peer connection via WiFi (same Access Point) , how would multiple devices talk on this layer.
Any API available or sources that can be looked into ?
Thanks
Yogurt
The Wi-Fi Alliance on Monday announced that its direct peer-to-peer networking version of WiFi, called WiFi Direct, is now available on several new WiFi devices. The Alliance is also announcing that it has begun the process of certifying devices for WiFi Direct compatibility.
Try researching the state of Bonjour / Avahi / Zeroconf on android. I'm seeing some pages that indicate people have made some progress for certain purposes but nothing like a generic howto or ready to use library.
Unless you know the IP address assigned to the other peer already, you'd have to somehow have devices inform other devices that they exist.
Are these devices definitely going to be on the same subnet? If so you can try messing around with having the devices send out 'broadcast' packets. I have no idea if the Android API lets actual applications receive these though.
The more reliable approach would probably be to run some centralised server somewhere that devices register with when they go online, and give their IP address when they register. Then they can query that server for which other devices are nearby and what their IP addresses are. If this is to be a central server out on the wider internet, then it means that unfortunately that the device discovery part isn't peer to peer - there is some privacy implication. Another thing if this is a central server is that you'll have to design the querying process to cope with NAT so that querying for other devices on your local network is restricted to the right network, but that you also get their IP address.