Re: Designing a server for Java applet
On Wed, 21 May 2008, petersprc wrote:
Your method is great and can certainly be hosted.
No, his method is terrible, and it would not go down at all well with a
host. He knows that - that's why he's asking about ways to do it better!
You can use HTTP, RMI, or plain sockets... The practical difference in
overhead isn't all that much in small-to-medium sized apps.
The problem isn't the communication method, it's how he handles
communication. Read what he wrote again: when player A is waiting for
player B's move, the servlet is busy-waiting, polling the server
whatjamacallits. Busy-waiting! Not good!
GT, the solution to your problem is a good old semaphore, aka mutex. You
set up an object to use as the semaphore, which could well be one of these
server context things. When your next-move-wanting thread comes in, it
goes:
synchronized (contextThing) {
while (!contextThing.hasNextMove()) contextThing.wait() ;
return contextThing.getNextMove() ;
}
Your next-moving, thread, on the other hand, goes:
synchronized (contextThing) {
contextThing.setNextMove(move) ;
contextThing.notify() ;
}
You should probably actually just package those up into methods on
ContextThing and declare them synchronized, so you don't need the explicit
synchronized block. Also, you need to handle InterruptedException in the
move-getting code, probably by letting it propagate. Also, you should use
a timeout on the wait(), and propagate the exception if it times out.
I'm assuming here that there are only two players. If there are more,
things are slightly more complicated, but not a lot.
I'm not 100% sure a semaphore-based solution would be acceptable to a host
either, i have to say. You have to be really careful that it can't
deadlock - that means using sensible timeouts on all your waits, and not
getting into loops where you keep going back and waiting some more.
Further remarks below ...
On May 21, 10:46 am, GT <dtsw...@googlemail.com> wrote:
I've developed a Java applet based on an old board game, mainly as a
learning exercise. I've just yesterday finished my first effort at the
server for it, so now two applets can play the game against each other
over my network.
The server is Java servlet running on Tomcat. All data is sent over
HTTP. The moves made by each player are stored on the server in Server
Context Attributes.
Either the applet:
1) waits for user input - when a user makes a move this is encoded
and sent to the server.
2) requests its opponent's next move from the server. In response to
this request the server polls its SCAbs until the opponent has
supplied a move which is then sent back to the applet
This does work for the purposes of my project, but I guess my question
is how would it be done properly?
i.e.
Could I deploy such a system to a commercial Java host? Would they
allow such abuse of the SCAbs?
What technology would a proper online game use? Presumably not a
tomcat server. As everything is sent over http the server does not
have to be Java, but I used it as I'm comfortable(ish) with the thread
handling. I only know PHP apart from Java, and I reckon PHP would have
a hell of a job with such a system. There's no static context for a
start, unless you start storing things in databases/flat files, which
probably wouldn't be a bad idea.
Could this be done with JavaBeans rather than sending http requests?
Do you mean Enterprise JavaBeans? If so, then what you really mean is can
it be done with RMI instead of HTTP. The answer is yes, and it's easier
and faster than HTTP but it means sacrificing interoperability: with your
current design, you or someone else could easily write a Visual Basic
client, or a DHTML + javascript AJAXy client, and because the interface is
HTTP, it's no problem. Interfacing either of those to RMI would be hard.
Although you can run RMI over the CORBA IIOP protocol, which is
language-neutral, and then there is a way to expose the interfaces to
other languages via CORBA. But this is getting a bit hairy.
I've no experience of them - I'll read up. I've used http as I've
assumed that if you ask people to run an applet you need to requests
that won't get firewalled - it's no use asking someone to use an
applet that is client and server - an intermediary is required.
Correct.
And if there are firewalls etc, you may have problems with RMI and
RMI-IIOP, since the ports they use are likely to be blocked. Although i
think there are ways to tunnel both of them over HTTP ...
tom
--
[Philosophy] is kind of like being driven behind the sofa by Dr Who -
scary, but still entertaining. -- itchyfidget