rails-devel — List for discussion of Rails development

Re: [Rails-devel] Starting on a client/server

[John A. T. <ja...@ja...>]

Brett Lentz wrote:
> It seems that java.nio.SocketChannel is probably a better choice than
> java.net.Socket. It seems like it's easier to manage multiple connections to
> the same port more easily with a SocketChannel.  I'm new to this part of the
> Java API, but that's my first impression.
>   
I think the only real difference is the buffering is more efficient in 
nio, but in either case I think you want a higher level API that can 
encapsulate same-machine via synchronized queues, between machines with 
sockets, between machines with some multicast protocol, etc.

--
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                		 		Smyrna, GA  30082-3723

Re: [Rails-devel] Starting on a client/server

[Brett L. <wak...@gm...>]

> -----Original Message-----
> From: rai...@li... [mailto:rails-devel-
> bo...@li...] On Behalf Of John A. Tamplin
> Sent: Wednesday, September 03, 2008 5:02 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Starting on a client/server
> 
> On Wed, 3 Sep 2008, Brett Lentz wrote:
> > That's not exactly how I read the function of java.net.Socket or
> > java.nio.SocketChannel.
> >
> > I'd need to double-check the API docs, to be sure, but I believe what
> are
> > passed are text representations of each object. So, we'll need to
> verify
> > that the default toString() method is an acceptable representation
> for each
> > object, or we'll need to override toString() with our own
> representation
> > that does pass the necessary data.
> 
> Sockets are byte channels, and you can send whatever you want across
> them,
> such as serialized objects.
> 
> --
> John A. Tamplin					ja...@ja...
> 770/436-5387 HOME				4116 Manson Ave
>                  		 		Smyrna, GA  30082-3723
>

Great!  So then tossing our objects over the SocketChannel ought to be
relatively easy.

It seems that java.nio.SocketChannel is probably a better choice than
java.net.Socket. It seems like it's easier to manage multiple connections to
the same port more easily with a SocketChannel.  I'm new to this part of the
Java API, but that's my first impression.

---Brett.

Re: [Rails-devel] Starting on a client/server

[John A. T. <jat...@ja...>]

On Wed, 3 Sep 2008, Brett Lentz wrote:
> That's not exactly how I read the function of java.net.Socket or
> java.nio.SocketChannel.
>
> I'd need to double-check the API docs, to be sure, but I believe what are
> passed are text representations of each object. So, we'll need to verify
> that the default toString() method is an acceptable representation for each
> object, or we'll need to override toString() with our own representation
> that does pass the necessary data.

Sockets are byte channels, and you can send whatever you want across them, 
such as serialized objects.

--
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                 		 		Smyrna, GA  30082-3723

Re: [Rails-devel] Starting on a client/server

[Brett L. <wak...@gm...>]

> -----Original Message-----
> From: rai...@li... [mailto:rails-devel-
> bo...@li...] On Behalf Of Erik Vos
> Sent: Wednesday, September 03, 2008 2:35 PM
> To: 'Development list for Rails: an 18xx game'
> Subject: Re: [Rails-devel] Starting on a client/server
> 
> > Right now, the biggest downside I can foresee is that _all_
> > clients must
> > talk to the server over a transport, which means that even
> > local games will
> > have to load up the network bits and talk across the
> > localhost.
> 
> Not necessarily, in my opinion. I had in mind generic API's
> (interfaces) at
> the client and the server side, that would take any sequence of objects
> at
> one side and deliver them at the other side. How that is done is
> internal to
> the transport module, that could have several implementations. For
> local
> play, it is just pass-through; I don't think we need separate programs
> communicating through a socket. For a client/server connection through
> sockets, the objects would be serialized at one side, sent over the
> socket,
> and deserialized at the other side (each object must know how to
> (de)serialize itself). For PBEM, we have SMTP and POP3 as transport
> mechanisms (in this case the objects must be accompanied by text). Etc.
> 

Not necessarily separate programs, but likely they'll at least be separate
threads.

I agree that a pass-through transport is probably the ideal way of handling
this. My first transport will be network-focused, so that will need to come
later. In the meantime, loopback communication is fast enough that nobody
should notice the slight inefficiency.

> My approach would have been first to refactor the current code to this
> architecture, and then add the transport through sockets as would just
> be a
> new implementation of an interface.
> 

That's not exactly how I read the function of java.net.Socket or
java.nio.SocketChannel. 

I'd need to double-check the API docs, to be sure, but I believe what are
passed are text representations of each object. So, we'll need to verify
that the default toString() method is an acceptable representation for each
object, or we'll need to override toString() with our own representation
that does pass the necessary data.

> > It's a minor
> > amount of overhead, though. So other than the conceptual
> > inefficiency, I
> > don't think it's a major problem.  The main requirement is
> > that the Server
> > will need two methods of startup: a command-line no-GUI
> > method, and through
> > the Options GUI for hosting a local Client and Server.
> 
> And a no-server Client.
> 

That should be handled at the UI level. The player selects "connect to a
remote game", and a local server instance simply is never started.

I can't really see why we'd distribute a client-only Jar package. Is there
really a use-case for someone to only play remote games, and never want to
play or host locally?

> > For now, I've decided to just use the native Java sockets in
> > java.net.* and
> > java.nio.*. I'll push PBEM support off until the basic
> > architecture is more
> > fleshed out. My gut feeling is that real-time network play
> > should be the
> > higher priority because there are already workable PBEM solutions.
> >
> > I think that maintaining good component separation is going
> > to require that
> > we adopt Java's concept of events and listeners. We do that
> > to some extent
> > with the Observer objects, but I think it's definitely
> > something that we can
> > work on improving.
> 
> I have looked hard at events and listeners before I started with
> Observer/Obervable, but at that time I concluded that Events wouldn't
> do the
> job for updating the UI. An Observer can register at a unique model
> object,
> whereas a Listener must register at a unique Event. This way, we would
> need
> separate (unique) events for each individual UI field, hex, stock
> space,
> etc.
> 
> Say a stock price token moves from stock chart space D5 to E5. Now the
> Observable StockSpace ModelObject D5 sends 'token removed' to UI
> ViewObject
> D5, and E5 sends a 'token added' to its counterpart. This does not
> translate
> directly to events.
> 
> If we are going to use events, I think the way to go is to replace this
> architecture by one in which the stock chart model as a whole, rather
> than
> the individual spaces, sends events to its UI counterpart, with the
> involved
> squares and tokens as parameters. Similarly the Map model sends events
> to
> the Map UI, and the OR model to the OR window (where we then still need
> to
> somehow identify the individual fields).
> 


I agree with you.  I think the Observer/Observable model is fine for certain
cases, but the Listener/Event model may be a better choice for others.

There is some merit to your description where we pass stock change Events to
the stock market UI as a whole, then it's the UI's job to understand how to
represent that. That leaves each UI free to implement that any way they
choose without the constraint of needing to process two separate actions for
removing the token from one space and placing a token into a new space.

I think this is something that we should come back to when I'm ready to
start integrating those pieces.

---Brett.

Re: [Rails-devel] Starting on a client/server

[Erik V. <eri...@hc...>]

> Right now, the biggest downside I can foresee is that _all_ 
> clients must
> talk to the server over a transport, which means that even 
> local games will
> have to load up the network bits and talk across the 
> localhost. 

Not necessarily, in my opinion. I had in mind generic API's (interfaces) at
the client and the server side, that would take any sequence of objects at
one side and deliver them at the other side. How that is done is internal to
the transport module, that could have several implementations. For local
play, it is just pass-through; I don't think we need separate programs
communicating through a socket. For a client/server connection through
sockets, the objects would be serialized at one side, sent over the socket,
and deserialized at the other side (each object must know how to
(de)serialize itself). For PBEM, we have SMTP and POP3 as transport
mechanisms (in this case the objects must be accompanied by text). Etc.

My approach would have been first to refactor the current code to this
architecture, and then add the transport through sockets as would just be a
new implementation of an interface. 

> It's a minor
> amount of overhead, though. So other than the conceptual 
> inefficiency, I
> don't think it's a major problem.  The main requirement is 
> that the Server
> will need two methods of startup: a command-line no-GUI 
> method, and through
> the Options GUI for hosting a local Client and Server.

And a no-server Client.
 
> For now, I've decided to just use the native Java sockets in 
> java.net.* and
> java.nio.*. I'll push PBEM support off until the basic 
> architecture is more
> fleshed out. My gut feeling is that real-time network play 
> should be the
> higher priority because there are already workable PBEM solutions.
> 
> I think that maintaining good component separation is going 
> to require that
> we adopt Java's concept of events and listeners. We do that 
> to some extent
> with the Observer objects, but I think it's definitely 
> something that we can
> work on improving.

I have looked hard at events and listeners before I started with
Observer/Obervable, but at that time I concluded that Events wouldn't do the
job for updating the UI. An Observer can register at a unique model object,
whereas a Listener must register at a unique Event. This way, we would need
separate (unique) events for each individual UI field, hex, stock space,
etc. 

Say a stock price token moves from stock chart space D5 to E5. Now the
Observable StockSpace ModelObject D5 sends 'token removed' to UI ViewObject
D5, and E5 sends a 'token added' to its counterpart. This does not translate
directly to events.

If we are going to use events, I think the way to go is to replace this
architecture by one in which the stock chart model as a whole, rather than
the individual spaces, sends events to its UI counterpart, with the involved
squares and tokens as parameters. Similarly the Map model sends events to
the Map UI, and the OR model to the OR window (where we then still need to
somehow identify the individual fields).

Re: [Rails-devel] Starting on a client/server

[Brett L. <wak...@gm...>]

Sounds like an excellent plan.

I'm rather happy that you've taken so much on. It would have taken me a lot
longer to implement most of the things that you took on.  :-)

Here's how I'm envisioning the architecture:

We need 4 main components:  Client, Server, Game Engine, and Data Transport.
These fit fairly well into the Model, View, Controller paradigm, which I'm
happy about.

I'm going to attempt to make everything as modular as possible to allow us
to build multiple modules (e.g. Swing Client, and Web Client. Java Sockets,
Jabber, SMTP transports, etc.). However, what this means is that we're going
to need to get better about writing JavaDoc and being a bit more strict with
our API definition so that we don't break things as we build additional
modules.

Right now, the biggest downside I can foresee is that _all_ clients must
talk to the server over a transport, which means that even local games will
have to load up the network bits and talk across the localhost. It's a minor
amount of overhead, though. So other than the conceptual inefficiency, I
don't think it's a major problem.  The main requirement is that the Server
will need two methods of startup: a command-line no-GUI method, and through
the Options GUI for hosting a local Client and Server.

For now, I've decided to just use the native Java sockets in java.net.* and
java.nio.*. I'll push PBEM support off until the basic architecture is more
fleshed out. My gut feeling is that real-time network play should be the
higher priority because there are already workable PBEM solutions.

I think that maintaining good component separation is going to require that
we adopt Java's concept of events and listeners. We do that to some extent
with the Observer objects, but I think it's definitely something that we can
work on improving.


---Brett.



> -----Original Message-----
> From: rai...@li... [mailto:rails-devel-
> bo...@li...] On Behalf Of Erik Vos
> Sent: Tuesday, September 02, 2008 3:05 PM
> To: 'Development list for Rails: an 18xx game'
> Subject: Re: [Rails-devel] Starting on a client/server
> 
> Hi Brett,
> 
> I'm very interested to see what you will come up with. In all honesty,
> Rails
> has perhaps become a bit too much my own baby, and a fresh look way
> well be
> in order. You're also solving my dilemma on how to continue myself - in
> the
> near future I will now just keep adding more games to the existing
> code.
> 
> Of course, I have my own thoughts on how to achieve the client/server
> split,
> and as you know I have already been working somewhat towards it. For
> instance, I think you would do well to reuse the PossibleAction
> hierarchy,
> to pass allowed and executed actions forth and back between client and
> server (in some serialized form). On the other hand, the screen updates
> via
> the ModelObject/ViewObject hierarchies do not translate well; the
> subclasses
> can perhaps be retained, but the top classes need be redone as the
> underlying Observer/Observable pattern must be replaced by something
> completely different. I don't yet have a conceptual solution for that.
> Although these are the main aspects of the client-server communication,
> there is a lot more that I have not even started to think about (such
> as
> changes to the current player and phase).
> 
> Anyway, I'll be happy to discuss such matters in more detail if you
> like,
> but perhaps we can then better do that off-list, to avoid annoying the
> onlookers.
> 
> I appreciate that you want to keep this new approach separate from the
> existing code. Hopefully we can reintegrate later on.
> 
> Good luck,
> Erik.
> 
> > -----Original Message-----
> > From: rai...@li...
> > [mailto:rai...@li...] On Behalf
> > Of brett lentz
> > Sent: Monday 01 September 2008 23:38
> > To: Development list for Rails: an 18xx game
> > Subject: [Rails-devel] Starting on a client/server
> >
> > I just wanted to send a quick update to the list on new developments.
> >
> > I've decided to get started on a client/server version of Rails. It's
> > been far too long since I actively wrote code, and I feel like I
> > should be more actively developing Rails.
> >
> > I've been giving it some thought, and I think the best approach is to
> > write a new architecture (mostly) from the ground up, rather than
> > migrating our existing code into a client/server paradigm.
> >
> > There are several reasons why I want to incorporate refactoring the
> > code into adding such a major new feature. One of the primary reasons
> > is that it will give me a chance to revisit the UI, the hex drawing
> > code, and many other areas of the codebase, and look at these things
> > with a fresh perspective. It's also a chance to clean up and organize
> > the code in ways that are difficult currently.
> >
> > One thing that I want to make perfectly clear. I'm absolutely not
> > throwing out our existing code.
> >
> > What I _am_ doing is starting from a new, empty project directory on
> > my workstation, writing a basic client and server, then slowly moving
> > our existing code in, one piece at a time. During this process, I'll
> > be cleaning up many areas of the code, and rewriting a couple of
> > things from scratch.
> >
> > As soon as I have a basic framework, I'll publish a new module into
> > CVS so that everyone can jump in and help get network play fully
> > functioning.
> >
> >
> > ---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

Re: [Rails-devel] Starting on a client/server

[Chris S. <chr...@gm...>]

>
> This is a development list, so I am not sure who would be here that you
> think would be annoyed by discussing a major architectural change.  Even
> if I don't have time to help out right now, please keep it on the list.


I agree.

-- 
Chris

Please consider the environment before printing this e-mail.

Re: [Rails-devel] Starting on a client/server

[John A. T. <ja...@ja...>]

On Wed, 3 Sep 2008, Erik Vos wrote:

> Anyway, I'll be happy to discuss such matters in more detail if you like,
> but perhaps we can then better do that off-list, to avoid annoying the
> onlookers.

This is a development list, so I am not sure who would be here that you 
think would be annoyed by discussing a major architectural change.  Even 
if I don't have time to help out right now, please keep it on the list.

--
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                 		 		Smyrna, GA  30082-3723

Re: [Rails-devel] Starting on a client/server

[Erik V. <eri...@hc...>]

Hi Brett,

I'm very interested to see what you will come up with. In all honesty, Rails
has perhaps become a bit too much my own baby, and a fresh look way well be
in order. You're also solving my dilemma on how to continue myself - in the
near future I will now just keep adding more games to the existing code.

Of course, I have my own thoughts on how to achieve the client/server split,
and as you know I have already been working somewhat towards it. For
instance, I think you would do well to reuse the PossibleAction hierarchy,
to pass allowed and executed actions forth and back between client and
server (in some serialized form). On the other hand, the screen updates via
the ModelObject/ViewObject hierarchies do not translate well; the subclasses
can perhaps be retained, but the top classes need be redone as the
underlying Observer/Observable pattern must be replaced by something
completely different. I don't yet have a conceptual solution for that.
Although these are the main aspects of the client-server communication,
there is a lot more that I have not even started to think about (such as
changes to the current player and phase).

Anyway, I'll be happy to discuss such matters in more detail if you like,
but perhaps we can then better do that off-list, to avoid annoying the
onlookers.

I appreciate that you want to keep this new approach separate from the
existing code. Hopefully we can reintegrate later on.

Good luck,
Erik.

> -----Original Message-----
> From: rai...@li... 
> [mailto:rai...@li...] On Behalf 
> Of brett lentz
> Sent: Monday 01 September 2008 23:38
> To: Development list for Rails: an 18xx game
> Subject: [Rails-devel] Starting on a client/server
> 
> I just wanted to send a quick update to the list on new developments.
> 
> I've decided to get started on a client/server version of Rails. It's
> been far too long since I actively wrote code, and I feel like I
> should be more actively developing Rails.
> 
> I've been giving it some thought, and I think the best approach is to
> write a new architecture (mostly) from the ground up, rather than
> migrating our existing code into a client/server paradigm.
> 
> There are several reasons why I want to incorporate refactoring the
> code into adding such a major new feature. One of the primary reasons
> is that it will give me a chance to revisit the UI, the hex drawing
> code, and many other areas of the codebase, and look at these things
> with a fresh perspective. It's also a chance to clean up and organize
> the code in ways that are difficult currently.
> 
> One thing that I want to make perfectly clear. I'm absolutely not
> throwing out our existing code.
> 
> What I _am_ doing is starting from a new, empty project directory on
> my workstation, writing a basic client and server, then slowly moving
> our existing code in, one piece at a time. During this process, I'll
> be cleaning up many areas of the code, and rewriting a couple of
> things from scratch.
> 
> As soon as I have a basic framework, I'll publish a new module into
> CVS so that everyone can jump in and help get network play fully
> functioning.
> 
> 
> ---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
> 

[Rails-devel] Starting on a client/server

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

I just wanted to send a quick update to the list on new developments.

I've decided to get started on a client/server version of Rails. It's
been far too long since I actively wrote code, and I feel like I
should be more actively developing Rails.

I've been giving it some thought, and I think the best approach is to
write a new architecture (mostly) from the ground up, rather than
migrating our existing code into a client/server paradigm.

There are several reasons why I want to incorporate refactoring the
code into adding such a major new feature. One of the primary reasons
is that it will give me a chance to revisit the UI, the hex drawing
code, and many other areas of the codebase, and look at these things
with a fresh perspective. It's also a chance to clean up and organize
the code in ways that are difficult currently.

One thing that I want to make perfectly clear. I'm absolutely not
throwing out our existing code.

What I _am_ doing is starting from a new, empty project directory on
my workstation, writing a basic client and server, then slowly moving
our existing code in, one piece at a time. During this process, I'll
be cleaning up many areas of the code, and rewriting a couple of
things from scratch.

As soon as I have a basic framework, I'll publish a new module into
CVS so that everyone can jump in and help get network play fully
functioning.


---Brett.

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

[Dave M. <da...@mi...>]

On 8/6/2008 06:30 PM, Erik Vos 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).
>
>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.
>
>My question is rather how to transfer such serialized objects between client
>and server, or applet and server, or whatever.
>
>...
>
>Erik.

I don't know what other mechanisms have been considered, but
Sun's JINI can pass objects. and deal with the clienr/server issues.

I spent a few months trying to learn it but gave up when other 
opportunities arose.
It tapped into a lot of heavy weight distributed communication 
features that I recognized their value from my software development 
experience, but found a bit daunting to learn all at once in a new platform.

It's more of a framework than a package.

FWIW...

Dave. 

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

[Jeffrey B. M. <mc...@br...>]

On Sat, Aug 09, 2008 at 08:44:13PM +0200, Erik Vos wrote:
> 
> I like that concept. Will certainly have a closer look at Jabber later on.
> Not having to set up a comms server saves a lot of trouble.
> Security looks a lot simpler that way.

For a point of reference, VASSAL's messaging is at least partway Jabber
underneath (I don't remember if they ever finished the conversion)

Jeff

-- 
----------------------------------------------------------------------------
"The man who does not read good books has no advantage over 
 the man who cannot read them."
 -- Mark Twain
----------------------------------------------------------------------------

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

[Erik V. <eri...@hc...>]

> > 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.

I like that concept. Will certainly have a closer look at Jabber later on.
Not having to set up a comms server saves a lot of trouble.
Security looks a lot simpler that way.
 
Erik.

Re: [Rails-devel] [18xx] Rails

[John A. T. <ja...@ja...>]

On Thu, 7 Aug 2008, brett lentz wrote:

> The down side, of course, is that we'd need to rewrite all of the GUI
> code.  The GUI code isn't great, but it's currently functioning enough
> to be usable.
>
> Unless John is volunteering to do the porting, I don't really see
> where this suggestion moves the project forward. Tossing out our
> currently functioning GUI code and redoing the same thing over again
> rather than working on either adding new features or improving
> existing capability just doesn't seem very productive to me.

I was just offering an alternative to Java applets, which I believe would 
entail signicant changes to the UI anyway, but I agree it would be better 
to add network play to the existing code and just require people to run a 
jar from the command line if they want to play.

--
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                 		 		Smyrna, GA  30082-3723

Re: [Rails-devel] [18xx] Rails

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

On Thu, Aug 7, 2008 at 2:01 PM, John A. Tamplin <jat...@ja...> wrote:
> On Thu, 7 Aug 2008, Erik Vos wrote:
>
>> That sounds like an interesting option. How is client-server communication
>> organized in this concept?
>
> It looks like normal Java RPC, except that the RPC is async (ie, you get
> callbacks when it returns).
>
>> A problem we would have with plain HTTP is, that the server will send
>> unsolicited messages (i.e. updates from moves by other players).
>
> This can be done with Comet or hanging gets.
>
> One other benefit I didn't menion is that you can debug the client code in
> Eclipse (or other IDE) as easily as your server code.
>


The down side, of course, is that we'd need to rewrite all of the GUI
code.  The GUI code isn't great, but it's currently functioning enough
to be usable.

Unless John is volunteering to do the porting, I don't really see
where this suggestion moves the project forward. Tossing out our
currently functioning GUI code and redoing the same thing over again
rather than working on either adding new features or improving
existing capability just doesn't seem very productive to me.


> --
> John A. Tamplin                                 ja...@ja...
> 770/436-5387 HOME                               4116 Manson Ave
>                                                Smyrna, GA  30082-3723
>


---Brett.

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.

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

[Erik V. <eri...@hc...>]

 

> -----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.
 
> 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.
 
> > 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....

Re: [Rails-devel] [18xx] Rails

[John A. T. <jat...@ja...>]

On Thu, 7 Aug 2008, Erik Vos wrote:

> That sounds like an interesting option. How is client-server communication
> organized in this concept?

It looks like normal Java RPC, except that the RPC is async (ie, you get 
callbacks when it returns).

> A problem we would have with plain HTTP is, that the server will send
> unsolicited messages (i.e. updates from moves by other players).

This can be done with Comet or hanging gets.

One other benefit I didn't menion is that you can debug the client code in 
Eclipse (or other IDE) as easily as your server code.

--
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                 		 		Smyrna, GA  30082-3723

Re: [Rails-devel] [18xx] Rails

[Erik V. <eri...@hc...>]

Hi John,

That sounds like an interesting option. How is client-server communication
organized in this concept?
A problem we would have with plain HTTP is, that the server will send
unsolicited messages (i.e. updates from moves by other players).

I think this could be a further development, after we have split off our
current UI to a separate client.

Erik.

> -----Original Message-----
> From: rai...@li... 
> [mailto:rai...@li...] On Behalf 
> Of John A. Tamplin
> Sent: Wednesday 06 August 2008 20:51
> To: Dev...@sc...; 
> li...@sc...; 
> fo...@sc...; 
> "Ra...@sc...":an 18xx game
> Subject: Re: [Rails-devel] [18xx] Rails
> 
> On Tue, Aug 5, 2008 at 12:18 PM, Erik Vos <eri...@hc...> wrote:
> 
> > I could also start working towards a version that would 
> allow on-line play
> > in some form or shape. As we already have a complete 
> graphical interface
> > programmed in Java, the simplest approach might be to split 
> the existing
> > system in a client and a server part (in fact, I already 
> have been gradually
> > working towards such a split for the last 2 years, but it 
> is far from done).
> > For the user interface this could lead to either a Java 
> client program, to
> > be installed on local PCs, or a Java applet, that could be 
> accessed over the
> > Web. However, Java applets are notorious for their long download and
> > initialization times, so I don't know if working with such 
> an applet would
> > be an appealing foresight for many people.
> >   
> Another option is Google Web Toolkit for the client side.  You can't 
> take the existing UI code and port it, but you can write in a 
> familiar 
> style and then have the GWT compiler translate it to 
> Javascript to run 
> in the browser.  Now applets to download, no requirement to have Java 
> installed, etc.  If you are interested in further discussion 
> about it, I 
> would be happy to fill in the details as I work on it for Google.
> 
> --
> John A. Tamplin					ja...@ja...
> 770/436-5387 HOME				4116 Manson Ave
>                 		 		Smyrna, GA  30082-3723
> 
> 
> --------------------------------------------------------------
> -----------
> 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
> 

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
>

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

[Erik V. <eri...@hc...>]

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?

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.

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

Erik.

> -----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
> 

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.

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

[Erik V. <eri...@hc...>]

> 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).

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.

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.

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?


Erik.

Re: [Rails-devel] [18xx] Rails

[John A. T. <ja...@ja...>]

On Tue, Aug 5, 2008 at 12:18 PM, Erik Vos <eri...@hc...> wrote:

> I could also start working towards a version that would allow on-line play
> in some form or shape. As we already have a complete graphical interface
> programmed in Java, the simplest approach might be to split the existing
> system in a client and a server part (in fact, I already have been gradually
> working towards such a split for the last 2 years, but it is far from done).
> For the user interface this could lead to either a Java client program, to
> be installed on local PCs, or a Java applet, that could be accessed over the
> Web. However, Java applets are notorious for their long download and
> initialization times, so I don't know if working with such an applet would
> be an appealing foresight for many people.
>   
Another option is Google Web Toolkit for the client side.  You can't 
take the existing UI code and port it, but you can write in a familiar 
style and then have the GWT compiler translate it to Javascript to run 
in the browser.  Now applets to download, no requirement to have Java 
installed, etc.  If you are interested in further discussion about it, I 
would be happy to fill in the details as I work on it for Google.

--
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                		 		Smyrna, GA  30082-3723

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

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

Moving this thread over to the appropriate list....   ;-)


On Tue, Aug 5, 2008 at 12:18 PM, Erik Vos <eri...@hc...> wrote:
>> But all considered what I would really like to see, are
>> online play capabilities added to Rail for remote real time playing.
>> That would be a real breakthrough in the hobby.
>
> Online play is certainly in scope for Rails, but I can't tell when it will
> happen.
> I'm currently the only (somewhat) active developer, and these days other
> hobby and non-hobby activities take most of my time.
>
> I'm actually on a crossroads as how to proceed with Rails. I could first
> work towards completion of some half-done games (1856, 1835, 1870) in the
> current (hot-seat only) version (earlier this year some interest in 1856 has
> surfaced). That is the easy road.
>
> I could also start working towards a version that would allow on-line play
> in some form or shape. As we already have a complete graphical interface
> programmed in Java, the simplest approach might be to split the existing
> system in a client and a server part (in fact, I already have been gradually
> working towards such a split for the last 2 years, but it is far from done).
> For the user interface this could lead to either a Java client program, to
> be installed on local PCs, or a Java applet, that could be accessed over the
> Web. However, Java applets are notorious for their long download and
> initialization times, so I don't know if working with such an applet would
> be an appealing foresight for many people.
>

My preference would be to finish off the games we've partially
implemented, get a "base" set of games into a playable state, and then
move on to doing the client/server split.

However, if you're eager to move on to more interesting work, we can
always come back to adding more games later. ;-)


> There are several ways in which a local client program could communicate
> with a central server. One perhaps unusual way could be near-real time
> communication via SMTP/POP3 (e-mail) - this way we could have PBEM as an
> extra bonus. Not sure if other communication methods are so easy as they
> sound - having a server listening on an Internet port has security
> implications that I can't assess - I'm a novice in that matter.
>

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.

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.

> Apologies to those who find this post a bit too technical. The technical
> details can better be discussed in the Sourceforge Rails maillist, or in the
> 18xx-softdev Yahoo group. But I'm now mainly interested in thoughts on the
> general line of development that Rails might take in the near future.
>
> Erik.
>
>

---Brett.