Skip to content

Bad rsv 4 on android #465

Closed
Closed
Bad rsv 4 on android#465
Labels
AndroidBugServerwaiting-for-feedbackwss
Milestone
Release 1.3.4

Description

@zhoulifu
zhoulifu
opened on Apr 27, 2017

Hello, our team using this library for connecting websocket server on Android platform,
sometimes, there are 'bad rsv 4' errors occurred. Seems same problem with #430.

04-27 14:26:09.960 I/System.out( 1564): D/WebsocketChannel: 000000	48 54 54 50 2f 31 2e 31 20 31 30 31 20 53 77 69 74 63  HTTP/1.1 101 Switc
04-27 14:26:09.960 D/WebSocketChannel( 1564): onError:org.java_websocket.exceptions.InvalidFrameException: bad rsv 4

The debug log above shows the WebSocketImpl treat the handshake response as normal websocket frame and decode it, then throw an InvalidFrameException.

Our client tries to reconnect to server endlessly when it is in condition of unstable network environment.
So is it possible that method org.java_websocket.WebSocketImpl#decode was invoked after WebSocketClient closed in some extreme cases?

Activity

  1. marci4 commented on Apr 27, 2017

    @marci4
    marci4
    on Apr 27, 2017
    Collaborator

    Hello @zhoulifu
    what do you mean with bad?

    Greetings
    marci4

  2. zhoulifu commented on Apr 27, 2017

    @zhoulifu
    zhoulifu
    on Apr 27, 2017
    ContributorAuthor

    @marci4 Sorry i just double click the Enter by mistake :(

  3. marci4 commented on Apr 27, 2017

    @marci4
    marci4
    on Apr 27, 2017
    Collaborator

    Hello @zhoulifu,

    no problem. Just was thinking wtf :D

    Are you using the latest version 1.3.3?

    If so, could you please provide an example application for me,, because right now I cannot reproduce this issue on my test enviroment.

    Greetings
    marci4

  4. marci4
    added
    Android
    Bug
    Server
    waiting-for-feedback
    on Apr 27, 2017
  5. marci4
    changed the title [-]'Bad'[/-] [+]Bad rsv 4 on android[/+] on Apr 27, 2017

  6. zhoulifu commented on Apr 27, 2017

    @zhoulifu
    zhoulifu
    on Apr 27, 2017
    ContributorAuthor

    Yes we are using java-websocket-1.3.3.
    I'm afraid I can't provide the apk :D, furthermore, it doesn't hannped 100% in our test env :(

    But, i'll try may best to produce this issue manually

  7. marci4 commented on Apr 27, 2017

    @marci4
    marci4
    on Apr 27, 2017
    Collaborator

    Hello @zhoulifu

    could you please activate the debug printouts with
    WebSocketImpl.DEBUG = true;

    Could you tell me something about the client you use to connect to the server?

    Greetings
    marci4

  8. zhoulifu commented on Apr 27, 2017

    @zhoulifu
    zhoulifu
    on Apr 27, 2017
    ContributorAuthor

    Yes, WebSocketImpl.DEBUG is enabled, and I added some statements in source code

     System.out.println("D/WebSocketChannel: Impl ready state " + readystate);
 System.out.println("D/WebSocketChannel: " + Hexdump.format(socketBuffer.array(), socketBuffer.position(), socketBuffer.remaining()));

    here was what I got

    04-27 15:40:52.940 I/System.out( 1548): D/WebSocketChannel: Impl ready state CLOSING
04-27 15:40:52.940 I/System.out( 1548): D/WebSocketChannel: 000000    48 54 54 50 2f 31 2e 31 20 31 30 31 20 53 77 69 74 63  HTTP/1.1 101 Switc
04-27 15:40:52.940 D/WebSocketChannel( 1548): onError:org.java_websocket.exceptions.InvalidFrameException: bad rsv 4

    It seems that my conjecture was confirmed.

    Our client runs as an android system service, it invoke the async method connect() and close(), I think it's the reason of this issue, because the stupid client would invoke close() after connect() was invoked immediately and over and over again in some cases :(

    I'm still trying to reproduce this issue, wait for my good news ;D

  9. marci4 commented on Apr 27, 2017

    @marci4
    marci4
    on Apr 27, 2017
    Collaborator

    Hello @zhoulifu,

    so as I understand you correctly you use the client provided by this lib.

    Could you then try if connectBlocking() and closeBlocking() "fixes" the issue?

    Just a heads up, I am going on a little trip for a few days later today. Won't be able to reply then.

    Greetings
    marci4

  10. zhoulifu commented on Apr 27, 2017

    @zhoulifu
    zhoulifu
    on Apr 27, 2017
    ContributorAuthor

    It seems those blocking methods are helpful, it works fine so far.
    Thanks for your advice, and have a nice trip! :)

  11. zhoulifu commented on Apr 27, 2017

    @zhoulifu
    zhoulifu
    on Apr 27, 2017
    ContributorAuthor

    Hello @marci4 , please checkout this, it could produce this problem on my computer.

    ENV:
    Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz
    Ubuntu 14.04.5 LTS
    Linux 4.4.0-75-generic
    Java 1.8.0_101 HotSpot(TM) 64-Bit (build 25.101-b13)

    Thanks :)

  12. zhoulifu
    added 2 commits that reference this issue on Apr 28, 2017

    Fix TooTallNate#465

    3cc0eef

    Fix TooTallNate#465

    64e5c70

  13. zhoulifu commented on Apr 28, 2017

    @zhoulifu
    zhoulifu
    on Apr 28, 2017
    ContributorAuthor

    Hi @marci4, I think it would be helpful, PTAL

  14. marci4 commented on May 2, 2017

    @marci4
    marci4
    on May 2, 2017
    Collaborator

    Hello @zhoulifu,

    thx for looking into this issue a bit more :)

    This issue sometimes happens with your example, but it looks like your patch fixes it.

    Going to test against side affects now ;)

    Greetings
    marci4

  15. marci4
    added
    wss
    on May 2, 2017

  16. marci4 commented on May 2, 2017

    @marci4
    marci4
    on May 2, 2017
    Collaborator

    It is me again.

    Soo all the test cases pass.
    Looks like it isn't just an android problem, but it is more likely to occur since phones have slower cpus.

    Could you please open a pull request for your fix?

    Greetings
    marci4

  17. marci4
    added this to the milestone on May 2, 2017

  18. zhoulifu commented on May 2, 2017

    @zhoulifu
    zhoulifu
    on May 2, 2017
    ContributorAuthor

    After thinking it carefully, you are right.
    It still could happen even if check the ready state, readyState could changed from NOT_YET_CONNECTED to CLOSED or CLOSING after the state's check.
    The effect of variable readyState is limited.
    Maybe we should find another way to fix it, how about blocking the close() method until handshake
    was completed?

  19. marci4 commented on May 2, 2017

    @marci4
    marci4
    on May 2, 2017
    Collaborator

    Well it still would not solve different clients, and I think it is an unexpected behavior that a non blocking method may block.

    Gonna check when readyState can change and if we just include an additional check for this case.

    Greetings
    marci4

  20. zhoulifu commented on May 2, 2017

    @zhoulifu
    zhoulifu
    on May 2, 2017
    ContributorAuthor

    If so, I think this would be better

    if( readystate != READYSTATE.NOT_YET_CONNECTED ) {
  if( readystate == READYSTATE.OPEN ) {
    decodeFrames( socketBuffer );
  }
} else {
    // something else
}

    WDYT?

  21. marci4 commented on May 2, 2017

    @marci4
    marci4
    on May 2, 2017
    Collaborator

    Yes I like it this way more.

    Readystate is changed to open just during handshake so it should not be a problem.

    Greetings
    marci4

  22. zhoulifu
    added a commit that references this issue on May 3, 2017

    Fix TooTallNate#465

    2daee16
  23. marci4
    closed this as completedin 2daee16on May 3, 2017
  24. marci4
    added a commit that references this issue on May 3, 2017

    Merge pull request #470 from zhoulifu/issue465

    56e0d75

  25. Eucalyptus-fructicetorum commented on Sep 5, 2022

    @Eucalyptus-fructicetorum
    Eucalyptus-fructicetorum
    on Sep 5, 2022

    How to solve this？
    org.java_websocket.exceptions.InvalidFrameException: bad rsv 4
    at org.java_websocket.drafts.Draft_10.translateSingleFrame(Draft_10.java:309)
    at org.java_websocket.drafts.Draft_10.translateFrame(Draft_10.java:286)
    at org.java_websocket.WebSocketImpl.decodeFrames(WebSocketImpl.java:312)
    at org.java_websocket.WebSocketImpl.decode(WebSocketImpl.java:157)
    at org.java_websocket.client.WebSocketClient.interruptableRun(WebSocketClient.java:230)
    at org.java_websocket.client.WebSocketClient.run(WebSocketClient.java:188)
    at java.lang.Thread.run(Thread.java:748)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    AndroidBugServerwaiting-for-feedbackwss

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions