Best way to catch Messages.

Results 1 to 6 of 6
  1. #1
    Member Amariconao is offline
    MemberRank
    Nov 2011 Join Date
    62Posts

    Best way to catch Messages.


    RaGEZONE Recommends

    RaGEZONE Recommends

    Hello,

    It's about saying which you think is best and why.

    1.- The "classic". When we get a message we just call the requests class, exactly to the map and we have it execute, without opening another thread, in the same as the user-connection. An example of this is Icarus from Quackster.
    Code:
       
    // OnMessage:
        @Override
        public void messageReceived(ChannelHandlerContext ctx, MessageEvent e) {
    
            try {
    
                Player player = (Player) ctx.getChannel().getAttachment();
                NettyRequest request = (NettyRequest) e.getMessage();
    
                if (request == null) {
                    return;
                }
    
                if (Util.getConfiguration().get("Logging", "log.packets", Boolean.class)) {
                        Log.println("Received: " + request.getMessageId() + " / " + request.getMessageBody());
                }
    
                if (player != null){
                    Icarus.getServer().getMessageHandler().handleRequest(player, request);
                }
    
            } catch (Exception ex) {
                Log.exception(ex);
            }
        }
    
    public void handleRequest(Player player, ClientMessage message) {
            if (messages.containsKey(message.getMessageId())) {
                messages.get(message.getMessageId()).handle(player, message);
            }
        }



    2.- This method I have seen and I have programmed it and it is not difficult at all. It consists of creating a Queue list of an object(QueueItem)that contains the session and the clientmessage. When a request arrives we create a queue object that we store in the QueueMessages list. On the other hand there is a pool of threads picking up these messages and executing them (Sync problem detected). An example:

    I get the package with header 4000.
    RequestMessage.QueueList.add (new QueueItem (session, clientmessage))


    On the other hand, the pool of threads would be in a continuous loop, such as:

    While (alive) {
    NextQueue = RequestMessages.QueueList.Dequeue ()
    Message = nextQueue.message
    Session = nextQueue.session

    RequestMessages.MessageList.get (message.header) .execute (session, message)

    wait(DELAY_TIME)
    }


    I do not know if I have explained myself completely, I hope you can understand what I mean.


  2. #2
    Member HabboTugaa is offline
    MemberRank
    Aug 2007 Join Date
    Somewere in this universe...Location
    78Posts

    Re: Best way to catch Messages.

    If you don't want active waits and/or sync issues, you should probably be using monitors. Multithreading isn't really simple, but it is easy once you get the hang of it. This way, you'd put the thread to sleep, and once it recieves something you notify it to get going. No need to actively wait for anything, nor to waste processing cycles.

    Here's the documentation on Condition, which give you even more flexibility on Java monitors.
    This is the universe, you know? Nice sequence of events, lad.

  3. #3
    Death from above! The General is offline
    The OmegaRank
    Aug 2011 Join Date
    8,852Posts

    Re: Best way to catch Messages.

    Is this a question or something?

    There are multiple ways you can handle messages, queue them to a thread pool, handle them straight away or do whatever you want.
    If you are using Arcturus, contact me
    Skype: wesley.jabbo
    Discord: TheGeneral#0063

  4. #4
    Member Amariconao is offline
    MemberRank
    Nov 2011 Join Date
    62Posts

    Re: Best way to catch Messages.

    Quote Originally Posted by HabboTugaa View Post
    If you don't want active waits and/or sync issues, you should probably be using monitors. Multithreading isn't really simple, but it is easy once you get the hang of it. This way, you'd put the thread to sleep, and once it recieves something you notify it to get going. No need to actively wait for anything, nor to waste processing cycles.

    Here's the documentation on Condition, which give you even more flexibility on Java monitors.
    I dont know that, i never see condition wow, its really amazing. I will study that :$

    - - - Updated - - -

    Quote Originally Posted by The General View Post
    Is this a question or something?

    There are multiple ways you can handle messages, queue them to a thread pool, handle them straight away or do whatever you want.
    Its a "debate" wich you should say what form u prefer to execute messages, and u think what is the best way for you

  5. #5
    topkek amirite?? Leon is offline
    True MemberRank
    May 2009 Join Date
    918Posts

    Re: Best way to catch Messages.

    In the example you showed regarding Icarus, it uses Netty. Under the hood, Netty processes events in a queue. You can define whether you want to use multiple queues for user events, IO events etc (aka loop groups) so it would be pretty damn pointless pushing those events to another queue (Comet supports handling messages in the current thread, handling them in another pool etc, feel free to take a look.. I don't recommend using any other method of handling messages other than the default method in production though; after much testing, I figured letting the Netty event loop handle it was the best way).

    In other cases, if the message is initially read in the IO threads, you want to be pushing those messages to another queue to take the load away from the IO threads.

    So yeah.. It honestly depends on so many other things. You might want to do some research into how your networking stack works if you want to squeeze every ounce of performance out of your code.
    Last edited by Leon; 16-06-17 at 01:17 PM.

  6. #6
    Member Amariconao is offline
    MemberRank
    Nov 2011 Join Date
    62Posts

    Re: Best way to catch Messages.

    Quote Originally Posted by Leon View Post
    In the example you showed regarding Icarus, it uses Netty. Under the hood, Netty processes events in a queue. You can define whether you want to use multiple queues for user events, IO events etc (aka loop groups) so it would be pretty damn pointless pushing those events to another queue (Comet supports handling messages in the current thread, handling them in another pool etc, feel free to take a look.. I don't recommend using any other method of handling messages other than the default method in production though; after much testing, I figured letting the Netty event loop handle it was the best way).

    In other cases, if the message is initially read in the IO threads, you want to be pushing those messages to another queue to take the load away from the IO threads.

    So yeah.. It honestly depends on so many other things. You might want to do some research into how your networking stack works if you want to squeeze every ounce of performance out of your code.

    Male lion neither more nor less than I like this doubt seeing how he executed comet the messages. PS: Execelt job with that;)




Advertisement