JSON asynchronous application server?
First let me explain the data flow I need
Client connects and registers with server
Server sends initialization JSON to client
Client listens for JSON messages sent from the server
Now all this is easy and simple to do by hand, but I would like to use some kind of server to handle all the include files, live clients, dead clients, etc. etc.
Are there any precedents for this kind of thing? Where does the client connect and receive JSON messages asynchronously from the server? Without using manual socket programming?
source to share
-
In the "good old days" this would be easy, since the first time the server connects, it gets the client's IP number so it can call back. It's actually so simple that this is how FTP works for no good reason ... But now we can almost be sure that the client is behind NAT, so you can't "call back".
-
Then you can just keep the TCP connection open since it is bidirectional, just make the client wait for the data to appear. The server will send whatever it wants when possible ... But now everyone wants every application to run on top of a web browser, which means HTTP, which is strictly a "request / response" initiated by the client.
-
So the current answer is Comet. Simply put, the JavaScript client makes a request, but the server is not responsible for the looooong time. if the connection times out, the client opens it immediately, so there is always one open pipe left waiting for the server to respond. This response will contain whatever message the server wants to send to the client, and only when appropriate. The client receives it and immediately sends a new request to open the channel.
-
source to share
A possible solution is known as Comet , in which the client opens a connection to a server that remains open for a long time.The server can then transmit data to the client as soon as it is available and the client receives it almost instantly. Eventually the comet conjunction expires and another is created.
Not sure which language you are using, but I have seen several for Java and Scala. Search for comet and your language name on Google and you should find something.
source to share
The problem is that HTTP is a request response protocol. The server cannot send any data if the client does not send requests.
Trying to get around this by dragging the request away and then continually sending responses to the same original requests has drawbacks because the behavior is not HTTP compliant and it doesn't work well with all types of intermediaries (proxies, routers, etc.) and browser behavior (Ajax completion). It also doesn't scale well, as a socket opened on a server is very resource intensive and sockets are very valuable resources (usually only a few thousand are available).
Trying to get around this by changing the flow (i.e. the server connects to the client when it needs to push) is even more flawed due to the security / authentication issues that come with this (the answer can easily be hijacked, abandoned, or faked), and also because often the client is unreachable (behind proxy servers or NAT devices).
AFAIK most RIA clients just polled the timer. Not perfect, but this is how HTTP works.
source to share