I am working on an automation project using Raspberry pi and Windows IoT. Is it possible to broadcast to a web page, similar to Server-Send-Event? I am monitoring certain events and instead of calling server every few seconds for updates, I would like server to send the alert to web page direct. Any help would be greatly appreciated.
I think you can use WebSockets. WebSockets are an advanced technology that makes it possible to open an interactive communication session between the user's browser and a server. You can refer to this sample. Or you can use IoTWeb to embed a simple HTTP and WebSocket server into your application.
Update:
WebSockets are a great addition to the HTTP protocol suite, but there are numerous situations where they cannot be used.
Some companies have firewalls that will prevent WebSockets from
working.
If you are deploying software in a shared hosting
environment, you may not be permitted to use WebSockets.
If you are
behind a reverse proxy that isn’t configured or the software doesn’t
support pass-through of WebSocket protocol, WebSockets won’t work.
Another option is long polling,the browser does an XHR request and the server simply doesn’t respond until it has something to send. But in this way, if you want to do 2-way communications with the server, you are effectively using 2 sockets. One is tied up hanging/waiting for the long poll response, and the other is sent by the client to send new information to the server. Long polling is also problematic because the client has to be able to handle XHR errors, some of which are tricky to handle or even impossible to handle. You can search more differences and disadvantages from internet.
Related
I've been working through a bunch of WebRTC examples, and they all require a custom Websocket server for exchanging the signalling data. OTOH, every WebRTC doc states that you can use anything for signalling, including carrier pidgeons.
So I've been wondering, just out of curiosity: why isn't signalling usually done using a boring old REST API (or similar)? It's not as if the setup process has realtime requirements, for which using Websockets would make sense...
Because you want the setup process to be as quick as possible—usually—and there can be quite a few messages to exchange, especially if you use ICE trickling. Using AJAX you'd have to use repeated polling, which is certainly slower. If that's good enough for you and you see some advantage in doing it that way vs. web sockets, more power to you. But typically you'd want to forward messages to the other peer as soon as you get them, not whenever the other peer happens to poll the server next. And the only practical option to push data from the server to the client are web sockets.
You could use server-sent events for the server-to-client push and AJAX for the client-to-server sending… but why, when web sockets already provide duplex communication?
What are the advantages and disadvantages of using only socket based communication vs a hybrid of REST and socket (using socket only when bidirectional communication is necessary, like receiving messages in a chat).
When I say only socket, I mean that instead of sending a GET request asking for /entities, I'd send update_needed and the server would send a push via socket.
My question is not really about performance, it's more about the concept, like delegate vs block/lambda (using socket would be like the delegate concept and REST is more like block).
It all boils down to what type of application and level of scalability you have in mind.
WebSocket/REST: Client connections?
How to handle CQRS from a client-side perspective
Hard downsides of long polling?
The main reason why I wouldn't use WebSockets in any major project is simply that still many users don't use a modern browser that support them. Namely IE 8 and 9 don't support them and both together still have a market share of over 20 % (Oct 15).
At the bottom, it's all about socket communications. If there is some way to get the ip of the both users, why can't the connection be directly setup between the users instead of having to go thru a server in the middle?
My 2 cents:
No one out there forces us to have a server based real-time communication model. Infact XMPP have an extension called "Serverless Messaging" which defines how to communicate over local or wide-area networks using the principles of zero-configuration networking for endpoint discovery and the syntax of XML streams and XMPP messaging for real-time communication. This method uses DNS-based Service Discovery and Multicast DNS to discover entities that support the protocol, including their IP addresses and preferred ports.
P2P chat applications have been for over a decade now. Having a server in the middle is purely a decision dependent upon your application needs. If your application can live with chats getting lost while the user was transitioning between online/offline status, then you can very well have a direct P2P model going. Similarly, there are a loads and loads of advantages (contact list management, avatars, entity discovery, presence authorization, offline messages, ....) when it comes to choosing a server based messaging model. If you try to have all this right inside your P2P based clients, they might die or under-perform because of all the work they will need to perform by themselves.
"WebSockets" were not designed for P2P/Serverless communication, rather they were designed to provide a standardized PUSH semantic over stateless HTTP protocol. In short, "WebSockets" is a standardized way replacing hacky comet, long-polling, chunked-encoding, jsonp, iframe-based and various other technique developers have been using to simulate server push over HTTP.
Named WebSockets (if someday it is fully and widely supported) could be the solution.
http://namedwebsockets.github.io/spec/
Named WebSockets are useful in a variety of collaborative local device
and local network scenarios: Discover matching peer services on the
local device and/or the local network.
Direct communication between users is possible in Peer To Peer (P2P) networks. In P2P each participant can act as client as well as server. But for P2P networks you need to write a separate program to make the communication possible.
Web Sockets let you leverage existing common browsers as clients. All depends on what is the purpose of your application and how you want to deploy it.
If there is some way to get the ip of the both users
You nailed the answer right in your question.
Most machines I use have IP address of 192.168.0.10 (or similar from 192.168. private network) and are deep, deep behind several layers of NAT. With the end of free IPv4 address pool and IPv6 nowhere near sight, this is the reality most users live. Having a stable intermediary of known, routable address helps a ton working around this issue.
WebSockets don't allow the socket to listen for connections, only to connect as a client to a server (not reverse). Technically they could make it allow this, but as far as I understand the spec doesn't currently (nor is it expected to) allow listen functionality for WebSockets.
The new WebRTC (http://www.webrtc.org/) spec looks like it might support peer-to-peer connections. I have not played with WebRTC at all so I'm not in a position to comment on it. I think it would be a bit more involved than WebSocket stuff. Maybe someone who knows WebRTC better can chime in. (Also apart from the latest version of Chrome I'm not sure if any of the other browsers really support WebRTC yet).
I've been asked about the possibilities for writing an ejabber module for an internal application. I am opposed to the idea, but I'm not sufficiently familiar with xmpp to support my response, and perhaps I'm wrong.
When google did wave they chose xmpp; and I understand that choice; real time communication between multiple people. Same goal here.
...but it feels to me like a customized server plugin isn't the right answer.
The issues I see are:
1) You lose sync with the server development and have to go through merge hell to ensure security updates, patches, etc. on the server are patched.
2) Any heavy customization of the server means you're probably expecting to be passing special mark up messages to interact with the server plugin; that means you'll have to do heavy client customization as well.
There is an alternative route:
Standard XMPP server. two customized xmpp clients; one for the client and one for the server.
The server client opens a connection to the XMPP server and sits and waits.
Multiple front end clients open connections to the XMPP server and then use xmpp to open connections optionally: 1) to each other and 2) to the server client user.
The front end can then perform real time updates by talking to the server client. It can even subscribe to multiple server client users and have incoming 'activity streams' for multiple different concurrent tasks.
This has the advantages of:
1) You only need to solve the XMPP problem once (client library)
2) Your application server is never externally visible; only the XMPP server is externally visible, which is massive security win.
3) You can use whatever XMPP server infrastructure you want without any issue.
4) You will never have a server update that causes your application server to become 'legacy' and unable to use those apis any more (short of a complete XMPP protocol update).
Downside:
You application server client needs to be complicated enough to handle multiple requests, or have multiple workers or something (but this scales using resource fields and have multiple application servers from different machines connecting to the XMPP network).
...but, I'm not that familiar with the technology.
Is there any reason why the alternative I've suggested would be worse than a customized xmpp server?
XMPP is used in Google Wave/Wave in a Box only for Federation, i.e. only for server to server communications. This is in order to take advantage of existing XMPP capabilities like discovery protocol. The messages are transported in binary form between servers inside XMPP packets. The Web clients use WebSockets/Socket.IO to communicate with the server. Actually that was the reason to argue about developing an alternative pure HTTP based Federation protocol.
On this post, I read about the usage of XMPP. Is this sort of thing necessary, and more importantly, my main question expanded: Can a chat server and client be built efficiently using only standard HTTP and browser technologies (such as PHP and JS, or RoR and JS, etc)? Or, is it best to stick with old protocols like XMPP find a way to integrate them with my application?
I looked into CampFire via LiveHTTPHeaders and Firebug for about 5 minutes, and it appears to use Ajax to send a request which is never answered until another chat happens. Is this just CampFire opening a new thread on the server to listen for an update and then returning a response to the request when the thread hears an update? I noticed that they're requesting on a specific port (8043 if memory serves me) which makes me think that they're doing something more complex than just what I mentioned. Also, the URL requested started with /tcp/ which I found interesting.
Note: I don't expect to ever have more than 150 users live-chatting in all the rooms combined at the same time. I understand that if I was building a hosted pay for chat service like CampFire with thousands of concurrent users, it would behoove me to invest time in researching special technologies vs trying to reinvent the wheel in a simple way in my app.
Also, if you're going to do it with server polling, how often would you personally poll to maximize response without slamming the server?
The technology is broadly called Comet, which is supposedly some hilarious pun on Ajax1.
The XmlHTTPResponse variant seems to be the most popular.
The XHR version isn't strictly polling per se; as you said, the client connects with a long timeout and the server doesn't actually send a response until there is anything to send. Once the response is sent, it drops the connection and the client reconnects. They call it long polling, because the client is initiating the connection, but it differs from classic polling in that the client doesn't constantly connect requesting new content even if nothing has changed (i.e. no "is there a message now? no? how about now? what about now?")
It's more like trying to keep a constantly dropping connection open.
Yes it can absolutely be built using standard web technologies.
1I prefer to think of Ajax as a mighty Greek warrior rather than a cleaning product, so I frown mightily upon this pun.
That would first depend on your strategy of your webserver load balancing. 150 concurrent users that publish data over a stateless medium (HTTP) is certainly efficient with the bit of scripting (client- and server side). Remember that chat applications are just many client -> one server strategies, that fits perfectly over the web.