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. * @return the binary handler id

Set a binary message handler on the connection. This handler serves a similar purpose to io.vertx.scala.core.http.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 io.vertx.scala.core.http.WebSocketFrame#isFinal to find the boundaries). * @param handler the handler

Close the WebSocket sending the default close frame.

No more messages can be sent.

Set a close handler. This will be called when the WebSocket is closed.

After this callback, no more messages are expected. * @param handler the handler

Set a drain handler on the stream. If the write queue is full, then the handler will be called when the write queue is ready to accept buffers again. See io.vertx.scala.core.streams.Pump for an example of this being used.

The stream implementation defines when the drain handler, for example it could be when the queue size has been reduced to maxSize / 2. * @param handler the handler

Calls io.vertx.scala.core.http.WebSocketBase#close

Same as io.vertx.scala.core.http.WebSocketBase#end but writes some data to the stream before ending.

Set an end handler. Once the stream has ended, and there is no more data to be read, this handler will be called. * @return a reference to this, so the API can be used fluently

Set an exception handler on the write stream. * @param handler the exception handler

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. * @return a reference to this, so the API can be used fluently

Set a frame handler on the connection. This handler will be called when frames are read on the connection. * @param handler the handler

Set a data handler. As data is read, the handler will be called with the data. * @return a reference to this, so the API can be used fluently

Pause the ReadStream, it sets the buffer in fetch mode and clears the actual demand.

While it's paused, no data will be sent to the data handler. * @return a reference to this, so the API can be used fluently

Set a pong message handler on the connection. This handler will be invoked every time a pong message is received on the server, and can be used by both clients and servers since the RFC 6455 Sections 5.5.2 and 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 pings should immediately be responded to with a pong with identical content

Pong frames may be received unsolicited. * @param handler the handler

Resume reading, and sets the buffer in flowing mode.

If the ReadStream has been paused, reading will recommence on it. * @return a reference to this, so the API can be used fluently

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.

The value is defined by the implementation of the stream, e.g in bytes for a io.vertx.scala.core.net.NetSocket, the number of io.vertx.scala.core.eventbus.Message for a io.vertx.scala.core.eventbus.MessageProducer, etc... * @param maxSize the max size of the write stream

Returns the websocket sub protocol selected by the websocket handshake.

On the server, the value will be null when the handler receives the websocket callback as the handshake will not be completed yet.

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.

Set a text message handler on the connection. This handler will be called similar to the , but the buffer will be converted to a String first * @param handler the handler

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 io.vertx.scala.core.streams.WriteStream#writeQueueFull method before writing. This is done automatically if using a io.vertx.scala.core.streams.Pump. * @param data the data to write

Writes a (potentially large) piece of binary data to the connection. This data might be written as multiple frames if it exceeds the maximum WebSocket frame size. * @param data the data to write

Write a final WebSocket binary frame to the connection * @param data The data to write

Write a final WebSocket text frame to the connection * @param text The text to write

Write a WebSocket frame to the connection * @param frame the frame to write

Writes a ping 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 5.5.2.

There is no pingHandler because RFC 6455 section 5.5.2 clearly states that the only response to a ping is a pong with identical contents. * @param data the data to write, may be at most 125 bytes

Writes a pong 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, as the server and client both handle responding to a ping with a pong 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. * @param data the data to write, may be at most 125 bytes

This will return true if there are more bytes in the write queue than the value set using io.vertx.scala.core.http.WebSocketBase#setWriteQueueMaxSize * @return true if write queue is full

Writes a (potentially large) piece of text data to the connection. This data might be written as multiple frames if it exceeds the maximum WebSocket frame size. * @param text the data to write