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

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

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 of objects) and
> deliver it to the other side by whatever magic. The difference between the
> client API and the server API is, that the former opens outgoing connections
> and the latter accepts incoming connections. For the rest it must be a
> asynchronous two-way channel.
>
> If Jabber can deliver such a black box, or if we can easily build such APIs
> on top of Jabber, fine with me.
>
> I've done a quick search on Jabber. So far I have only seen glimpses of APIs
> at the client side. Is there also a java API that we can bolt on our server
> (the 18xx game engine)? Or would our server be just another Jabber client?
>

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.

However, doing a "basic" client/server application is relatively
simple:  http://williams.comp.ncat.edu/Networks/JavaSocketExample.htm


> During my brief search I have seen remarks on large overhead (what else do
> you expect with XML) and problems with binary data, so I'm not immediately
> convinced of the greatness of this technology. But perhaps I'm wrong.

Like I said, it's just an option that is worth consideration.  There's
more than one way to solve this problem.  :-)

> In any case: I don't want another batik.
>

I'm not sure I understand what you're referring to there.

> Erik.
>


---Brett.


>> -----Original Message-----
>> From: rai...@li...
>> [mailto:rai...@li...] On Behalf
>> Of brett lentz
>> Sent: Thursday 07 August 2008 01:49
>> To: Development list for Rails: an 18xx game
>> Subject: Re: [Rails-devel] [18xx] Rails (was: Web-based 18xx)
>>
>> 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.
>>
>> --------------------------------------------------------------
>> -----------
>> This SF.Net email is sponsored by the Moblin Your Move
>> Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK &
>> win great prizes
>> Grand prize is a trip for two to an Open Source event
>> anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>