'Server-initiated' communication

Networking & Multiplayer
#1

We are developing an online game where the client will be a downloadable VC++ rich client and the server side game logic will be implemented in EJB with a servlet being the contact point for the client.
The requirement is that, on occurance of some event, the server should send some data to all the clients currently connected. This ‘send’ operation should be initiated by the server itself (“server-initiated”), without waiting for the client to contact the server next time. (To achieve quick response/action)
Considering the fact that the client and server are communicating over HTTP which is request/response based, how to achieve this ‘server-initiated’ communication without a client request?

Thanks
Rajit

#2

Could you explain how you know which clients are “connected” to the servlet? Assuming you call the servlets via HTTP which is stateless, you track clients with a session (cookie or request parameter).

I can think of two ways to let your server carry out stuff to the client:

[]Equip the client application with a servlet itself to handle the incoming data from the server. This would be an overkill, as you would have to bundle your client with a servlet engine.
[]Or you might drop your servlet idea completely in favor of persistent connections and a custom protocol via TCP/UDP - this would also be much faster than the servlet approach.

One major drawback in you client-server design seems to me, that servlets don’t do persistent connections (as far as I know): They get a request, service() it and close the connection. This means, you’ll always have to open a new connection, which will make it quite hard for you to “achieve quick response/action” :-/

phil

#3

You’re looking at an asynchronous messaging problem and trying to solve it with a synchronous tactic and that’s going to lead you down a very nasty bumpy road.

If the server is broadcasting messages over HTTP the clients either need to keep an HTTP connection open over port 80 (keep alive http) which is bad. What you might want to look into is having the clients poll the server at intervals. The server would broadcast messages into message queues where the clients would arrive and pick up the messages that are waiting for them since the last time they polled the server. This is the way async comms are going to work best.

#4

full ack, persistent HTTP (and HTTP in general) is bad for games which need fast response times.

IMHO that’s no good either:

If there are few messages being sent, this would cause quite a lot of unnecessary traffic because there won’t be a message waiting everytime the client polls the server.

If there are many messages sent and the client poll interval is too long, messages could pile up on the server and eventually crash it due to an out of memory error (only in rare cases of course)

I’d prefer some kind of “fire and forget” communication, where the server just writes the message to a stream/whatever and the client gets it instantly.

Just my 2 cents,
phil

#5

If you’re talking about running a servlet on both sides you’ll get the same poor performance as keeping an HTTPSession open on both sides - and actually it may be worse with remarshalling of data and reconnecting to the servlet. If you want fast response times, you absolutely aren’t going to get it with servlets or HTTP for that matter.

If you want something that works (however), you have a large collection of mediocre options.

#6

You’re right, it’s slow to use a HTTP servlet. I only mentioned the both-sided-servlet approach because rajit_b said they are currently using a servlet - so why throw it all over when it might not be necessary?

You don’t have to use HTTP for servlets, the servlet spec lets you implement any protocol, i.e HTTP, FTP, HTTPS and your home brewed protocols if you want. But for fast-paced games, all this servlet stuff is definitely overkill and much too slow.

I’d prefer to implement a custom protocol on top of TCP/IP or UDP if speed is of importance.

phil

PS: Is rajit_b still with us? He’s so quite…n