Develop Reference

Communicate with devices on local network using client-side Javascript

I'm trying to build a website that allows you to transfer files to devices connected on your local network. This website is static, and will be hosted on GitHub pages.
Is it possible to use Javascript to communicate with (i.e. transfer files/text) other devices on the local network? The IP addresses of the devices are already known and I'm looking for a peer-to-peer connection here.
Note: As this website is static, there is no server side code that can be controlled.
Thanks

Yes, it's possible with caveats, depending on the specifics of your situation.
WebRTC
With WebRTC, you can establish a real peer-to-peer connection between two clients on a network. They can send data (binary or strings), and media streams (like webcams and microphones). This can even work from a static page.
The catch is that you need some sort of server to help coordinate the connection. Because of the way the WebRTC standard was originally set up, there is some back-and-forth that must occur to set up that peer-to-peer connection. Some method of communicating the signalling between the clients must exist, and this is usually done via web sockets and an intermediary server.
There are some novel alternatives.
In the future, ORTC may solve this issue, allowing a one-shot method for setting up the call, making the server-side requirements easier.
Embedded HTTP Server
You didn't elaborate on the specifics of what device you want to communicate with on your network, so maybe this is a possibility as well. There's nothing stopping your browser from communicating with devices on your LAN. Your static web page can use the Fetch API or AJAX to retrieve data from devices.

setInterval($.get or socket.io? [duplicate]

I am developing a web app and I was wondering which method should be suitable for my project.
Basically what I want to display to the users are some notifications which are taken from requests to other servers. My node.js app gets all the info and then it spread out to the users, saving a copy into my MongoDB.
The idea is quite simple but reading about methods I found these two techniques:
Ajax : Client side would be checking all time if there is new content on the server. This would be done by using a jquery ajax get to my server API (every 30/60 seconds).
Socket.io : The client connects once, and then a permanent TCP connection is maintained (more realtime).
Now I have explained the situation, I have the following questions :
Would I not have too many requests with ajax ? imagine I want a check every minute to the server, if we scale the app to 100 users, it will give me 100 queries per minute. Would it be "cheaper" in system resources to have a socket ?
Would the socket.io be a problem for mobile devices ? bandwith and performance. The response of the server is always info in JSON format.
I read that now.js could be used for this but it seems the project is no longer supported, so not sure if using it would be a good idea.
How is the caching on both methods ? I was considering to create a cache file for each user and this would be updated by the node.js in the server side. I guess this could work really well with ajax but what about socket.io ?
Is it true that socket.io is not compatible at all with many browsers ? My app would be more focused to mobile devices and I think this could make me think about choosing ajax instead.
Any alternative suggested ?
I hope this could clear my mind and others who are in the same situation :)
Thanks

Many of the generic tradeoffs between webSocket and Ajax are discussed here:
websocket vs rest API for real time data?
Some tradeoff issues for mobile devices are discussed here:
Cordova: Sockets, PushNotifications, or repeatedly polling server?
In a nutshell, if your data is primarily server-driven and then needs to be sent out to clients and you desire fairly good latency for when the clients see the new data, then that is the exact problem that webSockets are good for. webSockets work best in this situation because the client does not need to poll frequently, the server does not need to handle regular polling requests from lots of clients. Instead, each client just sets up the one persistent webSocket communication channel which the server can then send data down upon demand at any time.
Would I not have too many requests with ajax ? imagine I want a check
every minute to the server, if we scale the app to 100 users, it will
give me 100 queries per minute. Would it be "cheaper" in system
resources to have a socket ?
Sockets require very little resources when they are not active so yes, a peristent webSocket is more efficient than lots of clients polling endlessly. This is why webSockets were invented because they are better at solving this particular problem.
Would the socket.io be a problem for mobile devices ? bandwith and
performance. The response of the server is always info in JSON format.
socket.io is not a problem for bandwidth or performance. There are some mobile issues with trying to use webSockets in the background because mobile devices are also trying to do active power management, though a similar issue exists with client polling too.
How is the caching on both methods ? I was considering to create a
cache file for each user and this would be updated by the node.js in
the server side. I guess this could work really well with ajax but
what about socket.io ?
It is unclear what you are asking about caching? In a webSocket implementation, the server gets the data and then just sends it to each user. No server-side caching would generally be needed. In a client Ajax polling implementation, the server would have to store the data somewhere and "wait" for each client to then request the data. There is no "built-in" caching mechanism for either webSocket or Ajax.
Is it true that socket.io is not compatible at all with many browsers
? My app would be more focused to mobile devices and I think this
could make me think about choosing ajax instead.
socket.io is fully compatible with all browsers that have webSockets which is pretty much everything in use today except for IE9 and older. If you use the socket.io library, it will automatically fall back to long polling if webSockets don't exist. Your mobile issues are likely going to be similar whether you're doing regular polling or webSocket because the mobile device wants to power manage long running things, but you don't want to stop polling. I don't think this is a reason to avoid webSockets/socket.io. socket.io has some really nice auto-reconnect logic whenever it loses the connection which can be really useful.
In the mobile world, I think you're just going to find that you can't reliably do real-time notifications in the background without using some sort of native app component that can plug into the native "push" system on the device because that's the only system that is both battery efficient and fully compatible with power management. A web page is going to be power managed as soon as it is not the foreground task or when the device has been idle.

peer to peer communication between mobile app and pc browser

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

WebSocket and SSE working difference in html5 [duplicate]

Both WebSockets and Server-Sent Events are capable of pushing data to browsers. To me they seem to be competing technologies. What is the difference between them? When would you choose one over the other?

Websockets and SSE (Server Sent Events) are both capable of pushing data to browsers, however they are not competing technologies.
Websockets connections can both send data to the browser and receive data from the browser. A good example of an application that could use websockets is a chat application.
SSE connections can only push data to the browser. Online stock quotes, or twitters updating timeline or feed are good examples of an application that could benefit from SSE.
In practice since everything that can be done with SSE can also be done with Websockets, Websockets is getting a lot more attention and love, and many more browsers support Websockets than SSE.
However, it can be overkill for some types of application, and the backend could be easier to implement with a protocol such as SSE.
Furthermore SSE can be polyfilled into older browsers that do not support it natively using just JavaScript. Some implementations of SSE polyfills can be found on the Modernizr github page.
Gotchas:
SSE suffers from a limitation to the maximum number of open connections, which can be specially painful when opening various tabs as the limit is per browser and set to a very low number (6). The issue has been marked as "Won't fix" in Chrome and Firefox. This limit is per browser + domain, so that means that you can open 6 SSE connections across all of the tabs to www.example1.com and another 6 SSE connections to www.example2.com (thanks Phate).
Only WS can transmit both binary data and UTF-8, SSE is limited to UTF-8. (Thanks to Chado Nihi).
Some enterprise firewalls with packet inspection have trouble dealing with WebSockets (Sophos XG Firewall, WatchGuard, McAfee Web Gateway).
HTML5Rocks has some good information on SSE. From that page:
Server-Sent Events vs. WebSockets
Why would you choose Server-Sent Events over WebSockets? Good question.
One reason SSEs have been kept in the shadow is because later APIs like WebSockets provide a richer protocol to perform bi-directional, full-duplex communication. Having a two-way channel is more attractive for things like games, messaging apps, and for cases where you need near real-time updates in both directions. However, in some scenarios data doesn't need to be sent from the client. You simply need updates from some server action. A few examples would be friends' status updates, stock tickers, news feeds, or other automated data push mechanisms (e.g. updating a client-side Web SQL Database or IndexedDB object store). If you'll need to send data to a server, XMLHttpRequest is always a friend.
SSEs are sent over traditional HTTP. That means they do not require a special protocol or server implementation to get working. WebSockets on the other hand, require full-duplex connections and new Web Socket servers to handle the protocol. In addition, Server-Sent Events have a variety of features that WebSockets lack by design such as automatic reconnection, event IDs, and the ability to send arbitrary events.
TLDR summary:
Advantages of SSE over Websockets:
Transported over simple HTTP instead of a custom protocol
Can be poly-filled with javascript to "backport" SSE to browsers that do not support it yet.
Built in support for re-connection and event-id
Simpler protocol
No trouble with corporate firewalls doing packet inspection
Advantages of Websockets over SSE:
Real time, two directional communication.
Native support in more browsers
Ideal use cases of SSE:
Stock ticker streaming
twitter feed updating
Notifications to browser
SSE gotchas:
No binary support
Maximum open connections limit

According to caniuse.com:
98.35% of global users natively support WebSockets
98.03% of global users natively support Server-sent events
You can use a client-only polyfill to extend support of SSE to many other browsers. This is less likely with WebSockets. Some EventSource polyfills:
EventSource by Remy Sharp with no other library dependencies (IE7+)
jQuery.EventSource by Rick Waldron
EventSource by Yaffle (replaces native implementation, normalising behaviour across browsers)
If you need to support all the browsers, consider using a library like web-socket-js, SignalR or socket.io which support multiple transports such as WebSockets, SSE, Forever Frame and AJAX long polling. These often require modifications to the server side as well.
Learn more about SSE from:
HTML5 Rocks article
The W3C spec (published version, editor's draft)
Learn more about WebSockets from:
HTML5 Rocks article
The W3C spec (published version, editor's draft)
Other differences:
WebSockets supports arbitrary binary data, SSE only uses UTF-8

Websocket VS SSE
Web Sockets - It is a protocol which provides a full-duplex communication channel over a single TCP connection.
For instance a two-way communication between the Server and Browser
Since the protocol is more complicated, the server and the browser has to rely on library of websocket
which is socket.io
Example - Online chat application.
SSE(Server-Sent Event) -
In case of server sent event the communication is carried out from server to browser only and browser cannot send any data to the server. This kind of communication is mainly used
when the need is only to show the updated data, then the server sends the message whenever the data gets updated.
For instance a one-way communication between the Server to Browser.
This protocol is less complicated, so no need to rely on the external library JAVASCRIPT itself provides the EventSource interface to receive the server sent messages.
Example - Online stock quotes or cricket score website.

Opera, Chrome, Safari supports SSE,
Chrome, Safari supports SSE inside of SharedWorker
Firefox supports XMLHttpRequest readyState interactive, so we can make EventSource polyfil for Firefox

One thing to note:
I have had issues with websockets and corporate firewalls. (Using HTTPS helps but not always.)
See https://github.com/LearnBoost/socket.io/wiki/Socket.IO-and-firewall-software
https://github.com/sockjs/sockjs-client/issues/94
I assume there aren't as many issues with Server-Sent Events. But I don't know.
That said, WebSockets are tons of fun. I have a little web game that uses websockets (via Socket.IO) (http://minibman.com)

they are different in semantics.
websocket has a native semantic meaning of "bidirectional data stream".
while sse has a native semantic meaning of "publish-subscribe pattern" or "request-respond pattern, despite the response is a stream".
of course you can implement a layer of "pub-sub pattern" or "req-res pattern" over websocket by yourself.

In 2023 the situation is not quite as it used to be.
Years ago, when IE still had a significant market share, one downside of SSE was the total lack of native support by IE (whereas WebSockets was supported by IE 10+). Nowadays, according to caniuse.com, both technologies are supported almost equally well on the client side: 98.35% for WebSockets vs 98.03% for SSE (those stats are for global users).
Historically, one severe limitation of SSE, the 6-connections-per-domain limit (a problem when yourapp.com is opened in many browser tabs) is not an issue anymore with HTTP/2. All modern browsers support HTTP/2 (97.16% of global users) and on the server-side HTTP/2+ has also surpassed HTTP/1 the last couple of years.
Various things need to be considered when chosing between SSE and WebSockets:
SSE is generally simpler to implement and easier to test/debug (a simple curl could be used).
WebSockets support bidirectional (full-duplex) communication. That said, SSE could be used in conjunction with AJAX if bidirectional communication is needed. WebSockets are often said to be the simpler option in those cases, but I think such generalizations can be misleading, as it largely depends on the type of application, how it's designed and the technologies used.
SSE supports UTF-8 text messages only, whereas WebSockets can also transmit binary data.
From a practical standpoint, I'd also recommend to research how well your application server supports each of those technologies. Note that some rely on additional modules and/or libraries. You might want to look at some examples and maybe build a quick PoC.

My Understanding of HTTP Polling, Long Polling, HTTP Streaming and WebSockets

I have read many posts on SO and the web regarding the keywords in my question title and learned a lot from them. Some of the questions I read are related to specific implementation challenges while others focus on general concepts. I just want to make sure I understood all of the concepts and the reasoning why technology X was invented over technology Y and so on. So here goes:
Http Polling: Basically AJAX, using XmlHttpRequest.
Http Long Polling: AJAX but the server holds on to the response unless the server has an update, as soon as the server has an update, it sends it and then the client can send another request. Disadvantage is the additional header data that needs to be sent back and forth causing additional overhead.
Http Streaming: Similar to long polling but the server responds with a header with "Transfer Encoding: chunked" and hence we do not need to initiate a new request every time the server sends some data (and hence save the additional header overhead). The drawback here is that we have to "understand" and figure out the structure of the data to distinguish between multiple chunks sent by the server.
Java Applet, Flash, Silverlight: They provide the ability to connect to socket servers over tcp/ip but since they are plugins, developers don't want to depend on them.
WebSockets: they are the new API which tries to address the short comings of above methods in the following manner:
The only advantage of WebSockets over plugins like Java Applets, Flash or Silverlight is that WebSockets are natively built into browsers and does not rely on plugins.
The only advantage of WebSockets over http streaming is that you don't have to make an effort to "understand" and parse the data received.
The only advantage of WebSockets over Long Polling is that of elimination of extra headers size & opening and closing of socket connection for request.
Are there any other significant differences that I am missing? I'm sorry if I am re-asking or combining many of the questions already on SO into a single question, but I just want to make perfect sense out of all the info that is out there on SO and the web regarding these concepts.
Thanks!

There are more differences than the ones you have identified.
Duplex/directional:
Uni-directional: HTTP poll, long poll, streaming.
Bi-direcitonal: WebSockets, plugin networking
In order of increasing latency (approximate):
WebSockets
Plugin networking
HTTP streaming
HTTP long-poll
HTTP polling
CORS (cross-origin support):
WebSockets: yes
Plugin networking: Flash via policy request (not sure about others)
HTTP * (some recent support)
Native binary data (typed arrays, blobs):
WebSockets: yes
Plugin networking: not with Flash (requires URL encoding across ExternalInterface)
HTTP *: recent proposal to enable binary type support
Bandwidth in decreasing efficiency:
Plugin networking: Flash sockets are raw except for initial policy request
WebSockets: connection setup handshake and a few bytes per frame
HTTP streaming (re-use of server connection)
HTTP long-poll: connection for every message
HTTP poll: connection for every message + no data messages
Mobile device support:
WebSocket: iOS 4.2 and up. Some Android via Flash emulation or using Firefox for Android or Google Chrome for Android which both provide native WebSocket support.
Plugin networking: some Android. Not on iOS
HTTP *: mostly yes
Javascript usage complexity (from simplest to most complicated). Admittedly complexity measures are somewhat subjective.
WebSockets
HTTP poll
Plugin networking
HTTP long poll, streaming
Also note that there is a W3C proposal for standardizing HTTP streaming called Server-Sent Events. It is currently fairly early in it's evolution and is designed to provide a standard Javascript API with comparable simplicity to WebSockets.

Some great answers from others that cover a lot of ground. Here's a little bit extra.
The only advantage of WebSockets over plugins like Java Applets, Flash or Silverlight is that WebSockets are natively built into browsers and does not rely on plugins.
If by this you mean that you can use Java Applets, Flash, or Silverlight to establish a socket connection, then yes, that is possible. However you don't see that deployed in the real world too often because of the restrictions.
For example, intermediaries can and do shutdown that traffic. The WebSocket standard was designed to be compatible with existing HTTP infrastructure and so is far less prone to being interfered with by intermediaries like firewalls and proxies.
Moreover, WebSocket can use port 80 and 443 without requiring dedicated ports, again thanks to the protocol design to be as compatible as possible with existing HTTP infrastructure.
Those socket alternatives (Java, Flash, and Silverlight) are difficult to use securely in a cross-origin architecture. Thus people often attempting to use them cross-origin will tolerate the insecurities rather than go to the effort of doing it securely.
They can also require additional "non-standard" ports to be opened (something administrators are loathe to do) or policy files that need to be managed.
In short, using Java, Flash, or Silverlight for socket connectivity is problematic enough that you don't see it deployed in serious architectures too often. Flash and Java have had this capability for probably at least 10 years, and yet it's not prevalent.
The WebSocket standard was able to start with a fresh approach, bearing those restrictions in mind, and hopefully having learned some lessons from them.
Some WebSocket implementations use Flash (or possibly Silverlight and/or Java) as their fallback when WebSocket connectivity cannot be established (such as when running in an old browser or when an intermediary interferes).
While some kind of fallback strategy for those situations is smart, even necessary, most of those that use Flash et al will suffer from the drawbacks described above. It doesn't have to be that way -- there are workarounds to achieve secure cross-origin capable connections using Flash, Silverlight, etc -- but most implementations won't do that because it's not easy.
For example, if you rely on WebSocket for a cross-origin connection, that will work fine. But if you then run in an old browser or a firewall/proxy interfered and rely on Flash, say, as your fallback, you will find it difficult to do that same cross-origin connection. Unless you don't care about security, of course.
That means it's difficult have a single unified architecture that works for native and non-native connections, unless you're prepared to put in quite a bit of work or go with a framework that has done it well. In an ideal architecture, you wouldn't notice if the connections were native or not; your security settings would work in both cases; your clustering settings would still work; your capacity planning would still hold; and so on.
The only advantage of WebSockets over http streaming is that you don't have to make an effort to "understand" and parse the data received.
It's not as simple as opening up an HTTP stream and sitting back as your data flows for minutes, hours, or longer. Different clients behave differently and you have to manage that. For example some clients will buffer up the data and not release it to the application until some threshold is met. Even worse, some won't pass the data to the application until the connection is closed.
So if you're sending multiple messages down to the client, it's possible that the client application won't receive the data until 50 messages worth of data has been received, for example. That's not too real-time.
While HTTP streaming can be a viable alternative when WebSocket is not available, it is not a panacea. It needs a good understanding to work in a robust way out in the badlands of the Web in real-world conditions.
Are there any other significant differences that I am missing?
There is one other thing that noone has mentioned yet, so I'll bring it up.
The WebSocket protocol was designed to a be a transport layer for higher-level protocols. While you can send JSON messages or what-not directly over a WebSocket connection, it can also carry standard or custom protocols.
For example, you could do AMQP or XMPP over WebSocket, as people have already done. So a client could receive messages from an AMQP broker as if it were connected directly to the broker itself (and in some cases it is).
Or if you have an existing server with some custom protocol, you can transport that over WebSocket, thus extending that back-end server to the Web. Often an existing application that has been locked in the enterprise can broaden it's reach using WebSocket, without having to change any of the back-end infrastructure.
(Naturally, you'd want to be able to do all that securely so check with the vendor or WebSocket provider.)
Some people have referred to WebSocket as TCP for the Web. Because just like TCP transports higher-level protocols, so does WebSocket, but in a way that's compatible with Web infrastructure.
So while sending JSON (or whatever) messages directly over WebSocket is always possible, one should also consider existing protocols. Because for many things you want to do, there's probably a protocol that's already been thought of to do it.
I'm sorry if I am re-asking or combining many of the questions already on SO into a single question, but I just want to make perfect sense out of all the info that is out there on SO and the web regarding these concepts.
This was a great question, and the answers have all been very informative!

If I may ask one additional thing: I came across in an article somewhere that says that http streaming may also be cached by proxies while websockets are not. what does that mean?
(StackOverflow limits the size of comment responses, so I've had to answer here rather than inline.)
That's a good point. To understand this, think about a traditional HTTP scenario... Imagine a browser opened a web page, so it requests http://example.com, say. The server responds with HTTP that contains the HTML for the page. Then the browser sees that there are resources in the page, so it starts requesting the CSS files, JavaScript files, and images of course. They are all static files that will be the same for all clients requesting them.
Some proxies will cache static resources so that subsequent requests from other clients can get those static resources from the proxy, rather than having to go all the way back to the central web server to get them. This is caching, and it's a great strategy to offload requests and processing from your central services.
So client #1 requests http://example.com/images/logo.gif, say. That request goes through the proxy all the way to the central web server, which serves up logo.gif. As logo.gif passes through the proxy, the proxy will save that image and associate it with the address http://example.com/images/logo.gif.
When client #2 comes along and also requests http://example.com/images/logo.gif, the proxy can return the image and no communication is required back to the web server in the center. This gives a faster response to the end user, which is always great, but it also means that there is less load on the center. That can translate to reduced hardware costs, reduced networking costs, etc. So it's a good thing.
The problem arises when the logo.gif is updated on the web server. The proxy will continue to serve the old image unaware that there is a new image. This leads to a whole thing around expiry so that the proxy will only cache the image for a short time before it "expires" and the next request goes through the proxy to the web server, which then refreshes the proxy's cache. There are also more advanced solutions where a central server can push out to known caches, and so on, and things can get pretty sophisticated.
How does this tie in to your question?
You asked about HTTP streaming where the server is streaming HTTP to a client. But streaming HTTP is just like regular HTTP except you don't stop sending data. If a web server serves an image, it sends HTTP to the client that eventually ends: you've sent the whole image. And if you want to send data, it's exactly the same, but the server just sends for a really long time (like it's a massively gigantic image, say) or even never finishes.
From the proxy's point of view, it cannot distinguish between HTTP for a static resource like an image, or data from HTTP streaming. In both of those cases, the client made a request of the server. The proxy remembered that request and also the response. The next time that request comes in, the proxy serves up the same response.
So if your client made a request for stock prices, say, and got a response, then the next client may make the same request and get the cached data. Probably not what you want! If you request stock prices you want the latest data, right?
So it's a problem.
There are tricks and workarounds to handle problems like that, it is true. Obviously you can get HTTP streaming to work since it's it's in use today. It's all transparent to the end user, but the people who develop and maintain those architectures have to jump through hoops and pay a price. It results in over-complicated architectures, which means more maintenance, more hardware, more complexity, more cost. It also means developers often have to care about something they shouldn't have to when they should just be focussing on the application, GUI, and business logic -- they shouldn't have to be concerned about the underlying communication.

HTTP limits the number of connections a client can have with a server to 2 (although this can be mitigated by using subdomains) and IE has been known to enforce this eagerly. Firefox and Chrome allow more (although I can't remember of the top of my head exactly how many). This might not seem like a huge issue but if you are using 1 connection constantly for real-time updates, all other requests have to bottleneck through the other HTTP connection. And there is the matter of having more open connections from clients puts more load on the server.
WebSockets are a TCP-based protocol and as such don't suffer from this HTTP-level connection limit (but, of course, browser support is not uniform).