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

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

On Wed, Aug 6, 2008 at 3:30 PM, Erik Vos <eri...@hc...> wrote:
>> If we want to leverage some existing code, for the "near realtime"
>> communication, XMPP (aka. Jabber) is a more appropriate protocol. I
>> believe there are a few different existing libraries we can leverage
>> for the communications, which could save us a TON of work.
>
> XML simple? It's verbose and slow, and needs lots of code to build and
> parse, as I have experienced so far...   Its main asset is that it's
> readable (and, oh yes, fashionable).
>

Not plain XML.   XMPP. There's a difference. XMPP has it's own IETF
standards and definitions.

There are already libraries ( http://www.jabber.org/libraries ) for
several languages, so most of the details of how to send messages is
already done for us.

In general, XMPP is a fairly mature communication protocol that is
excellent for real-time communications and message passing.. Plus, it
would be trivial to include a chat feature into the game. :-)

I'm not saying this is the only option, just that's its available and
worth considering.

> The simplest thing IMO would be to pass on serialized java objects.
> Save/Load is already based on (de)serialization. It's simple and fast and it
> works.
>

Sure, that works too.  Java has a bunch of API options for
client/server communications.  The down side is that we'd be forced to
build more of the structure ourself, and that will also require more
debugging effort than just hooking into a pre-existing library.

Sometimes, DIY is still the best way to go. I do want to point out the
added costs of going this route, though.

> My question is rather how to transfer such serialized objects between client
> and server, or applet and server, or whatever.
>
>> We should consider SMTP to be for PBEM only.  To be honest, the PBEM
>> component can be as simple as dropping the saved game file into an
>> e-mail, and passing around the saved game files.  There's a PBEM
>> Diplomacy client that does basically this. It connects to your mail
>> server and just looks for specially formatted e-mails, and loads the
>> contents into the game engine.
>
> I had such a thing in mind. I suppose there must be Java code around for a
> very basic SMTP/POP3 client, that we can build into Rails.
>
> Now, if we put either the ASCIIfied serialized Java objects or the
> corresponding plain text (or why not both) into e-mails, we might have
> achieved PBEM and near real-time play by the same mechanism.
>

Let's be _really_ clear about this.  SMTP is NOT anything resembling a
real-time communication protocol. There are mechanisms built into the
protocol that assume a highly variable amount of latency.

While SMTP is capable of fast transmission, that delivery speed is
never guaranteed. Delivery speed is not even a significant part of the
RFC. There's simply no way to guarantee that messages are delivered in
a timely fashion.

SMTP really needs to be considered as a PBEM-only protocol.  For more
real-time play we absolutely must use a different protocol.

What we're ultimately going to need is a modular network design that
allows us to "plug in" multiple communication backends, and define
whether they.are for live network play or "PBEM" play.


> This would be just a start, other means can perhaps be added later.
>
> On a LAN it can of course be done a lot simpler: just open a stream between
> client and server and pass the objects around. But is that safe enough for
> Internet?
>

These days, LAN play and Internet play are one and the same. We really
shouldn't separate them.  At a basic level, both types of play will
use TCP or UDP and should be indistinguishable from the other. (I
can't think of any reason why this wouldn't be the case.)

If we're going to implement our own communication method, it may be
good to use an encrypted communication channel. I believe Java has
some secure communication options, or we can use the openssl libraries
to encrypt our messages prior to transmission. Although, it also comes
down to what exactly it is that we're sending over the wire. We may be
able to get away with basic authentication without requiring a fully
encrypted channel for communicating.


>
> Erik.
>


----Brett.