Set an asynchronous result for the handshake, upon completion of the specified future, the
WebSocket will either be
accepted when the future succeeds with the HTTP status code
rejected when the future is succeeds with an HTTP status code different than
rejected when the future fails with the HTTP status code 500
The provided future might be completed by the WebSocket itself, e.g calling the close(io.vertx.core.Handler<io.vertx.core.AsyncResult<java.lang.Void>>) method
will try to accept the handshake and close the WebSocket afterward.

binaryHandlerID

When a WebSocket is created it automatically registers an event handler with the event bus - the ID of that
handler is given by this method.

Given this ID, a different event loop can send a binary frame to that event handler using the event bus and
that buffer will be received by this instance in its own event loop and written to the underlying connection. This
allows you to write data to other WebSockets which are owned by different event loops.

textHandlerID

When a WebSocket is created it automatically registers an event handler with the eventbus, the ID of that
handler is given by textHandlerID.

Given this ID, a different event loop can send a text frame to that event handler using the event bus and
that buffer will be received by this instance in its own event loop and written to the underlying connection. This
allows you to write data to other WebSockets which are owned by different event loops.

writePong

Writes a pong frame to the connection. This will be written in a single frame. Pong frames may be at most 125 bytes (octets).

This method should not be used to write application data and should only be used for implementing a keep alive or
to ensure the client is still responsive, see RFC 6455 section 5.5.2.

There is no need to manually write a pong frame, as the server and client both handle responding to a ping from with a pong from
automatically and this is exposed to users. RFC 6455 section 5.5.3 states that pongs may be sent unsolicited in order
to implement a one way heartbeat.

pongHandler

Set a pong frame handler on the connection. This handler will be invoked every time a pong frame is received
on the server, and can be used by both clients and servers since the RFC 6455 section 5.5.2 and section 5.5.3 do not
specify whether the client or server sends a ping.

Pong frames may be at most 125 bytes (octets).

There is no ping handler since ping frames should immediately be responded to with a pong frame with identical content

fetch

Fetch the specified amount of elements. If the ReadStream has been paused, reading will
recommence with the specified amount of items, otherwise the specified amount will
be added to the current stream demand.

write

Write some data to the stream. The data is put on an internal write queue, and the write actually happens
asynchronously. To avoid running out of memory by putting too much on the write queue,
check the WriteStream.writeQueueFull() method before writing. This is done automatically if using a Pump.

rxWrite

setWriteQueueMaxSize

Set the maximum size of the write queue to maxSize. You will still be able to write to the stream even
if there is more than maxSize items in the write queue. This is used as an indicator by classes such as
Pump to provide flow control.

headers

accept

This method should be called from the WebSocket handler to explicitly accept the WebSocket and
terminate the WebSocket handshake.

reject

public void reject()

Reject the WebSocket.

Calling this method from the WebSocket handler when it is first passed to you gives you the opportunity to reject
the WebSocket, which will cause the WebSocket handshake to fail by returning
a response code.

You might use this method, if for example you only want to accept WebSockets with a particular path.