Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8155621

WebSocket Enhancements

XMLWordPrintable

      WebSocket API tasks

      1. Provide more examples in the API
      2. Remove Text interface and sendText(ByteBuffer): JDK-8156650
      3. Specify it's up to implementation how to treat incomplete (UTF-16 representation) CharSequences: JDK-8156650
      4. Remove word immediately everywhere from methods that return CompletableFuture: JDK-8156693
      5. CompletableFuture<WebSocket> instead of CompletableFuture<Void>: JDK-8156693
      6. All exceptions other than NPE and IAE should be relayed through CompletableFuture rather than thrown on the spot: JDK-8156693
      7. Provide better design for onPong (take care of as much as possible in the implementation rather than delegate to the Listener): JDK-8159053
      8. Provide better design for onClose (e.g. return CF to indicate when close can be sent): JDK-8159053
      9. Builder.connectTimeout(Duration) instead of Builder.connectTimeout(long, TimeUnit): JDK-8156742
      10. void request(long) instead of long request(long): JDK-8156742
      11. Remove sendBinary(byte[], boolean): JDK-8156742
      12. Remove sendText(Stream<CharSequence>): JDK-8156742
      13. Specify it's up to an implementation to serialize Ping, Pong and Close messages with Text and Binary ones however it wants. Given the relative order of messages of the same type (control/non-control) is preserved. One outstanding write. Period.
      14. Remove CloseCode and use simple (int, String): JDK-8159053
      15. Return an empty String for no subprotocol rather than null
      16. if onClose(1006) is signalled instead of onError(), then

      onOpen (onText|onBinary|onPing|onPong)* (onClose|onError)?

      could be more strict

      onOpen (onText|onBinary|onPing|onPong)* onClose|onError

      WebSocket implementation tasks

      1. Better check subprotocol syntax. Check for separators like

        "(" | ")" | "<" | ">" | "@",

      2. Think of repeated reading from the channel until the buffer is full or a message is received -- which comes first (optimization).
      3. Default implementation of Listener.onError must log the error or do something like

        default void onError(WebSocket webSocket, Throwable error) {
            Thread.currentThread().getUncaughtExceptionHandler()
                    .uncaughtException(Thread.currentThread(), error);
        }

      Or make it abstract.

      1. Get rid of ByteBuffer pooling on the receiving side for binary messages as an error-prone activity for user. ByteBuffers can be stored by the user and reused. Bottom line. Slicing? Yes. Pooling? No! At the same time it's absolutely fine to pool CharBuffer, since they are exposed as CharSequence. And CharSequence is implementable, thus we can control access to an already disposed sequences.
      2. Own package for the implementation instead of WS type prefix.
      3. Consider changing one-off registration with key cancellation for modifying interestOps (see Java™ NIO, 4.5 Selection Scaling); maybe we should put scalability one level higher, i.e. each channel reading/writing task is submitted to an executor? Is key cancellation followed by registration is expensive compared modifying interestOps for the duration of the task?
      4. Provide better exception messages, more descriptive and capturing state.
      5. Unbounded queue for outgoing messages: JDK-8157273 Decided not to do this.
      6. Delegate forbidden (used by RFC 6455) headers checking to HttpClient's internals (mainly because of the case-sensitivity rules) It's fine the way it is now.
      7. Consider pros and cons of attempting to send from the same thread followed by asynchronous sent of leftovers. Investigate possible problems with stack bloating.
      8. Consider ByteBuffer pooling on the sending side.
      9. Provide security checks for sendXXX.
      10. Move UTF-16 to UTF-8 encoding operations to a point before message acceptance. So these errors become non-fatal: JDK-8156693

      Test

      1. Group all tests in a dedicated folder
      2. Tests must be parametric (i.e. do not have a hardcoded data) where possible

      Wordsmithing

      1. abort() and isClosed() should agree on terminology. Use either of "TCP connection" or "socket" 1. Work out a better notation for sendX/onX in the javadoc. Maybe sendType/onType

            prappo Pavel Rappo
            prappo Pavel Rappo
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: