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.