Uploaded image for project: 'TinkerPop'
  1. TinkerPop
  2. TINKERPOP-1555

Multiple frame fragments support for WebSocket

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Minor
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: driver
    • Labels:

      Description

      Hello,

      We've encountered the "Max frame length of 65536 has been exceeded" error message a few times already.

      Like suggested here https://groups.google.com/d/topic/gremlin-users/JWto9uv8CeA/discussion , we could increase this number to a new arbitrary one, until the problem appears again.

      The WebSocket protocol supports the multiple frame fragments mode. Sending a single message into multiple frames can therefore be an "open bar" configuration for those that aren't subject to DOS attacks.

      Also, you can run into different kind of problems right now, because the application (client/server) receiving the frame will close the connexion if the frame size is above the max allowed.

      However, the sender just doesn't know the connexion was closed due to a "max frame size" protocol violation, and may retry the same request again.
      There is no "railing" on the sender side to make sure the receiver can actually handle the frame.

      The multiple frame fragments avoids this kind of troubles, but may be affected by DOS attacks.

      It could be a new configuration option in both client / server, "enableFrameFragments: true" (defaulting to false for retro-compatibility)

      I will work on this improvement, and wanted to share the thoughts with you, so a pull request can be done later on.

      What do you think about the idea ?
      Would you integrate the pull request if done right ?

      Regards,

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              naab Anthony PERINOT
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 48h
                48h
                Remaining:
                Remaining Estimate - 48h
                48h
                Logged:
                Time Spent - Not Specified
                Not Specified