I have a AJAX client which must receive messages from server. Some messages from server not like request-response type. For example, imaging game in which players can enter. Server must send to client info about player entering. But how can server send message to client via http without request from client?
Only decision that i can invent: client send request to server (getNewPlayerEnter request) with big timeout, server checks state of player set, if in set new players are, then server send info to client, if not server 'sleeps' on some time, and after 'sleeping' server checks players set again.
I think my desicion a little stupid(maybe not little). How implement it right?
p.s. sorry for my english
What you are referring to is "polling" where your client side code will make a request to the server every X seconds to check for updates.
It's an easy to implement solution, which is why you see it so often. However, a better solution is to use Comet.
In 2006, Alex Russell coined the term "Comet" to identify a technique whereby the client makes and HTTP request to the server and the server keeps that connection open indefinitely. With this open connection, the server can then push updates to the client in the response when there are updates.
When the response is received, the client immediately opens a new long-lived HTTP connection.
I encourage you to do a search for "Comet" and whatever server-side language you are using to find a framework that will get you started.
Comet Daily has some really great demos, from chat applications to games, that use Comet. If you have a tool like Firebug or Chrome Debugger, you can observe the response/request cycle of these real-time applications.
http://cometdaily.com/2009/10/23/concrete-comet-examples/
The way this typically would be done is for the client to ping the server on a regular interval (say, every 10-seconds). If there has been a change on the server, the change is sent back to the client. If there has been no change, either a blank response is sent, or some sort of "no-change" code that you specify.
Related
I have a game I am working on that is client/server (fully authoritative). The game is not FPS or MMORPG. More like Clash of Clans where you can see other people's attacks, chat, manage your resources etc but no real-time players in the same battle/attack.
Nothing is saved on the client's phone (other than its uniqueID). So when it logs in, the server sends the player's current state/data.
Now, if the client wants to do something (move a unit, collect coins, start building something, etc)
The server will validate everything, of course, to prevent cheating.
However, I see 2 approaches:
1: No acknowledgment from the server
The client decides to do something, it is automatically applied on the client's side and it sends this information to the server.
The server validates the action. If it is legal, store the new information and do nothing.
No acknowledgment is sent to the client
The client was not waiting for acknowledgment either.
If the action was not valid (it means the client was cheating). The server does not save the state and close the connection.
2: Fully acknowledged
The client decides to do something, it sends this information to the server and waits (nothing happens on the client at the moment)
The server validates the action. If it is legal, store the new information.
Server sends the acknowledgment + the new state to the client.
The client then applies the new state.
If the action was not valid, it does not store the new information and sends an "invalid action" to the client. It can also decide to close the connection.
Option 1 reduces considerably the traffic between the client and server, plus the player does not feel "lags" when doing an action. And it does not remove the authoritative validation of the server.
Option 2 makes it more "legit" in the sense the client can never "see" an illegal move and the server always acknowledge something before the client can see it.
I assume most FPS will use something closer to option 2, but since it is not real-time I would assume option 1 would be ideal.
Any reason option 1 would cause an issue and I should go for option 2?
I have a very simple netty app which serves both as server and a client.
Client uses channel.writeAndFlush() to send request to server and then blocks on monitor.wait().
In client's InboundAdapter in channelRead() I find the appropriate monitor and do monitor.notify() to let the requesting client thread to proceed working on the server's reply.
On the server in ChannelHandler's channelRead() I do the following:
To limit the amount of requests being processed I submit a task which does the real work as a new task to existing EventLoop: ctx.executor().submit(new Task()). I that task I do heavy IO operations and after that I writeAndFlush() results back to client.
Here is my pipeline setup:
new ObjectEncoder(),
new ObjectDecoder(LibConstants.Search.MAX_REQUIEST_SIZE, ClassResolvers.cacheDisabled(null))
Here is the bootstrap config:
new ServerBootstrap()
.channel(NioServerSocketChannel.class)
.option(ChannelOption.SO_BACKLOG, 1000)
.option(ChannelOption.SO_KEEPALIVE, true)
I have 2 problems:
Rather often I get io.netty.handler.codec.DecoderException: java.io.UTFDataFormatException on the client when receiving a reply from server. I cannot find any obvious reason for this. Since my pipeline setup is so simple.
A reply from the server just wouldn't appear on the client. I the logs I see a successful flush on the server but the reply never arrived at the client. This is very hard to deal with since my app is very latency sensitive. Any timeout I would set will kill my user experience.
This all happens over a VPN network so there is a possibility that VPN device misbehaves in some weird way but I hoping that TCP would handle any sort of packet loss/corruption which can happen in the channel.
Any advice or experience you can share will be very appreciated!
I'm trying to implement a custom live chat program on the web, but I'm not sure how to handle the real-time (or near real-time) updates for users. Would it make more sense to send Ajax requests from the client side every second or so, polling the database for new comments?
Is there a way to somehow broadcast from the database each time a comment is added? If this is possible how would that work? I'm using Sql Server 2008 with Asp.net (c#).
Thanks!
Use long polling/server side push/comet:
http://en.wikipedia.org/wiki/Comet_(programming))
Also see:
http://en.wikipedia.org/wiki/Push_technology
I think when you use long polling you'll also want your web server to provide some support in the form of non-blocking io for requests, so that you aren't holding a thread per connection.
You could have each client poll the server, and at the server side keep the connection open without responding.
As soon there is a message detected at server side, this data is returned through the already open connection. On receipt, your client immediately issues a new request.
There's some complexity as you need to keep track server side which connections is associated with which session, and which should be responded upon to prevent timeouts.
I never actually did this but this should be the most resource efficient way.
Nope. use queuing systems like RabiitMq or ActiveMQ. Check mongoDB too.
A queuing system will give u a publish - subscribe facilities.
I was watching many presentations about Html 5 WebSockets , where server can initialize connection with client and push the data without the request from the client.
We don't need Polling etc.
And , I am curious , why Http was designed as a "pull" and not full duplex protocol in the first place ? What where the reasons behind that kind of decision ?
Because when http was first designed it was meant to be used to retrieve documents from a server. And the easiest way to do is when the client asks the server for a document and gets it delivered as response (or an error in case it does not exist). When you have push protocol that means the server would need to keep client connections around for potentially a long time creating more resource management problems - remember we are talking about early 1990s here.
Http was designed for simply retrieving hypertext documents from a server. There were no reasons to push anything to the client when the pages were just pure, static html without scripting capabilities.
Since there was no need at the time for pushing things back to the client, the protocol was kept simple.
HTTP is mainly a pull protocol—someone loads information on a Web server and
users use HTTP to pull the information from the server at their convenience. In particular,
the TCP connection is initiated by the machine that wants to receive the file.
Manytimes clients ask for features like instant messaging (IM) and other client-to-client (P2P) communication for their web apps. Typically how is this done in normal web browsers? For example I've seen demos of Google Wave (and Gmail) that are able to IM from a regular browser. Is this via HTTP? Or does XmlHttpRequest (AJAX) provide the necessary backend for such communication?
More than anything I wonder how can a server "wake up" the remote client, lets say for sending an IM? Or does the client have to keep "polling" the message server for new IMs?
Typically the browser will poll the server for new messages. One approach that is often done to make this more efficient is the 'long poll' (see also this link) - the server responds immediately if it has anything; otherwise, it waits, keeping the connection open for a while. If a message comes in, it immediately wakes up and sends it, otherwise it comes back with a 'nope, check back' after a few tens of seconds. The client them immediately redials to go back into the long-polling state.