I'm writing a Clojure application that uses websockets to communicate with clients. The server sometimes acts as a sort of hub, getting a message from one client and that triggering sending a message to another client. If I have only one web server that's fine, but if I have two I run into trouble as clients might be connected to different servers.
I think the best way to deal with this would be for a web server to broadcast the message received to the other ones so all of them can react and notify the appropriate client. How can I do this? Any libraries that can help?
If it matters, I'm planning on hosting this in Heroku at first but I always want to leave the door open for self hosting.
Related
I'm developing an iOS app that requires realtime dual-way server/client messaging.
I'm trying to use WebSocket++ to develop a WebSocket server app on an AWS EC2. Have to use C++ because that's the only language I know on the server side.
The problem is I'm a fresh guy on server side development. I have 2 very basic questions:
1, Do I need have to setup an HTTP server like apache/nginx in order to get websocket running?
That is, can websocket app live independently alone?
2, I have now setup an nginx server in case it is a must have, is there any resource that I can refer to to make nginx & websocket work together well?
No, you don't need a Web server, a (reverse) Web proxy or anything to have your C++ WebSocket server talk to WebSocket clients.
Nginx (as HAproxy) supports reverse proxying WebSocket. This can make sense in certain situations, like you want to terminate TLS at the proxy and forward plain WebSocket to your backend server, or you want to load-balance incoming WebSocket connections to multiple backend nodes. However, as said, this isn't required.
No you don't, websocket and socket for an HTTP server are two diffent things.
HTTP server is for the HTTP protocol while there is not protocol defined for websocket, you have to define it yourself typically by the mean of sending/receiving Json message (a stream of character which each side (the server and the client) knows how to read/write).
The goal of websocket is to offer to javascript through HTML5 an easy, light and quick way to communicate through a socket, without websocket you have to do that with web services and in that case you need a http server.
With websocket you can create an html file leveraging html tag and javascript, javascript use client side of websocket to communicate with a C++/websocket server program, and you do not need even a web server, in this scenario you have a "desktop web app" ! (here web term is only because you use html tags)
Same question, same answer, no again ;-)
Good luck, and welcome in the wonderful world of asio !
I learn about being asynchronous when i write code with twisted, but i wonder now how do common web servers process thing asynchronously. As a case of this below:
apache get a client request from A, and there maybe some operations block the main process. If apache doesn't do some tricks here, then at the just time another client B send
a request , and obviously client B will get no response. Right? I guess, every client request will be processed in a dependent process/thread?
And django is a web framework, the question is whether django has the logic about "not blocking", or the work is handled totally by web servers.
There are no tricks here, really. Apache simply spins up multiple processes and/or threads (depending on how it is configured), and a request is routed to the next available one.
The logic is exclusively in the web server.
How can I have two ways communication with WS. Two ways means a client could be a server and a server could be a client. As far as I understand the problem related to the client-server model in HTTP which is used by WS. What is the best practice for this scenario when a server wants send an event to multiple clients without being polled. ?
As far as I know there are some solutions but I do not know which one is best
1) server-push techniques (websockets)
2) SOAP over JMS (this sounds great)
3) WS-eventing
Thanks
The purpose of a webservice is - as the name says - to serve. It responds to requests, but it never sends requests on its own (but an application accessed through a webservice interface could send requests to other webservices to fulfill a request sent to it).
When a component of a service-oriented architecture is supposed to receive events from another component, it means that the receiving component has to act as a server and expose an own web services interface so that the component where the event occured can call it.
I have a mini computer that does not support websockets that I would like to receive push notifications from a server.
The issue is that after the client connects to the server, the server responds and then closes the connection. This makes it so the client has to continually reconnect to the server to get new information.
Is there a way using Django to allow the connection to be left open and then have the server publish data to the client?
Django is primarily a request/response framework and as such does not have support for real duplex communication.
Socket.IO is the de facto library that makes websocket-like functionality cross-browser (IE5.5+), using real websockets as a transport if the browser allows it, falling back to HTTP long-polling or whatever else if it doesn't. For various options on integrating Socket.IO with Django, read this.
I'm getting started with creating the back-end architecture to support a turn-based mobile game. Most of my research tells me that a stateless web server should work just fine, because the client is not always connected to the server.
My question is, how would I write the logic for GET requests. If I need a user to be updated when his or her opponent has made a move...do I keep doing GET requests every few seconds? Isn't it a big problem that the server is one-directional, as in the server can't notify the user when it is his/her move? Or am I overestimating it, and doing a GET requests every other second is perfectly fine?
Thanks!
I think you should consider the use of WebSockets:
http://en.wikipedia.org/wiki/WebSocket
And even if you are not using a browser, with iOS you can open a connection to the socket which uses port 80 (you don't need any extra rules). WenSockets providie a standardized way for the server to send content to the browser without being solicited by the client, and allowing for messages to be passed back and forth while keeping the connection open.