Re: [Openrpg2 dev] OpenRPG2 current status, and module design

[Mark T. <ma...@ly...>]

Thanks,

One more thing, also...

I notice that the server has a GUI....   how major of a change would it 
be to make the server work in a headless environment.  While many people 
may be satisfied with it taking up a window, I would expect that not 
everyone would be.   Such a headless server need only log text output 
normally, and should not have a gui.   Ideally, we could use a separate 
program which talks to the server on a localhost, and which may act as a 
gui environment for people who want to have a user interface over a 
server that has no UI.

Mark


On 11/14/2013 04:17 PM, Snowdog wrote:
> I’ll tackle these inline… so see below.
>
> On Nov 14, 2013, at 1:54 PM, Mark Tarrabain <ma...@ly...> wrote:
>
>> Hey,
>>
>> Well, a recent and rather unexpected change in my employment status has
>> opened up my schedule a whole lot, and since I've really wanted to do
>> some work on this, I might as well take advantage of the time I have
>> right now to do so.
>
> Ironically the exact opposite has happened to me. I’m starting a new job and loosing lots of time. :-/
>
>> So... first things first.
>>
>> It seems there is some sort of logical error in the client-server
>> connectivity, since I cannot seem to disconnect from a server that I've
>> connected to.
>
> The client side network module is new, and admittedly lacks some polish to put _very_ kindly. ;-)
> Yes, there indeed is a disconnection issue. The client/server do indeed disconnect,
> but they do so on their own whims (or so it seems). Its a thread based timing thing i believe.
> The async nature of the network code poses some _significant_ challenges to what
> would be otherwise simple setup/teardown of the network pipe. We have to arbitrarily wait
> while other modules do their syncing before actually shutting down the pipe.
>
> I’ll be the first to admit, sometimes I think I’ve dug myself into a huge hole with this design,
> but other times things slips together so simply and easily I know its going to work great
> down the road. All the hard stuff is up front, once thats handled module writers should
> have a simple time of adding to this design. Till then though… expect to loose hair lol.
>
>
>> Also, it's been a while since I looked at the code here and I'm not sure
>> I'm getting my brain wrapped around how the whole system is structured.
>
> Yeah, the base structure is…. different. Because of the multi-threaded modular nature of the core
> it makes visualizing how things work difficult. I’ll try to boil it down for you. Remember this is all OOD/P so there is little in the way of a ‘flow’ to follow.
> I’ll reference key classes as I go...
>
> Basically, we have 3 subsystems (Layers) that each run in its own thread by the “Engine” (common.core.engine.Engine)
> 1) Network Layer (common.core.network.NetworkServer & common.core.network.NetworkClient)
> 	The network manages all connections and network I/O using a pool of worker threads
> 	The network sends/receives ORPGMessages (common.core.ORPGMessage) to/from the Module Layer
> 2) Module Layer
> 	All features of the system are ‘Modules’, i.e. ‘chat module’, ‘whiteboard module’, etc.
> 	All modules register with the ModuleManager (common.core.engine.ModuleManager) via the module loader (server.core.ServerModuleLoader & client.core.ClientModuleLoader)
> 	They register what types of messages they receive & send, register interest in other modules, register gui components, etc with the Module Manager.
> 	This is a key point…. Modules CANNOT interact directly with other modules, they MUST go through the ModuleManager.
> 3) GUI Layer (common.core.gui.GUIManager)
> 	All GUI components for registered modules and handled as JPanels by a GUIManager.
> 	Each panel is controlled and managed by its respective owning module.
>
>> Snowdog, could you please walk me through how the module system works,
>> exactly?   What does a client and server have to do to register a
>> module?
>
> Eventually we will be able to dynamically load modules, but currently only ‘core’ static
> modules are loaded via the respective module loader (server.core.ServerModuleLoader & client.core.ClientModuleLoader)
>
> The module loader then instances the module and calls its doRegistration() method (see bottom of ExampleClientModule.java).
> The module class handles it’s own registering with the ModuleManager.
>
>> How does a client module send or receive data from the server,
>> and how does a module on the server send or receive data from clients?
>
> Check out the Example modules (client.core.modules.ExampleClientModule )
> Messages between the client/server or client/client(s) is accomplished using a simple header/data structure (based on a TCP/IP packet design)
> 1) Create an ORPGMessage
> 2) Set the message type so the receiver(s) know what module this is destined for
> 3) Set any header data [optional, but useful for small messages]
> 4) Set data payload [optional]
> 5) Create a MessageAddress (contains details for delivery of message) and set the destination for the ORPGMessage
> 6) Push the ORPGMessage to the ModuleManager via sendToNetwork() call.
>
> Note: The data payload will be sent as binary so the structure of the data is up to individual modules.
> Could be text, XML, binary, JSON, etc. As the data portion of the message will only be parsed by the
> receiving module (and then only if needed presumably) it greatly cuts down on message parsing times
> (as only header is parsed)
>
>> I am thinking of working on the chat/channel system, if you haven't
>> already started on that.
>
> I have not started on either as all of my work has been much lower level.
>
>> Once that's complete, I will work on a channel-based whiteboard that can
>> be viewed by all within the channel, which will ultimately function as
>> the channel's map.
>>
>> Mark
>
> It should be noted that the server does not need to have a module for a given module.
> As it only parses the message header (for addressing info) it does not NEED to handle the message,
> only route it to the correct client. This means that technically, you only need a client side module for most tasks.
>
> The server contains a special ‘fallback’ module called ‘DefaultRelay’ that accepts all unknown messages and simply forwards them based on their MessageAddress data.
>
> let me know if you need any more info.
>
>
> --Snowdog
>
>
>
>
>
> ------------------------------------------------------------------------------
> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> Free app hosting. Or install the open source package on any LAMP server.
> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> _______________________________________________
> Openrpg-v2-dev mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openrpg-v2-dev
>
>
>