Re: Designing a server for Java applet
On Thu, 22 May 2008, petersprc wrote:
On May 21, 1:37 pm, Tom Anderson <t...@urchin.earth.li> 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.