Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (581)
games submitted by our members
Games in WIP (500)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  'Server-initiated' communication  (Read 2080 times)
0 Members and 1 Guest are viewing this topic.
Offline rajit_b

Innocent Bystander




Java games rock!


« Posted 2003-05-24 07:06:22 »

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
Offline Phil-o-soph

Junior Newbie




need more coffee


« Reply #1 - Posted 2003-05-24 17:00:53 »

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
Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #2 - Posted 2003-06-08 01:45:45 »

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.

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Phil-o-soph

Junior Newbie




need more coffee


« Reply #3 - Posted 2003-06-08 09:44:21 »

Quote

... keep an HTTP connection open over port 80 (keep alive http) which is bad.


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

Quote

... clients poll the server at intervals,


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
Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #4 - Posted 2003-06-08 15:26:37 »

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.

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline Phil-o-soph

Junior Newbie




need more coffee


« Reply #5 - Posted 2003-06-08 15:39:42 »

Quote

... running a servlet on both sides you'll get the same poor performance ...


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?

Quote

If you want fast response times, you absolutely aren't going to get it with servlets or HTTP for that matter.


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
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

xsi3rr4x (62 views)
2014-04-15 18:08:23

BurntPizza (60 views)
2014-04-15 03:46:01

UprightPath (73 views)
2014-04-14 17:39:50

UprightPath (56 views)
2014-04-14 17:35:47

Porlus (73 views)
2014-04-14 15:48:38

tom_mai78101 (99 views)
2014-04-10 04:04:31

BurntPizza (159 views)
2014-04-08 23:06:04

tom_mai78101 (254 views)
2014-04-05 13:34:39

trollwarrior1 (208 views)
2014-04-04 12:06:45

CJLetsGame (215 views)
2014-04-01 02:16:10
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!