EnigmaTransmission

I posted previously about the need for a session management library for Enigma. I now realize that there is a need for a transmission library as well that can be called by the session library and the reverse is also possible in cases where the server or client needs to be notified. The reason for this is that currently all the transmission logic is inside of the client & server binaries. This is a problem because I intend to make a console client for testing purposes. Also I'm seeing the importance of modularity more and more. The nice thing about this is that this will allow anyone wanting to reuse some of this code to break out the pieces they like.

My fear at this point is over engineering this thing to the point where I'm working against myself. However the current system isn't working and once again it is growing to the point where my bad design decisions are coming back to haunt me. I think my initial approach would have been fine for smaller projects but it just gets crazy with all those callbacks and interdependencies.

As for the interaction between the transmission and session libraries my plan is to completely encapsulate enet inside of the transmission library such that no library outside of it needs to link the enet library. Next I plan to only pass type safe message objects to the session manager from the transmission manager. At that point the session manager doesn't need to know about peers or channels or anything of that nature so I will be moving the channel header from common to transmission or at least copying it. I will likely pass a peerId to the session manager so it can inform the transmission layer knows who to send packets to. However whether or not the user is logged in should be stored in the session manager. That way the transmission layer can be relatively stateless aside from keeping the peerId and the associated peer object. As well as the enet objects needed for transmission.


Another benefit of this design is that because the objects lack internal functionality and simply maintain state it shouldn't be too hard to make them thread safe with a few locks here and there. This will allow my to thread the server and client without too much issue. Most graphics engines are single threaded but all that thread needs to do is sync the scene graph to my objects and render them. All other calculations, updates, etc can be done in different threads. This would allow things like AI & physics to operate on the state machine independently of the rendering loop.

Alright thats enough for now I have to get some sleep, thanks for reading.

Comments

Popular posts from this blog

VK9 - Milestone8 Completed

VK9 - Milestone13 Completed

VK9 - Milestone16 Completed