I was wondering can web servers initiate communication with web browsers?
from my understanding they communicate but can web server innitiate it?
No. The client must establish and maintain some kind of connection, ie HTTP, WebSocket, or AJAX before the server can send any data. Once the browser window is closed the session is lost and the server can send no more data. In WebSockets the server can push data asynchronously but only through the established connection that the client initiated.
Yes, you can use the WebSocket technology, takes a look here:
WebSocket
Web servers using HTTP cannot. However, there are some new web technologies around the corner that hope to change that.
Check out SPDY. One of their technical goals is:
To enable the server to initiate communications with the client and push data to the client whenever possible.
Related
I am building a browser multiplayer game. For latency, I want to use WebRTC DataChannel to sync the game state. In my setup, one peer is always the server, which is always reachable (no NAT on server side, maybe on user side).
Most setups recommend using a websocket as the signaling channel. I saw some setups with manual copy-pase signaling, with one peer sending an offer to the other peer, the other peer sending an offer back.
Now, this sounds to me like a REST API - Browser does POST request with a SDP offer to the server, then receives SDP answer from server, both can establish connection. When the connection drops, they do that again. Client can always reach server, since that's on a public IP.
What is the disadvantage of doing it this way vs. establishing a websocket and keeping that open?
in a signaling session the SDP is not the only thing you are sending back and forth. So a short answer to why not to use REST API might be that when you trickle ICE candidates other than SDP there are so many messages going back and forth. I believe the SDP only will not have many problems with REST API but overall websocket is preferable basically even just because of websocket faster.
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.
I have a client and a server application that is communicating just fine, there is a TIdCmdTCPServer in the server and a TIdTCPClient in the client.
The client has to authenticate in the server, the client asks the server for the newest version information and downloads any updates, and other communications. All this communication with TIdTCPClient.SendCmd() and TIdTCPClient.LastCmdResult.Text.Text.
The way it is, the server receives commands and replies, the clients only receives replies, never commands, and I would like to implement a way to make the client receives commands. But as I heard, if the client uses SendCmd it should never be listening for data like ReadLn() as it would interfere with the reply expected in SendCmd.
I thought of making a command to check for commands, for example, the client would send a command like "IsThereCommandForMe" and the server would have a pool of commands to each client and when the client asks, the server send it in the reply, but I think it would not be a good approach as there would be a big delay between the commands being available and the client asking for it. I also thought of making a new connection with new components, for example a TIdCmdTcpClient, but then there would be 2 connections for each client, I don't like that idea as I think it could easily give problems in the communication.
The reason I want this, is that I want to implement a chat functionality in the client, and it should be receiving messages from the server without asking for it all the time, imagine all clients continually asking the server if there is message for them. And I would like to be able to inform the client when there is an update available instead the client being asking if there is any. And with this I could send more commands to the client too.
what are your thoughts about this ? how can I make the server receiving commands from the clients, but also sends them ?
TCP sockets are bidirectional by design. Once the connection between 'client' and 'server' has been established, they are symmetric and data can be sent at any time from any side over the same socket.
It only depends on the protocol (which is just written 'contract' for the communication) which communication model is used. HTTP for example uses a request/reply model. With Telnet for example, both sides can initate data transmissions. (If you take a look at the Indy implementation for Telnet, you will see that it uses a background thread to listen for server data, but it uses the same socket connection in the main thread to send data from client to server).
A "full duplex" protocol which supports both request/response and server push, and also is firewall-friendly, is WebSockets. With WebSockets (a HTTP upgrade), the server can send data to the connected client(s) any time. This would meet your 'chat' requirement.
If you use TIdTCPClient / TIdCmdTCPServer, corporate firewalls might block the communication.
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.
I'm new to node.js and I want to ask a simple question about how it works.
I have used FMs in the past for client to client communication and real time applications. For example, for creating a collaborative application where you need to see what other users are doing. I want to explore that using NodeJS.
I have couple of questions:
1) How does NodeJs handle server-to-client communication? Is thee any way to push information to the client? or the client needs to be making requests constantly to the server to see if anything has changed?
2) Is there such thing like permanent connections between the server and the clients?
3) How Can be handle client-to-client communication (of course thru the server)?
Thanks in advance.
3) How Can be handle client-to-client
communication (of course thru the
server)?
A simple solution is to open a websocket between the server and each client :
[Client A] <==websocket==> [Server] <==websocket==> [Client B]
If you go with Socket.IO for example, it is very easy to do client-to-client communication this way.
When the server receives a message from one client, you just broadcast it to all clients or send it to one specific client depending on your use case.
Some example code using Socket.IO :
var socket = io.listen(server);
socket.on('connection', function(client) {
client.on('message', function(msg) {
broadcast(msg); // broadcast message to all clients
// OR
socket.clients[session_id].send(msg); // send message to one client
});
client.on('disconnect', function( ) {
console.log('Client Disconnected.');
});
});
Quite a lot of Node.js questions from you recently ;)
As Toby already said, Node can do HTTP, TCP/UDP and Unix Sockets. When you establish a permanent connection, you can of course push data to the clients.
Since you are talking about Browser based clients, there a numerous ways to achieve this. You could for example use WebSockets with a Flash fallback. In case you are not interested in the low level details and want a complete package, take a look at Socket.IO.
WebSockets can't do this, Flash can't do it either as far as I know. So unless you want to enter Java/Silverlight land, you'll need to route the requests through your server.