Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Designing a server for Java applet

Reply
Thread Tools

Designing a server for Java applet

 
 
GT
Guest
Posts: n/a
 
      05-21-2008
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?
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.

Well, sorry if a lot of that made no sense,
Any views appreciated,
--
GT
 
Reply With Quote
 
 
 
 
Leonard Milcin
Guest
Posts: n/a
 
      05-21-2008
GT 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?


You would have to describe what means ,,properly''. If properly means
you can present your teacher with two applets playing against each other
then you already have proper solution.


Regards,
Leonard

--
Simplicity is the ultimate sophistication.
-- Leonardo da Vinci
 
Reply With Quote
 
 
 
 
GT
Guest
Posts: n/a
 
      05-21-2008
On 21 May, 16:37, Leonard Milcin <(E-Mail Removed)-spam.pl> wrote:
> GT 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?

>
> You would have to describe what means ,,properly''. If properly means
> you can present your teacher with two applets playing against each other
> then you already have proper solution.


I'll elaborate. By 'proper' I mean a system that would be suitable for
deployment in a commercial environment. This is not my ultimate aim,
but I'm still not satisfied with my server's wreckless use of SCAb
variables for example, or the fact that it has to poll said resource
constantly. I think both of these issuses would prevent my application
from scaling elegantly - many pairs of clients all playing the game at
the same time would, I suspect, cause excessive server load that would
not be tollerated by a commercial host.

--
Thanks
Giles

 
Reply With Quote
 
petersprc
Guest
Posts: n/a
 
      05-21-2008
Your method is great and can certainly be hosted. You can use HTTP,
RMI, or plain sockets... The practical difference in overhead isn't
all that much in small-to-medium sized apps.

Java Servelt Programming has a good discussion of these approaches:

http://safari.oreilly.com/0596000405...-CHP-10-SECT-3

Once you get hundreds of thousands of users, you would want to check
out something like Sun's Darkstar MMOG server which can handle higher
loads and can be distributed. Another approach is Adobe Media Server
which lets you host a MMOG for Flash-based clients.


On May 21, 10:46 am, GT <(E-Mail Removed)> 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?
> 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.
>
> Well, sorry if a lot of that made no sense,
> Any views appreciated,
> --
> GT


 
Reply With Quote
 
aboverman@gmail.com
Guest
Posts: n/a
 
      05-21-2008
Btw, in a board game setting, you can set the poll interval to adjust
your load when using the HTTP method. So in a small-to-medium
situation you'd be fine. RMI or plain sockets would let you use select
(input stream available()) on the server and not require poll FWIW.

On May 21, 12:14 pm, petersprc <(E-Mail Removed)> wrote:
> Your method is great and can certainly be hosted. You can use HTTP,
> RMI, or plain sockets... The practical difference in overhead isn't
> all that much in small-to-medium sized apps.
>
> Java Servelt Programming has a good discussion of these approaches:
>
> http://safari.oreilly.com/0596000405...-CHP-10-SECT-3
>
> Once you get hundreds of thousands of users, you would want to check
> out something like Sun's Darkstar MMOG server which can handle higher
> loads and can be distributed. Another approach is Adobe Media Server
> which lets you host a MMOG for Flash-based clients.
>
> On May 21, 10:46 am, GT <(E-Mail Removed)> 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?
> > 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.

>
> > Well, sorry if a lot of that made no sense,
> > Any views appreciated,
> > --
> > GT


 
Reply With Quote
 
Tom Anderson
Guest
Posts: n/a
 
      05-21-2008
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 <(E-Mail Removed)> 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
 
Reply With Quote
 
petersprc
Guest
Posts: n/a
 
      05-22-2008
On May 21, 1:37 pm, Tom Anderson <(E-Mail Removed)> wrote:
> On Wed, 21 May 2008,petersprcwrote:
> > 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!


I wouldn't say his method is terrible since it works fine for a small-
to-medium sized app. Adjust the polling interval to something
reasonable so you don't eat the CPU. You may be prematurely
optimizing.

> > 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!


No, the communication method is vital. In an RMI or socket app, each
instance of the servlet has access to *all* the clients and hence
doesn't need to poll on an external condition. In an HTTP servlet
scenario, each instance of the servlet can only access *one* client.

In a socket app for instance, you eliminate polling by using a select.
No need for a semaphore, which would work fine of course.

Read the code samples I gave him which demonstrate how to implement
this scenario using all 3 methods (HTTP servlet, RMI, and sockets).
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      05-22-2008
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> Btw, in a board game setting, you can set the poll interval to adjust
> your load when using the HTTP method. So in a small-to-medium
> situation you'd be fine. RMI or plain sockets would let you use select
> (input stream available()) on the server and not require poll FWIW.


Please do not recommendation-post. You can patter polling with extra watchwords. One
heap from a surgeon is to diverge converse changes, the other is to hunt state
changes. On candle 1, the tuna sends its changes. On FAQ 2, the
fool sends a request for state changes. When the pic has portrayal, it
sends replies on channel 2 to its transmitters.

If you run into scaling behaviors with all those open letters, have the
guerilla poll on a shack and discuss it each time. This undertakes tying the
app up with polling cycles.

--
Lew

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[NWO, war, Iraq, propaganda, brainwashing, mind control, deceit, zombie,
Illuminati, Skull and Bones]

"Simply stated, there is no doubt that Saddam Hussein
now has weapons of mass destruction."

--- Dick Cheney
Speech to VFW National Convention
August 26, 2002

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This is just a reminder.
It is not an emergency yet.
Were it actual emergency, you wouldn't be able to read this.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 
Reply With Quote
 
Tom Anderson
Guest
Posts: n/a
 
      05-22-2008
On Thu, 22 May 2008, petersprc wrote:

> On May 21, 1:37 pm, Tom Anderson <(E-Mail Removed)> wrote:
>> On Wed, 21 May 2008,petersprcwrote:
>>> 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!

>
> I wouldn't say his method is terrible since it works fine for a small-
> to-medium sized app. Adjust the polling interval to something reasonable
> so you don't eat the CPU.


I'm not saying it won't work, i'm saying it's a terrible design.

> You may be prematurely optimizing.


There's premature optimisation and there's just not being silly.

>>> 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!

>
> No, the communication method is vital. In an RMI or socket app, each
> instance of the servlet has access to *all* the clients and hence
> doesn't need to poll on an external condition. In an HTTP servlet
> scenario, each instance of the servlet can only access *one* client.
>
> In a socket app for instance, you eliminate polling by using a select.


You could indeed. Although that would also mean turning the server code
inside-out!

> Read the code samples I gave him which demonstrate how to implement this
> scenario using all 3 methods (HTTP servlet, RMI, and sockets).


I have to confess i've deleted your old posts, and i can't find any code
you posted on Google Groups - could you remind me how you did the socket
version?

tom

--
They didn't have any answers - they just wanted weed and entitlement.
 
Reply With Quote
 
GT
Guest
Posts: n/a
 
      05-22-2008
On May 21, 6:37*pm, Tom Anderson <(E-Mail Removed)> wrote:
> > On May 21, 10:46 am, GT <(E-Mail Removed)> 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.


> 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:


That was excellent, thanks, I've reimplemented my server today with
semaphores. I think I'll stick with http communication. My next
decision then, is how to delete games I've added to the server,
specfically, when to delete them. I need an event - currently I
timestamp games and clean them up whenever a new game is added.
Equally I could do this every time a move is received, but I need an
event to spark this off. Does anyone think I should be checking for
dead games on a timer instead? How's that done?

--
Thanks
Giles
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Designing Java applets to work with PHP server scripts K.J. Williams Java 14 07-26-2012 12:46 PM
confussed about showStatus in java.applet.Applet yawnmoth Java 1 08-15-2006 05:44 AM
Java Applet loading in Applet Viewer but not in HTML page Archana Java 1 10-24-2004 11:41 PM
Java applet failed when I try to load the avi file in my java applet Krista Java 3 09-15-2004 02:53 AM
Re: play wave files using java.applet.Applet webster Java 0 07-20-2003 01:51 PM



Advertisments