glob2-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Networking (was Re: [glob2-devel] Glob2 salvage proposal)


From: Andrew Sayers
Subject: Re: Networking (was Re: [glob2-devel] Glob2 salvage proposal)
Date: Mon, 24 Oct 2005 22:14:30 +0100
User-agent: Mutt/1.5.11

On Mon, Oct 24, 2005 at 09:35:50PM +0200, Martin Voelkle wrote:
>      >    You forgot that the salvage proposal uses a central server where
>      the game
>      >    runs. The model can therefore be extremely simplified:
> 
>      Yes, but I still believe the peer-to-peer nature of the game can work,
>      and that if it can work, it's a better solution than a central server.
> 
>      For example, memory would be a very serious issue on a central server.
>      The map code alone will take more than (21 * number_of_teams * map_width
>      * map_height) bytes of data per game.  For an 8 player 512*512 map,
>      that's 42 megabytes of data - manageable for one game, but do you want
>      to donate the server that could be asked to run a dozen of them at once?
> 
>    It doesn't need to be like that. The server would be the machine of one of
>    the players. Many games work like that. There is a host player which
>    creates the game. The other players join it. When the host player starts
>    the game, a server is started on his computer and the other computers just
>    act as clients. The host player runs both the server and his own client.
>    The server and the client can be embedded in the same executable. If they
>    are splitted, you can run a standalone server, which is very convenient if
>    one of the players has a spare machine to run it.

That's true - although a client with no state information would have to
get updates about every movement of every glob, which would take
significantly more memory, and be significantly more susceptible to
network instability.

This solution would still benefit from our own protocol stack, so that
the game server didn't have to deal with all the bandwidth of every game
of Glob2.

> 
>      >    - The only good way to prevent spoofing is to use some lightweight
>      digital
>      >    signature (encryption). Here the metaserver can act as a trusted
>      server to
>      >    establish a secure connection between the client and the server.
>      While
>      >    encryption might be too heavyweight for the server, it can easily
>      be run
>      >    in parallel to the game to take advantage of multiple processors or
>      >    HT-like processors.
> 
>      The real question is: why prevent spoofing?  What do people have to gain
>      by attacking a game of Glob2?  The most likely outcomes are to make the
>      game desynchronise or insert orders that shouldn't be there.  While
>      annoying, these are hardly a major threat.
> 
>    I agree with you. It's just a possibility to consider.
>    I remember back in ye olde days when there was a bug in glob2 that allowed
>    to restore a building's HP by upgrading and cancelling the upgrade.
>    Gentlemen's behaviour said we shouldn't use this trick, but some people
>    where doing it anyway... They will recognize themselves, as they will
>    probably read this.

I don't remember back that far, so it's useful for me to hear about
these sorts of things.  I've been brushing up on my security knowledge
while writing these messages :)

At any rate though, securing communication strikes me as something that
can be bolted on to the game at a later date if needs be, so it's safe
to ignore it for now.

        - Andrew




reply via email to

[Prev in Thread] Current Thread [Next in Thread]