Re: [Rails-devel] [18xx] Rails (was: Web-based 18xx)

[brett l. <wak...@gm...>]

On Thu, Aug 7, 2008 at 2:08 PM, Erik Vos <eri...@hc...> wrote:
>
>
>> -----Original Message-----
>> From: rai...@li...
>> [mailto:rai...@li...] On Behalf
>> Of brett lentz
>> Sent: Thursday 07 August 2008 21:35
>> To: Development list for Rails: an 18xx game
>> Subject: Re: [Rails-devel] [18xx] Rails (was: Web-based 18xx)
>>
>> On Thu, Aug 7, 2008 at 1:07 PM, Erik Vos <eri...@hc...> wrote:
>> > What we need for "real" real-time play is some API that
>> can, both on the
>> > server and the client side, take a Java object (or a series
>
>> If we use XMPP, the server-side would be just another jabber server,
>> and people could use any jabber server they want.  This has some
>> advantages, because we can then leverage things like Jabber.org and
>> google talk as ways of connecting our clients.
>
> OK, so the game engine (acting as the GM) will also be a jabber client.
>

Yes.  The "server" component would function as a moderator and as a
message relay for distributing game data to the players.  In that
sense, it's still a server, but from the messaging layer's perspective
it's a jabber client.

>> However, doing a "basic" client/server application is relatively
>> simple:  http://williams.comp.ncat.edu/Networks/JavaSocketExample.htm
>
> Yes, I know. A while ago I have developed a fairly elaborate comms package
> based on such principles.
> In fact I have in mind to reuse it here in some form.
> But then the game enogine will be a server listening to some port, open to
> everyone.
> That's fine on a LAN, but is this secure enough for the Internet, even with
> basic authentication? I doubt.
>

Well, this is where I'm on much more familiar ground. I've got a fair
amount of experience with networking and network security.

When it comes to security, there's a couple of things that we may want
to assure.  It breaks down like this:

1. Application security
2. Player authentication and authorization
3. Transport security.

App security is simply making sure that a remote user can't do
anything malicious to the client or server. The major risk factor for
our application is remote file system access. We tend to cover this by
not allowing the user to specify files or paths outside of the config
file, and the app only reads the config files and doesn't write to
them.  Also, we don't really allow any form of remote code execution,
so we're fairly safe here.

Player authentication is something that I see as mandatory. At a
minimum, we will need to provide the users with a way to
password-protect their server.  An optional step beyond that is
setting specific passwords for individual players, or specific IP
allow/deny lists.  I can't really see the need for privilege
delegation, because our application usage is fairly simple.

Transport security is, to me, optional. Not using SSL/TLS introduces
some risk of game tampering due to packet modification or injection.
However, I don't really see this as a significant risk, because it can
be mitigated within the game engine itself by doing value boundary
checking, checksumming the messages, etc.  The other reason I consider
this optional is because we're not seeking to communicate privileged
information. At best, we'll be sending the player's names over the
wire, along with the updated game data. I would expect the players to
be smart enough to not use their full names when playing internet
games.


>> > In any case: I don't want another batik.
>> >
>>
>> I'm not sure I understand what you're referring to there.
>
> Its enormous size - and so many libraries that call each other and that all
> need to be mentioned in the classpath....
>

Hrm. I'm not sure I see the problem.

Java isn't exactly known to be a "lightweight" language. The JVM
itself is considered pretty bloated.

To be honest, if code size was a legitimate issue, we should be
writing significant portions of this app in C or assembly.

Also, Batik is broken up by function. We only use a couple things, and
can definitely delete the libraries we're not using.

---Brett.