Hello everyone,
Man, that title is kind of long, but it's to the point. I'm working on making a game (the same game I mention in Map Storage For Game) and currently the way it's set up there is a server and several different clients. At the moment I'm working on writing the web client. The web client is just going to be a set of web pages with some forms that can submit data into the server. My question/meditation is how should I communicate betweeen the web front end and the server? My first thought was to use IO::Socket and such, but then that didn't seem like quite as good an idea. Because both the web pages and the server were going to be on the same machine this didn't seem necessary. Another method I thought of was just having the web front end be part of the server and having shared variables with it, but since I'd never done anything remotly like this I thought asking couldn't hurt.

Anyway, I was just having some problems with this and I thought I'd present it to my brothers at the monastary. (BTW, I've tried to RTFM but I couldn't find anything that seemed relevant. If someone has a link to something similar to my problem then that would be great too.)

-Ben Jacobs (dooberwah)
"one thing i can tell you is you got to be free"

  • Comment on Communications Between a Game Server and Web Front End

Replies are listed 'Best First'.
Re: Communications Between a Game Server and Web Front End
by herveus (Prior) on Nov 28, 2001 at 01:49 UTC
    Howdy!

    Right off the top of my head, I'd go for the socket based communications. That frees you from the requirement that the web front end and the server be on the same box.

    Decoupling is good. It lets you isolate the two parts. It makes it easier to try different clients.

    You will want to clearly document the communications between the parts.

    yours,
    Michael

[reply]
      I second it. It makes sense to have network protocol since you are going to have several different clients (as you have said). Just want to note that IO::Socket could be too low level. If you don't have any serious perfomance requirements take a look at SOAP. There exist very nice module SOAP::Lite which makes writting SOAP servers and clients very simple.
[reply]
        Take it one step further and write a SOAP client program that you can distribute. No web needed! Go soap!

        ____________________
        Jeremy
        I didn't believe in evil until I dated it.

[reply]
Re: Communications Between a Game Server and Web Front End
by fuzzysteve (Beadle) on Nov 28, 2001 at 07:10 UTC
    I'd second the IO::Socket idea (or third, or fourth...)
    I'll even justify it for you:
    • Not using it means one of two things. either you have to rework the server to allow for http access. (a headache in the making.) or work with data files that potentially could be out of date right after they're written (might not be much of a problem, but i don't know much about your game)
    • using it would allow you to move the client to another machine dependant on the load it will take.
    • do it right and all the clients can communicate with the server in the same way. keeps it nice and simple.

    from my perspective, if you can keep the server simple (all the clients use the same protocol to access it) then it keeps debugging down to a minimum. It also splits it up functionally, so each component does one thing, and (hopefully) does it well.
    The soap idea is similar in principal, and might be a good idea. (not sure what the protocol is like, but I've heard good things about it) If its sufficient to get your data moved, then go for it. no point doing work you don't have to after all. if your other clients can use it, then congrats, you've just found a drop in networking module.
[reply]
Re: Communications Between a Game Server and Web Front End
by MZSanford (Curate) on Nov 28, 2001 at 19:10 UTC
    To add yet more fuel to the brightly burning IO::Socket fire, i would also like to make a suggestion.

    Don't just use IO::Socket, go one step further and create your own module to do the IO::Socket communications with the server. This way, when you move from a CGI client, to a Win32::GUI client (or what ever), all of the client/server connection and interaction code will be reusable. Not to mention if you want to add new functionallity to your server.

    This is good OOP, good Abstraction, good sence... i think.
    i had a memory leak once, and it ruined my favorite shirt.
[reply]
Re: Communications Between a Game Server and Web Front End
by dooberwah (Pilgrim) on Nov 29, 2001 at 01:09 UTC
    Several people have said that I should is the SOAP module instead of IO::Select. I was wondering why they say this: is it because of performance or portability?

    -Ben Jacobs (dooberwah)
    "one thing i can tell you is you got to be free"

[reply]
      It is because of simplicity. IO::Socket provides you with low level protocol. Basically you can just read and write strings from a stream. You will have to roll your own high level protocol for communication between game server and client. You mentioned that you want several different clients. It means that unless they are all written in Perl they all will need their own libraries for handling of this high level protocol.

      With SOAP you already have high level protocol which is portable across different OSes and programming languages. Basically it a protocol which allows you to do RPC (function and method calls). SOAP::Lite is very convinient librariy which makes it completly transparent in Perl. See yourself. Read SOAP::Lite Guide.

      As for perfomance SOAP::Lite will be probably slower than your own protocol over IO::Socket. But it acceptable price in most cases unless you have very strict perfomance requirements.

[reply]

Back to Meditations