Re: [glob2-devel] YOG system update

[Martin Voelkle]

> I'm just sending out what I have for my YOG system, feel free to
> download the patches and take a look at the code. The first patch is
> exclusivly the YOG stuff, all 10 of my changsets for it.
>
> The second patch is the game engine stuff that I had done first. I'm
> not sure if you need the second to do the first, but I do know that
> they don't modify conflicting files (the first patch mostly adds new).
> I still don't know how mercurial will deal with this, but I hope that
> it will allow one to just import the YOG stuff. If not, import the
> other stuff first.
>
> The new YOG system is being done in the following header/source pairs:
>     NetConnection, NetListener, NetMessage, YOGGameServer, YOGPlayer,
> YOGClient, & NetTestSuite
>
> And I also made a change to YOGConsts, commenting out the current
> consts and replacing them with my own.
>
> Note that its not going to compile, no matter how you import the
> changes. I haven't even attempted compiling the code yet, so there are
> probably allot of small errors I have overlooked. Plus the fact that
> it doesn't yet integrate into Glob2 yet, and the changes in YOGConsts
> will have a rippling effect.
>
> So far I've got the low level communication classes done, and some of
> the YOG communication done. I haven't implemented the RSA encryption
> of passwords yet, and I haven't implemented password stoarge on the
> server yet either. Yet most of the communication is functional, and
> sends only a few bytes of data, making the protocol very compact.

Since you are going for TCP and want encryption, I suggest using a
standard protocol, like TLS or SSL. The GNU TLS library is
license-compatible with Glob2 and has an active windows port.

> I've chosen to model the client as much as a self contained system as
> possible. Right now, it sets a state that it needs login information,
> and another object (presumably the caller) has to check this state,
> and provide it with login information. This means that the YOGClient
> requires other code to function, but that other code can be anything
> and is entirely external. Usually, this would be the GUI. After it
> sees the request for login information, it would retrieve it from the
> user.

This looks like a standard controller/UI separation. Instead of having
the UI peek at the YOGClient state, it could be better to use an
asynchronous pattern between the UI and the YOGClient: UI methods take
callback arguments to be executed when the UI has the required
information. This way, the YOGClient is in control of the flow of
execution. Otherwise, you get an inversion of control which is quite
ugly: the UI has to make control decisions (decide what to do next)
based on the state of the YOGClient (using a giant switch, of course).

> Comments & suggestions are welcome.

Good work! I'll take a look at the code after work (it's only 10 am here).

Martin