Designing a server for Java applet

Discussion in 'Java' started by GT, May 21, 2008.

  1. GT

    GT Guest

    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
    GT, May 21, 2008
    #1
    1. Advertising

  2. 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
    Leonard Milcin, May 21, 2008
    #2
    1. Advertising

  3. GT

    GT Guest

    On 21 May, 16:37, Leonard Milcin <-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
    GT, May 21, 2008
    #3
  4. GT

    petersprc Guest

    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/jservlet2-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 <> 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
    petersprc, May 21, 2008
    #4
  5. GT

    Guest

    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 <> 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/jservlet2-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 <> 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
    , May 21, 2008
    #5
  6. GT

    Tom Anderson Guest

    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 <> 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
    Tom Anderson, May 21, 2008
    #6
  7. GT

    petersprc Guest

    On May 21, 1:37 pm, Tom Anderson <> 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).
    petersprc, May 22, 2008
    #7
  8. GT

    Lew Guest

    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.
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Lew, May 22, 2008
    #8
  9. GT

    Tom Anderson Guest

    On Thu, 22 May 2008, petersprc wrote:

    > On May 21, 1:37 pm, Tom Anderson <> 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.
    Tom Anderson, May 22, 2008
    #9
  10. GT

    GT Guest

    On May 21, 6:37 pm, Tom Anderson <> wrote:
    > > On May 21, 10:46 am, 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.


    > 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
    GT, May 23, 2008
    #10
  11. GT

    Tom Anderson Guest

    On Thu, 22 May 2008, GT wrote:

    > On May 21, 6:37 pm, Tom Anderson <> wrote:
    >>> On May 21, 10:46 am, 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.

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


    With crontab -e and wget.

    tom

    --
    :-( bad :) bad :-| good
    Tom Anderson, May 23, 2008
    #11
  12. GT

    Roedy Green Guest

    On Wed, 21 May 2008 07:46:38 -0700 (PDT), GT <>
    wrote, quoted or indirectly quoted someone who said :

    >
    >The server is Java servlet running on Tomcat.


    One possible technology to use is to exchange serialised Java objects,
    perhaps gzipped. That saves the hassle of defining a protocol. It is
    quite compact. The biggest problem is making sure applet and server
    use identical versions of the classes exchanged.

    --

    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
    Roedy Green, May 23, 2008
    #12
  13. On May 23, 12:04 pm, Roedy Green <>
    wrote:
    ...
    > One possible technology to use is to exchange serialised Java objects,
    > perhaps gzipped.  That saves the hassle of defining a protocol. It is
    > quite compact.  The biggest problem is making sure applet and server
    > use identical versions of the classes exchanged.


    Java webstart* would help with the client side
    versioning. Ensuring applets running in browsers
    get updated, would be a nightmare.

    * Yes, yes. I was waiting for 'half a good reason'
    to mention webstart on this thread - and that was
    it.

    --
    Andrew T.
    PhySci.org
    Andrew Thompson, May 23, 2008
    #13
  14. GT

    petersprc Guest

    On May 22, 2:28 pm, Tom Anderson <> wrote:
    > On Thu, 22 May 2008,petersprcwrote:
    > > 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.


    I totally agree with you that synchronization is superior to polling.

    My point was, realistically, the performance cost of polling is
    negligible in the poster's scenario. Say you had 100 concurrent
    instances polling at 2 second intervals. That's 50 lookups per second
    with some waking involved. The total overhead might not even reach
    0.0001% of a single CPU on commodity hardware. So, there shouldn't be
    any concern about doing this on a shared host, which is why I said his
    solution is fine. There's no need to rewrite his code and potentially
    introduce race conditions or deadlocks. A robust, buffering, message
    queue that supports multiple listeners who can possibly drop and
    reconnect requires slightly more implementation...

    The main bottleneck is the number of simultaneous connections, which
    you would run out of way before polling becomes an issue. A plain
    socket app would be a bigger win as the overhead of each connection is
    much lower than a full HTTP session and you can use select directly on
    the sockets, thus avoiding any polling entirely.

    A typical server may only be handle to a few hundred simultaneous
    transactions, so the poster will need a dedicated server at that
    point. And yes, I would use a synchronized message queue that
    broadcasts all the messages in a game to all the observers who attach
    to it.

    And of course the plain socket app or RMI servlet make it easy to do
    asynchronous messaging with no polling.

    JMS - Jave Message Service - would be the next step, as that can be
    distributed across machines. Then there's Sun Darkstar which is
    designed to handle very large virtual worlds...

    The code is here:

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

    Regards,

    John Peters
    petersprc, May 23, 2008
    #14
  15. GT

    Tom Anderson Guest

    On Thu, 22 May 2008, petersprc wrote:

    > On May 22, 2:28 pm, Tom Anderson <> wrote:
    >> On Thu, 22 May 2008,petersprcwrote:
    >>> 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.

    >
    > I totally agree with you that synchronization is superior to polling.
    >
    > My point was, realistically, the performance cost of polling is
    > negligible in the poster's scenario. Say you had 100 concurrent
    > instances polling at 2 second intervals. That's 50 lookups per second
    > with some waking involved. The total overhead might not even reach
    > 0.0001% of a single CPU on commodity hardware. So, there shouldn't be
    > any concern about doing this on a shared host, which is why I said his
    > solution is fine.


    You have a point there. I hadn't considered the possibility that he was
    using a sleep interval between polls, which was silly of me. A sleeping
    poll would indeed be entirely practical.

    > There's no need to rewrite his code and potentially introduce race
    > conditions or deadlocks.


    I don't think he's likely to get either of those. The solution i suggested
    is functionally interchangeable with repeated polling, so it only
    introduces a deadlock where he already had an infinite loop.

    > A robust, buffering, message queue that supports multiple listeners who
    > can possibly drop and reconnect requires slightly more implementation...


    And isn't necessary here.

    > The main bottleneck is the number of simultaneous connections, which you
    > would run out of way before polling becomes an issue. A plain socket app
    > would be a bigger win as the overhead of each connection is much lower
    > than a full HTTP session and you can use select directly on the sockets,
    > thus avoiding any polling entirely.


    The HTTP server could be implemented with select for all we know.

    Using sockets and select directly means dealing with inside-out control
    flow, where rather than reading and writing from the socket, you have to
    return control from your code to the select loop, which is a huge headache
    in a language without coroutines.

    > A typical server may only be handle to a few hundred simultaneous
    > transactions, so the poster will need a dedicated server at that
    > point. And yes, I would use a synchronized message queue that
    > broadcasts all the messages in a game to all the observers who attach
    > to it.
    >
    > And of course the plain socket app or RMI servlet make it easy to do
    > asynchronous messaging with no polling.
    >
    > JMS - Jave Message Service - would be the next step, as that can be
    > distributed across machines. Then there's Sun Darkstar which is
    > designed to handle very large virtual worlds...


    If the OP's game gets to that scale, he should certainly get back to us
    for fresh advice!

    > The code is here:
    >
    > http://safari.oreilly.com/0596000405/jservlet2-CHP-10-SECT-3


    Links to pay subscription resources: not helpful.

    tom

    --
    You are in a twisty maze of directories, all alike. In front of you is
    a broken pipe...
    Tom Anderson, May 23, 2008
    #15
  16. GT

    petersprc Guest

    On May 23, 11:22 am, Tom Anderson <> wrote:
    > > The code is here:

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

    >
    > Links to pay subscription resources: not helpful.


    Use the 10-day free trial if you like... You can find similar code for
    chat servers which is the usual example as well.
    petersprc, May 23, 2008
    #16
  17. GT

    Arne Vajhøj Guest

    petersprc wrote:
    > On May 21, 1:37 pm, Tom Anderson <> 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.


    Prematurely optimization is to replace nice code with ugly code
    to get small performance gains.

    Choosing something that scales well from the start is called
    good architecture.

    People who can see the future and know that the app will never
    need to scale can omit that. The rest of us has to start with a
    good architecture.

    Arne
    Arne Vajhøj, May 25, 2008
    #17
  18. Lew wrote:
    > 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 top-post. You can avoid polling with extra connections.
    > One connection from a client is to push move changes, the other is to
    > pull state changes. On connection 1, the client sends its changes. On
    > connection 2, the client sends a request for state changes. When the
    > server has information, it sends replies on channel 2 to its clients.
    >
    > If you run into scaling problems with all those open connections, have
    > the client poll on a connection and close it each time. This avoids
    > tying the server up with polling cycles.


    Both RMI and plain sockets are bidirectional. You do not need
    an extra connection to avoid polling. You can choose an extra
    connection to make the protocol simpler.

    Opening and closing TCP connections is not the right way to solve
    scalability problems. When number of TCP connections become an
    issue, then switch to UDP.

    (but too many TCP connections requires a huge load)

    Arne
    Arne Vajhøj, May 25, 2008
    #18
  19. GT

    Arne Vajhøj Guest

    petersprc wrote:
    > My point was, realistically, the performance cost of polling is
    > negligible in the poster's scenario. Say you had 100 concurrent
    > instances polling at 2 second intervals. That's 50 lookups per second
    > with some waking involved. The total overhead might not even reach
    > 0.0001% of a single CPU on commodity hardware. So, there shouldn't be
    > any concern about doing this on a shared host, which is why I said his
    > solution is fine. There's no need to rewrite his code and potentially
    > introduce race conditions or deadlocks. A robust, buffering, message
    > queue that supports multiple listeners who can possibly drop and
    > reconnect requires slightly more implementation...


    ????

    50 request/second = 0.0001% CPU means that one CPU can handle
    50 million requests per second.

    I am pretty sure that Google would love to get a few of those
    "single CPU on commodity hardware".

    > The main bottleneck is the number of simultaneous connections, which
    > you would run out of way before polling becomes an issue.


    I very much doubt that.

    > A plain
    > socket app would be a bigger win as the overhead of each connection is
    > much lower than a full HTTP session and you can use select directly on
    > the sockets, thus avoiding any polling entirely.


    Sockets avoid polling because the server can push. Select has nothing to
    do with that.

    Arne
    Arne Vajhøj, May 25, 2008
    #19
  20. GT

    petersprc Guest

    On May 24, 10:07 pm, Arne Vajhøj <> wrote:
    > petersprcwrote:
    > > My point was, realistically, the performance cost of polling is
    > > negligible in the poster's scenario. Say you had 100 concurrent
    > > instances polling at 2 second intervals. That's 50 lookups per second
    > > with some waking involved. The total overhead might not even reach
    > > 0.0001% of a single CPU on commodity hardware. So, there shouldn't be
    > > any concern about doing this on a shared host, which is why I said his
    > > solution is fine. There's no need to rewrite his code and potentially
    > > introduce race conditions or deadlocks. A robust, buffering, message
    > > queue that supports multiple listeners who can possibly drop and
    > > reconnect requires slightly more implementation...

    >
    > ????
    >
    > 50 request/second = 0.0001% CPU means that one CPU can handle
    > 50 million requests per second.
    > I am pretty sure that Google would love to get a few of those
    > "single CPU on commodity hardware".


    No, we're not talking about "requests per second". You don't
    understand the post you're replying to.

    The workload under consideration comprises testing a boolean flag
    (MyListener.updateFlag == true) every 2 seconds. The difference
    between this and waiting on a semaphore is negligible in the described
    scenario. Further, It was stated that there were 100 total
    connections, not "50 million."

    > > The main bottleneck is the number of simultaneous connections, which
    > > you would run out of way before polling becomes an issue.

    >
    > I very much doubt that.


    That's nice, maybe you should discuss your deep doubts with the Tomcat
    folks and ask them why the hard limit on simultaneous requests is
    *200* by default.

    > > A plain
    > > socket app would be a bigger win as the overhead of each connection is
    > > much lower than a full HTTP session and you can use select directly on
    > > the sockets, thus avoiding any polling entirely.

    >
    > Sockets avoid polling because the server can push. Select has nothing to
    > do with that.


    The push is done after select (or a blocking read) returns data.

    > Arne
    petersprc, May 25, 2008
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. webster
    Replies:
    0
    Views:
    851
    webster
    Jul 20, 2003
  2. Rune Andresen
    Replies:
    2
    Views:
    1,940
    Phil Powell
    Sep 17, 2003
  3. Krista
    Replies:
    3
    Views:
    2,315
    Andrew Thompson
    Sep 15, 2004
  4. Roland Poellinger
    Replies:
    1
    Views:
    1,298
    Ryan Dillon
    Mar 12, 2005
  5. K.J. Williams
    Replies:
    14
    Views:
    891
    Arne Vajhøj
    Jul 26, 2012
Loading...

Share This Page