Thread: Orion Framework (initial release)

Page 1 of 5 123 ... LastLast
Results 1 to 10 of 45
  1. #1 Orion Framework (initial release) 
    Renown Programmer and Respected Member
    Maxi's Avatar
    Join Date
    Jun 2008
    Posts
    3,197
    Thanks given
    281
    Thanks received
    1,095
    Rep Power
    1366
    For the past couple of days I have been working on a new framework. The reason I started writing a new framework is that I came across few roadblocks within my old designs and for this framework I've changed the design drastically.

    Currently the project's hierarchy looks like this:



    NOTE: This framework is in an early stage of development and should be considered to be used when you want a learning experience or a stable base to start from almost complete scratch. The basics of this framework are written very well, but it has no content so far.

    The framework is documented troughout almost all methods and classes. Note here that some javadocs are outdated as I did not update them when I changed minor and major things.

    Thread model.

    There are three major tasks being performed within the framework (exluding netty's networking):
    1. Packet handling - accessing resources
    2. Packet encoding - reading resources
    3. Game updates - reading and writing resources


    Netty's first decoder will first fragment the incoming stream into multiple frames. The second decoder will create a packet object, read the stream in the given order and then call the packet's resource handling method. This handling is done on a single thread and will wait if a game update is being executed to continue.

    Packet encoding is done on a multi threaded executor. Commands are executed with a neat system and object will be created and passed onto the last netty encoder. This encoder will transform the object into a ChannelBuffer and send it downstream, eventually to the remote peer.

    Game updates are done on a single thread. This doesn't need alot of explanation except that a game update will wait if a packet is being handled before it starts executing its actual logic. The game update will use the packet encoding executor for its encoding demands.

    Usage.

    As explained before, this framework doesn't include any actual game logic handling. All it provides is a neat packet decoding and encoding system with smart logic separation. Future releases will contain a fully functional game update system and some handled pre login and in game packets. So far it's designed to work with all the RT3 and RT4 engines. Future releases might contain a login server and maybe an upgrade to work with the RT5 engines (with of course a lobby server and a full gpi update system).

    If used to gain some ideas to involve in your own framework or if you have any constructive criticism please let me know. If you find any bugs I'd be glad to be pointed towards them. Anyone complaining about my names, stand up if it might be any constructive.

    Features.

    - Update protocol ; Sending reference tables checksum works fine, normal file requests still need some work and a new system.

    - Cache reader ; Used for the update protocol and reading cache files, currently succesfully reads all object definitions.

    - Complete networking, core handling etc.

    Download.

    Download Orion Framework.rar (initial release) here

    This release is the initial release.

    Download Orion Framework.rar REV#1

    This release contains some improvements on my netty implementation as pointed out by Method.

    Download Orion Framework.rar REV#2

    Added some pre login packets, client will now load normally.

    Download Orion Framework.rar REV#3

    Added a cache file system to read the cache and use the update protocol. Not that you will have a cache to have this working, the cache files should be in "data/cache/packed/". This version has a bug in the file request parser, the client won't accept the normal files. It will read the reference table checksum properly from the cache and the client will accept it. The object definition loader works a 100% but the landscape file loader needs some fixes. Also the update system I've applied needs to be ported to one of my old systems, as this one is not a 100% accurate.
    Just don't use the update server yet, except for the 'update keys' calculation. Make sure your client has a cache to read.

    Download Orion Framework.rar REV#4

    Update server file pushing is now moved to a single thread to ensure the order the files are sent in. Still need to fix the file request encoding.

    Download Orion Framework.rar REV#5

    Added RSA decryption to the login block.

    Credits:

    Method - used his refactored client as a reference + constructive criticism.
    Other - some credits are in the framework although there are not many.
    Reply With Quote  
     

  2. #2  
    Donator

    Ecstasy's Avatar
    Join Date
    Sep 2008
    Age
    29
    Posts
    5,031
    Thanks given
    324
    Thanks received
    596
    Rep Power
    843
    good job maxi

    Reply With Quote  
     

  3. #3  
    Community Veteran



    Join Date
    Jan 2008
    Posts
    3,444
    Thanks given
    46
    Thanks received
    973
    Rep Power
    4748
    nice base

    Reply With Quote  
     

  4. #4  
    Hi.

    'Mystic Flow's Avatar
    Join Date
    Nov 2007
    Posts
    7,146
    Thanks given
    256
    Thanks received
    1,252
    Rep Power
    3714
    Great fucking job Maxi .



    Reply With Quote  
     

  5. #5  
    Renown Programmer
    Method's Avatar
    Join Date
    Feb 2009
    Posts
    1,455
    Thanks given
    0
    Thanks received
    845
    Rep Power
    3019
    The first thing that stands out is that your pipeline seems poorly designed. Your encoders and (more importantly) decoders should be before the handler in your pipeline, which should be the one performing the necessary handling/processing on the received data.

    PLPObjectDecoder and PLPStreamMultiplexer also seem kind of redundant. One decoder should be able to accomplish reading a complete packet and pass it on to the handler to be processed from there.

    Other than that, it look like a decent start. Good luck if you plan on continuing it.

    edit: Interestingly enough, I had called my own server framework Orion also. However, I haven't done much work on it anyways.
    :-)
    Reply With Quote  
     

  6. Thankful user:


  7. #6  
    Renown Programmer and Respected Member
    Maxi's Avatar
    Join Date
    Jun 2008
    Posts
    3,197
    Thanks given
    281
    Thanks received
    1,095
    Rep Power
    1366
    Quote Originally Posted by Method View Post
    The first thing that stands out is that your pipeline seems poorly designed. Your encoders and (more importantly) decoders should be before the handler in your pipeline, which should be the one performing the necessary handling/processing on the received data.
    I placed the handler first with the intention of closing new channels that I don't want to be bound and opened (i.e. maintenace of the amount of connections from one host). If placed last in the pipeline, the decoders would first perform decoding work. Wouldn't that be a waste?

    Quote Originally Posted by Method View Post
    PLPObjectDecoder and PLPStreamMultiplexer also seem kind of redundant. One decoder should be able to accomplish reading a complete packet and pass it on to the handler to be processed from there.
    What I'm doing is simply splitting the message into frames in the PLPStreamMultiplexer and passing them onto the PLPObjectDecoder to be decoded into a packet object and execute its resource handling. Sometimes it happens more than one frame is sent as a packet. I see your point, but instead of passing it onto a handler (you call it a handler, but aren't they all handlers, but the one you're talking about an upstream and a downstream handler?) I pass it onto the PLPObjectDecoder which performs the creation of the packet object + its execution of handling.

    Using a simple handler could be some events less, but handling a packet that contains several frames in one handler would be the same work as the PLPStreamMultiplexer does, wouldn't it?

    Quote Originally Posted by Method View Post
    Other than that, it look like a decent start. Good luck if you plan on continuing it.

    edit: Interestingly enough, I had called my own server framework Orion also. However, I haven't done much work on it anyways.
    Thanks.
    Reply With Quote  
     

  8. #7  
    Renown Programmer
    Method's Avatar
    Join Date
    Feb 2009
    Posts
    1,455
    Thanks given
    0
    Thanks received
    845
    Rep Power
    3019
    Quote Originally Posted by Maxi View Post
    I placed the handler first with the intention of closing new channels that I don't want to be bound and opened (i.e. maintenace of the amount of connections from one host). If placed last in the pipeline, the decoders would first perform decoding work. Wouldn't that be a waste?
    The decoder doesn't handle connection messages such as those sent when a channel is opened, bound, connected, etc. Once those have been processed by the handler (your ConnectionStateHandler in this case), data sent between the client and server will be processed through the decoder, which will decode the data into a packet, and then passed onto the handler. From there, you can handle it how you please.

    Quote Originally Posted by Maxi View Post
    What I'm doing is simply splitting the message into frames in the PLPStreamMultiplexer and passing them onto the PLPObjectDecoder to be decoded into a packet object and execute its resource handling. Sometimes it happens more than one frame is sent as a packet. I see your point, but instead of passing it onto a handler (you call it a handler, but aren't they all handlers, but the one you're talking about an upstream and a downstream handler?) I pass it onto the PLPObjectDecoder which performs the creation of the packet object + its execution of handling.

    Using a simple handler could be some events less, but handling a packet that contains several frames in one handler would be the same work as the PLPStreamMultiplexer does, wouldn't it?
    The point is that you should separate the decoding and handling of a packet. A decoder should:

    • See if there is any data in the buffer.
    • If so, read the opcode of the message sent.
    • See how much data the packet contains besides the opcode (if any) by checking the array you have or whatever means of storing packet information you use.
    • If all of the packet data is there, read the data and return the packet for use in the handler. Otherwise, reset the reader index to before you read the opcode (and make sure the ISAAC cipher isn't out of sync) and wait for another message.


    Multiple packets sent at once should be handled fine considering Netty doesn't throw away any data unless you read bytes and forget to reset a ChannelBuffer's readerIndex.

    As for handling the packet in PLPObjectDecoder, you really should have your ConnectionStateHandler doing that. Having the decoder decode a packet and handle it is more than should be done by it.
    :-)
    Reply With Quote  
     

  9. Thankful user:


  10. #8  
    Registered Member

    Join Date
    Aug 2009
    Posts
    1,712
    Thanks given
    96
    Thanks received
    198
    Rep Power
    78
    Might have a look at it, nice
    removed
    Reply With Quote  
     

  11. #9  
    Renown Programmer

    Sean's Avatar
    Join Date
    May 2007
    Age
    32
    Posts
    2,757
    Thanks given
    264
    Thanks received
    1,090
    Rep Power
    4393
    good start maxi but i done my netty implement a little different in typhoon
    Reply With Quote  
     

  12. #10  
    Renown Programmer and Respected Member
    Maxi's Avatar
    Join Date
    Jun 2008
    Posts
    3,197
    Thanks given
    281
    Thanks received
    1,095
    Rep Power
    1366
    Quote Originally Posted by Method View Post
    The decoder doesn't handle connection messages such as those sent when a channel is opened, bound, connected, etc. Once those have been processed by the handler (your ConnectionStateHandler in this case), data sent between the client and server will be processed through the decoder, which will decode the data into a packet, and then passed onto the handler. From there, you can handle it how you please.



    The point is that you should separate the decoding and handling of a packet. A decoder should:

    • See if there is any data in the buffer.
    • If so, read the opcode of the message sent.
    • See how much data the packet contains besides the opcode (if any) by checking the array you have or whatever means of storing packet information you use.
    • If all of the packet data is there, read the data and return the packet for use in the handler. Otherwise, reset the reader index to before you read the opcode (and make sure the ISAAC cipher isn't out of sync) and wait for another message.


    Multiple packets sent at once should be handled fine considering Netty doesn't throw away any data unless you read bytes and forget to reset a ChannelBuffer's readerIndex.

    As for handling the packet in PLPObjectDecoder, you really should have your ConnectionStateHandler doing that. Having the decoder decode a packet and handle it is more than should be done by it.
    Thanks for clearing that up for me .
    Besides my netty implementation, what do you think of my logic separation and packet handling/encoding?
    Reply With Quote  
     

Page 1 of 5 123 ... LastLast

Thread Information
Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)


User Tag List

Posting Permissions
  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •