When a WebSocket is created, it may register an event handler with the event bus - the ID of that
handler is given by this method.
By default, no handler is registered, the feature must be enabled via WebSocketConnectOptions or HttpServerOptions.
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.
Set a binary message handler on the connection. This handler serves a similar purpose to {@link WebSocketBase#handler} except that if a message comes into the socket in multiple frames, the data from the frames will be aggregated into a single buffer before calling the handler (using {@link WebSocketFrame#isFinal} to find the boundaries).
Same as {@link WebSocketBase#close} but with an handler called when the operation completes
Same as {@link WebSocketBase#close} but with an handler called when the operation completes
Same as {@link WebSocketBase#close} but with an handler called when the operation completes
Same as {@link WebSocketBase#close} but with an handler called when the operation completes
Same as {@link WebSocketBase#close} but with an handler called when the operation completes
Same as {@link WebSocketBase#close} but with an handler called when the operation completes
Set a close handler. This will be called when the WebSocket is closed.
After this callback, no more messages are expected. When the WebSocket received a close frame, the {@link WebSocketBase#closeStatusCode} will return the status code and {@link WebSocketBase#closeReason} will return the reason.Returns the close reason message from the remote endpoint or null when not yet received.
Returns the close status code received from the remote endpoint or null when not yet received.
Same as but with an handler called when the operation completes
Same as but with an handler called when the operation completes
Calls {@link WebSocketBase#close}
Calls {@link WebSocketBase#close}
Set a frame handler on the connection. This handler will be called when frames are read on the connection.
Returns the HTTP headers when the WebSocket is first obtained in the handler.
The headers will benull on subsequent interactions.
Pipe this ReadStream to the WriteStream.
Elements emitted by this stream will be written to the write stream until this stream ends or fails.
Once this stream has ended or failed, the write stream will be ended and the handler will be
called with the result.
Pipe this ReadStream to the WriteStream.
Elements emitted by this stream will be written to the write stream until this stream ends or fails.
Once this stream has ended or failed, the write stream will be ended and the handler will be
called with the result.
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
Pong frames may be received unsolicited.
Returns the WebSocket sub protocol selected by the WebSocket handshake.
On the server, the value will benull when the handler receives the WebSocket callback as the
handshake will not be completed yet.
When a WebSocket is created, it may register an event handler with the eventbus, the ID of that
handler is given by textHandlerID.
By default, no handler is registered, the feature must be enabled via WebSocketConnectOptions or HttpServerOptions.
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.
Set a text message handler on the connection. This handler will be called similar to the {@link WebSocketBase#binaryMessageHandler}, but the buffer will be converted to a String first
Same as but with an handler called when the operation completes
Same as but with an handler called when the operation completes
Same as {@link WebSocketBase#writeBinaryMessage} but with an handler called when the operation completes
Same as {@link WebSocketBase#writeBinaryMessage} but with an handler called when the operation completes
Same as {@link WebSocketBase#writeFinalBinaryFrame} but with an handler called when the operation completes
Same as {@link WebSocketBase#writeFinalBinaryFrame} but with an handler called when the operation completes
Same as {@link WebSocketBase#writeFinalTextFrame} but with an handler called when the operation completes
Same as {@link WebSocketBase#writeFinalTextFrame} but with an handler called when the operation completes
Same as {@link WebSocketBase#writeFrame} but with an handler called when the operation completes
Same as {@link WebSocketBase#writeFrame} but with an handler called when the operation completes
Writes a ping frame to the connection. This will be written in a single frame. Ping 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 section 5.5.2.
There is no handler for ping frames because RFC 6455 clearly states that the only response to a ping frame is a pong frame with identical contents.
Writes a ping frame to the connection. This will be written in a single frame. Ping 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 section 5.5.2.
There is no handler for ping frames because RFC 6455 clearly states that the only response to a ping frame is a pong frame with identical contents.
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.
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.
This will return true if there are more bytes in the write queue than the value set using {@link WebSocketBase#setWriteQueueMaxSize}
Same as {@link WebSocketBase#writeTextMessage} but with an handler called when the operation completes
Same as {@link WebSocketBase#writeTextMessage} but with an handler called when the operation completes
Generated using TypeDoc
Base WebSocket implementation.
It implements both and so it can be used with Pipe to pipe data with flow control.