Thread: [ELVARG] Random DCs?

Page 1 of 2 12 LastLast
Results 1 to 10 of 16
  1. #1 [ELVARG] Random DCs? 
    Hella Hard Homie


    Join Date
    Jan 2011
    Posts
    584
    Thanks given
    163
    Thanks received
    41
    Rep Power
    111
    Hey everyone,

    A while back I started working on my own Elvarg project, unfortunately I just recently discovered some bugs regarding random DCs, this seems to happen very fast (normally I am used to DCs happening after an unresponsive period of nearly 10 seconds, but this seems to happen after incoming/outgoing packets were send mere seconds ago)

    No errors are printed or special actions take (there used to be some mismatches in the UseItem packet and 1-2 others I believe, I have fixed those)

    Things to take into account:
    -I have ran 2 different sources on the same machine (simultaniously as well), the DCs only happen on Elvarg and not on the second (Vencillio based) server.
    -Sometimes I am able to AFK for hours on end, but when I get back to my computer I can rapidly DC several times after each other in a short period of time.

    I also somehow feel this might be related to the amount of players in your region (but this could be a hoax, as this has never happened to me when playing on a localhost connection, just when connecting to a remote server)

    I have also ran it on 2 seperate VPS'es with the same result.

    I am also not the only one who gets these DCs from time to time, which makes me believe it is not related to me, or the VPS, which should leave Elvarg.

    I have very (very) little experience with networking, and besides knowing how its spelled I have no clue what Netty's advantage is over their counterparts (and who they even are)

    My attempt to fix this was by prolonging the disconnect from happening, in Vencillio I recall changing a timeout somewhere where the player would only be kicked after no response was received in 9 game ticks (I improved this number myself, but the 9 game ticks is an estimated guess, I dont fully recall the exact value)
    I tried recreating this in Elvarg, but could not find similar code (except for a ChannelHandler timeout, which was set to 45 seconds and I changed it to 60 (this did not seem to have any (or the desired) effect))


    Hopefully some of you whizzkids can point me into the right direction on this


    EDIT: A second note: when uploading files to the VPS (and being logged in), when the complete upload is done, I feel as if my connection to the VPS is somehow cleared, as that usually triggers a DC as well.
    Last edited by Aekramer; 06-19-2019 at 12:58 PM. Reason: additional note
    [Only registered and activated users can see links. ]

    Quote Originally Posted by Winston Churchill
    "Success is the ability to go from one failure to another with no loss of enthusiasm"
    Austin still owes me $43
    Reply With Quote  
     

  2. #2  
    Rune-Server Affiliate

    Join Date
    Oct 2010
    Posts
    2,843
    Thanks given
    1,189
    Thanks received
    1,583
    Rep Power
    5000
    I'd say get rid of the custom networking as it was never finished, not sure if that's the problem though.
    [Today 01:29 AM] RSTrials: Nice 0.97 Win/Loss Ratio luke. That's pretty bad.
    [Today 01:30 AM] Luke132: Ok u fucking moron i forgot i could influence misc.random
    [Only registered and activated users can see links. ]
    Reply With Quote  
     

  3. #3  
    Registered Member
    Join Date
    Jun 2019
    Posts
    57
    Thanks given
    18
    Thanks received
    11
    Rep Power
    17
    Quote Originally Posted by Professor Oak View Post
    I'd say get rid of the custom networking as it was never finished, not sure if that's the problem though.
    As Oak pointed out if the networking isn't finished take the one from ur Vencillio server and copy paste it over.

    Offtopic @ Oak love the signatures
    Reply With Quote  
     

  4. #4  
    Hella Hard Homie


    Join Date
    Jan 2011
    Posts
    584
    Thanks given
    163
    Thanks received
    41
    Rep Power
    111
    Quote Originally Posted by Professor Oak View Post
    I'd say get rid of the custom networking as it was never finished, not sure if that's the problem though.
    Did you ever encounter a similar issue like this?

    I will look into adding Arrav networking then instead
    [Only registered and activated users can see links. ]

    Quote Originally Posted by Winston Churchill
    "Success is the ability to go from one failure to another with no loss of enthusiasm"
    Austin still owes me $43
    Reply With Quote  
     

  5. #5  
    Be the change you wanna see!
    Nozemi's Avatar
    Join Date
    Jul 2010
    Posts
    254
    Thanks given
    60
    Thanks received
    57
    Rep Power
    40
    Quote Originally Posted by Aekramer View Post
    Did you ever encounter a similar issue like this?

    I will look into adding Arrav networking then instead
    I have experienced this issue a few times on mine. Replacing networking should probably be a good place to start.
    Reply With Quote  
     

  6. #6  
    Hella Hard Homie


    Join Date
    Jan 2011
    Posts
    584
    Thanks given
    163
    Thanks received
    41
    Rep Power
    111
    Quote Originally Posted by Professor Oak View Post
    I'd say get rid of the custom networking as it was never finished, not sure if that's the problem though.
    I was hoping you could inform me more on this particular part of code (ChannelPipelineHandler class),
    What is the IdleStateHandler intended for? I see you passed along one timeout value for the readIdle time, but 0 for writeIdle and allIdle, is this as intended?
    The name and assigned timeout values makes me believe this is somekind of special pipeline for AFK players? Where no incoming (writer data) is coming in, so no timeout is needed there?

    Code:
    protected void initChannel(SocketChannel channel) throws Exception {
    		final ChannelPipeline pipeline = channel.pipeline();
    		
    	    channel.attr(NetworkConstants.SESSION_KEY).setIfAbsent(new PlayerSession(channel));
    	    
    	    pipeline.addLast("channel-filter", FILTER);
    	    pipeline.addLast("decoder", new LoginDecoder());
    	    pipeline.addLast("encoder", new LoginEncoder());
    	    pipeline.addLast("timeout", new IdleStateHandler(NetworkConstants.SESSION_TIMEOUT, 0, 0));
    	    pipeline.addLast("channel-handler", HANDLER);
    	}
    [Only registered and activated users can see links. ]

    Quote Originally Posted by Winston Churchill
    "Success is the ability to go from one failure to another with no loss of enthusiasm"
    Austin still owes me $43
    Reply With Quote  
     

  7. #7  
    Donator


    Join Date
    Apr 2014
    Posts
    622
    Thanks given
    65
    Thanks received
    207
    Rep Power
    448
    First of all, people telling you to simply replace your networking is not especially helpful. I like that you're trying to fix this yourself and I'd definitely recommend doing so.

    Quote Originally Posted by Aekramer View Post
    I was hoping you could inform me more on this particular part of code (ChannelPipelineHandler class),
    What is the IdleStateHandler intended for? I see you passed along one timeout value for the readIdle time, but 0 for writeIdle and allIdle, is this as intended?
    The name and assigned timeout values makes me believe this is somekind of special pipeline for AFK players? Where no incoming (writer data) is coming in, so no timeout is needed there?

    Code:
    protected void initChannel(SocketChannel channel) throws Exception {
    		final ChannelPipeline pipeline = channel.pipeline();
    		
    	    channel.attr(NetworkConstants.SESSION_KEY).setIfAbsent(new PlayerSession(channel));
    	    
    	    pipeline.addLast("channel-filter", FILTER);
    	    pipeline.addLast("decoder", new LoginDecoder());
    	    pipeline.addLast("encoder", new LoginEncoder());
    	    pipeline.addLast("timeout", new IdleStateHandler(NetworkConstants.SESSION_TIMEOUT, 0, 0));
    	    pipeline.addLast("channel-handler", HANDLER);
    	}
    According to netty docs:

    IdleStateHandler(int readerIdleTimeSeconds, int writerIdleTimeSeconds, int allIdleTimeSeconds)
    Creates a new instance firing IdleStateEvents.
    So this means when the reader (listener for client packets) does not receive any packets for the amount of seconds specified by the
    Code:
    NetworkConstants.SESSION_TIMEOUT
    An IdleStateEvent is send to the channel handler, which would be your
    Code:
    HANDLER
    .

    You can handle the event like this (also taken from the netty docs):
    Code:
      @Override
         public void userEventTriggered(ChannelHandlerContext ctx, Object evt) throws Exception {
             if (evt instanceof IdleStateEvent) {
                 IdleStateEvent e = (IdleStateEvent) evt;
    This is not the same as AFK. I believe most clients (and I am not sure whether this is an official RS packet) have a packet that is being send when a player is no longer performing any actions but still has an active connection with the server (thus still send some ping packet at a regular interval). This would prompt the server to queue them for a logout.

    For your specific issue, I am failing to grasp some of the details. Is this DC occurring to specific players or subset of players at a time (say all the players within a certain region) or does it occur globally (so all players are affected). Also does the connection, after it is dropped, revive itself after some period of time or does it result in a deadlock in the networking/main-game thread?

    The only real advice I can give you at this point is to delve a bit deeper into netty. For a starters u can configure a logger through the
    Code:
    ServerBootstrap
    object.

    For example:
    Code:
    bootstrap.handler(new LoggingHandler(LogLevel.DEBUG))
    Last edited by StanDev; 06-20-2019 at 05:34 PM.
    [Only registered and activated users can see links. ]
    Reply With Quote  
     

  8. Thankful users:


  9. #8  
    Hella Hard Homie


    Join Date
    Jan 2011
    Posts
    584
    Thanks given
    163
    Thanks received
    41
    Rep Power
    111
    Quote Originally Posted by StanDev View Post
    First of all, people telling you to simply replace your networking is not especially helpful. I like that you're trying to fix this yourself and I'd definitely recommend doing so.



    According to netty docs:



    So this means when the reader (listener for client packets) does not receive any packets for the amount of seconds specified by the
    Code:
    NetworkConstants.SESSION_TIMEOUT
    An IdleStateEvent is send to the channel handler, which would be your
    Code:
    HANDLER
    .

    You can handle the event like this (also taken from the netty docs):
    Code:
      @Override
         public void userEventTriggered(ChannelHandlerContext ctx, Object evt) throws Exception {
             if (evt instanceof IdleStateEvent) {
                 IdleStateEvent e = (IdleStateEvent) evt;
    This is not the same as AFK. I believe most clients (and I am not sure whether this is an official RS packet) have a packet that is being send when a player is no longer performing any actions but still has an active connection with the server (thus still send some ping packet at a regular interval). This would prompt the server to queue them for a logout.

    For your specific issue, I am failing to grasp some of the details. Is this DC occurring to specific players or subset of players at a time (say all the players within a certain region) or does it occur globally (so all players are affected). Also does the connection, after it is dropped, revive itself after some period of time or does it result in a deadlock in the networking/main-game thread?

    The only real advice I can give you at this point is to delve a bit deeper into netty. For a starters u can configure a logger through the
    Code:
    ServerBootstrap
    object.

    For example:
    Code:
    bootstrap.handler(new LoggingHandler(LogLevel.DEBUG))
    Thanks for your detailed response, I will setup a logger to further debug the issue, as for so far here are some more details for you on the issue:

    The DC does attempt to reconnect after X amount of seconds (like we are used to back in 2007 when the internet wasn't as good and my dad wanted to upload his entire photo album), however sometimes it "seems" to instantly kick you to the login screen (almost as if this were a client sided action)

    Furthermore, when this happens to a person, not everyone experiences the same issue. Most of the time it is an individual player (even if others are in the same vicinity), after further discussing it with some other players, we have come to the conclusion that sending long messages (whether it is over PM or public chat, I think yell/cc are also affected) seem to really increase the likelihood of this happening.

    Then I realized a big difference between most RSPS and Elvarg, in Elvarg you can actually type in the public chat in all caps, whereas most clients render those other characters as lowercase (And it also ignores more symbols than elvarg I believe, but not certain about that)

    Perhaps it has to do with the fact that OSRS used to send the text as a lowercase value through a packet, but in here it sends it in the caps it was typed in, thus using up more data and not fitting the designed space (resulting in some kind of channel overflow that causes the connection between server and said player to reconnect)

    EDIT: Also; this has NEVER occured once when I run both server and client on localhost, but this might very well be still related to long chat messages (as I am usually not very talkative when I am alone in the game)


    EDIT2: A slight follow up scenario: I was with a friend of mine in the same area, talking small sentences in public (no issue)
    I do a very long CC message that goes out of the chat, unfortunately I hoped I would DC but this did not happen, however my friend did.

    It took a few seconds for him to recover, so I was typing some more, and typed a very long message in the public chat, this stopped my client (it no longer responded to me clicking anywhere on the map), waiting for my "Please wait, attempting to reestablish" message to appear, I saw my friend log back in, walk a few tiles around and say a phrase to me, I tried replying but this message was not received on his end (however I did see live action of everything he was doing right until I was kicked to the login screen)
    Last edited by Aekramer; 06-20-2019 at 09:21 PM.
    [Only registered and activated users can see links. ]

    Quote Originally Posted by Winston Churchill
    "Success is the ability to go from one failure to another with no loss of enthusiasm"
    Austin still owes me $43
    Reply With Quote  
     

  10. #9  
    Donator


    Join Date
    Apr 2014
    Posts
    622
    Thanks given
    65
    Thanks received
    207
    Rep Power
    448
    Quote Originally Posted by Aekramer View Post
    Thanks for your detailed response, I will setup a logger to further debug the issue, as for so far here are some more details for you on the issue:

    The DC does attempt to reconnect after X amount of seconds (like we are used to back in 2007 when the internet wasn't as good and my dad wanted to upload his entire photo album), however sometimes it "seems" to instantly kick you to the login screen (almost as if this were a client sided action)

    Furthermore, when this happens to a person, not everyone experiences the same issue. Most of the time it is an individual player (even if others are in the same vicinity), after further discussing it with some other players, we have come to the conclusion that sending long messages (whether it is over PM or public chat, I think yell/cc are also affected) seem to really increase the likelihood of this happening.

    Then I realized a big difference between most RSPS and Elvarg, in Elvarg you can actually type in the public chat in all caps, whereas most clients render those other characters as lowercase (And it also ignores more symbols than elvarg I believe, but not certain about that)

    Perhaps it has to do with the fact that OSRS used to send the text as a lowercase value through a packet, but in here it sends it in the caps it was typed in, thus using up more data and not fitting the designed space (resulting in some kind of channel overflow that causes the connection between server and said player to reconnect)

    EDIT: Also; this has NEVER occured once when I run both server and client on localhost, but this might very well be still related to long chat messages (as I am usually not very talkative when I am alone in the game)
    It might be that some specific sequence of characters do not get encoded/decoded properly. I do believe some popular RSPS bases (maybe also Elvarg) altered the encoding/decoding process, it might be related to that. Maybe look into how the Elvarg client parses input differently than a refactored 317.

    Other than this, my advice would be to perhaps setup a packet tracker. Where u cache all packets received and send by specific users. Than once a DC occurs to an user, you look at the packets send/received during the time of the DC. If these packets than contain unexpected information then you might have found your cause of misery.

    Another thing I would probably do in your situation is make sure I know what happens to the player session at the time of a DC.
    For example by place debug messages at each spot in the code that may cause the client to drop the connection.
    This could for example be a call to the channel handler channelInactive method or an IdleStateEvent (as mentioned in the previous post).
    Or any other place where the connection might be dropped, like that AFK packet (assuming it is present in your server).

    Quote Originally Posted by StanDev View Post
    It might be that some specific sequence of characters do not get encoded/decoded properly. I do believe some popular RSPS bases (maybe also Elvarg) altered the encoding/decoding process, it might be related to that. Maybe look into how the Elvarg client parses input differently than a refactored 317.

    Other than this, my advice would be to perhaps setup a packet tracker. Where u cache all packets received and send by specific users. Than once a DC occurs to an user, you look at the packets send/received during the time of the DC. If these packets than contain unexpected information then you might have found your cause of misery.

    Another thing I would probably do in your situation is make sure I know what happens to the player session at the time of a DC.
    For example by place debug messages at each spot in the code that may cause the client to drop the connection.
    This could for example be a call to the channel handler channelInactive method or an IdleStateEvent (as mentioned in the previous post).
    Or any other place where the connection might be dropped, like that AFK packet (assuming it is present in your server).
    As follow up to your second edit. That would indicate the issue is related to the encoding/decoding process.
    Maybe keep track of what packets containing strings (such as clan/public message) are coming in and then how they are going out.
    Perhaps check if the re-encoding of the string is different from how it was read (post decoding).

    However, if this DC u mentioned cannot be replicated than it touches some deeper issue I am afraid.

    Also when this DC happens, does the server at any points register the affected players as logging out?
    [Only registered and activated users can see links. ]
    Reply With Quote  
     

  11. Thankful user:


  12. #10  
    Hella Hard Homie


    Join Date
    Jan 2011
    Posts
    584
    Thanks given
    163
    Thanks received
    41
    Rep Power
    111
    Quote Originally Posted by StanDev View Post
    It might be that some specific sequence of characters do not get encoded/decoded properly. I do believe some popular RSPS bases (maybe also Elvarg) altered the encoding/decoding process, it might be related to that. Maybe look into how the Elvarg client parses input differently than a refactored 317.

    Other than this, my advice would be to perhaps setup a packet tracker. Where u cache all packets received and send by specific users. Than once a DC occurs to an user, you look at the packets send/received during the time of the DC. If these packets than contain unexpected information then you might have found your cause of misery.

    Another thing I would probably do in your situation is make sure I know what happens to the player session at the time of a DC.
    For example by place debug messages at each spot in the code that may cause the client to drop the connection.
    This could for example be a call to the channel handler channelInactive method or an IdleStateEvent (as mentioned in the previous post).
    Or any other place where the connection might be dropped, like that AFK packet (assuming it is present in your server).



    As follow up to your second edit. That would indicate the issue is related to the encoding/decoding process.
    Maybe keep track of what packets containing strings (such as clan/public message) are coming in and then how they are going out.
    Perhaps check if the re-encoding of the string is different from how it was read (post decoding).

    However, if this DC u mentioned cannot be replicated than it touches some deeper issue I am afraid.

    Also when this DC happens, does the server at any points register the affected players as logging out?
    I have been digging deeper, and just replicated it in a localhost environment.

    I have been typing messages like crazy into the chatbox (public chat), and I noticed that when typing the entire alphabet twice I can add another "abdefg" (so a total of 59 characters) if I add one more character to the end it will bug and sends the "DC".

    It does not always print an error message (usually it doesn't, but I have added the logginghandler you described in your first reply and it just printed out this error response I haven't seen before, but it refers to the EnterInput packet (used for the dialogue input, which wasnt in use at the time)


    And yes, as soon as the "DC" hits the client becomes unresponsive to input, and the server prints a Deregister message for the specific player (it will then take a few seconds for the client to attempt to reconnect)

    I am guessing the length of the chat is not cut off after X length and this results in an overflow? This overflow might have corrupted data in the pipeline giving the server the idea that the EnterInputAction packet was send?

    Error output I was referring to above:
    Code:
    [2019-06-20 23:43:02] java.lang.IndexOutOfBoundsException
    [2019-06-20 23:43:02] 	at io.netty.buffer.EmptyByteBuf.readInt(EmptyByteBuf.java:580)
    [2019-06-20 23:43:02] 	at com.elvarg.net.packet.Packet.readInt(Packet.java:225)
    [2019-06-20 23:43:02] 	at com.elvarg.net.packet.impl.EnterInputPacketListener.handleMessage(EnterInputPacketListener.java:42)
    [2019-06-20 23:43:02] 	at com.elvarg.net.PlayerSession.processPacket(PlayerSession.java:172)
    [2019-06-20 23:43:02] 	at com.elvarg.net.PlayerSession.handleQueuedPackets(PlayerSession.java:162)
    [2019-06-20 23:43:02] 	at com.elvarg.game.entity.impl.player.Player.sequence(Player.java:264)
    [2019-06-20 23:43:02] 	at com.elvarg.game.World$1.execute(World.java:147)
    [2019-06-20 23:43:02] 	at com.elvarg.game.entity.updating.sync.GameSyncExecutor.sync(GameSyncExecutor.java:55)
    [2019-06-20 23:43:02] 	at com.elvarg.game.World.sequence(World.java:142)
    [2019-06-20 23:43:02] 	at com.elvarg.game.GameEngine.run(GameEngine.java:34)
    [2019-06-20 23:43:02] 	at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
    [2019-06-20 23:43:02] 	at java.util.concurrent.FutureTask.runAndReset(Unknown Source)
    [2019-06-20 23:43:02] 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(Unknown Source)
    [2019-06-20 23:43:02] 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
    [2019-06-20 23:43:02] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
    [2019-06-20 23:43:02] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
    [2019-06-20 23:43:02] 	at java.lang.Thread.run(Unknown Source)
    [Only registered and activated users can see links. ]

    Quote Originally Posted by Winston Churchill
    "Success is the ability to go from one failure to another with no loss of enthusiasm"
    Austin still owes me $43
    Reply With Quote  
     

  13. Thankful user:


Page 1 of 2 12 LastLast

Thread Information
Users Browsing this Thread

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

Similar Threads

  1. Random Dc [Elvarg Base]
    By Guruu in forum Help
    Replies: 6
    Last Post: 06-21-2019, 11:20 PM
  2. Buy debug services [Elvarg random dc?]
    By Guruu in forum Buying
    Replies: 7
    Last Post: 08-07-2018, 09:36 PM
  3. Fix: Get rid of T1/T2's (Random dc's)
    By iZAjz in forum Configuration
    Replies: 26
    Last Post: 06-24-2009, 01:53 PM
  4. 508 Random Dc
    By Haledam in forum Help
    Replies: 6
    Last Post: 06-01-2009, 12:59 AM
  5. Uh random dcs?
    By Le Stat in forum Help
    Replies: 2
    Last Post: 03-28-2009, 11:11 AM
Tags for this Thread

View Tag Cloud

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