WebSocketBuilder
Related Docs:
object WebSocketBuilder
| package websocket
The send side of the Exchange represents the outgoing stream of messages that should be sent to the client
The receive side of the Exchange is a sink to which the framework will push the incoming websocket messages
Once both streams have terminated, the server will initiate a close of the websocket connection.
As defined in the websocket specification, this means the server
will send a CloseFrame to the client and wait for a CloseFrame in response before closing the
connection, this ensures that no messages are lost in flight. The server will shutdown the
connection when it receives the CloseFrame message back from the client. The connection will also
be closed if the client does not respond with a CloseFrame after some reasonable amount of
time.
Another way of closing the connection is by emitting a CloseFrame in the stream of messages
heading to the client. This method allows one to attach a message to the CloseFrame as defined
by the websocket protocol.
Unfortunately the current implementation does not quite respect the description above, it violates
the websocket protocol by terminating the connection immediately upon reception
of a CloseFrame. This bug will be addressed soon in an upcoming release and this message will be
removed.
Currently, there is no way for the server to be notified when the connection is closed, neither in
the case of a normal disconnection such as a Close handshake or due to a connection error. There
are plans to address this limitation in the future.
Handshake response headers, such as such as:Sec-WebSocket-Protocol.
The status code to return to a client making a non-websocket HTTP request to this route. default: NotImplemented
The status code to return when failing to handle a websocket HTTP request to this route. default: BadRequest
Handshake response headers, such as such as:Sec-WebSocket-Protocol.
The status code to return when failing to handle a websocket HTTP request to this route.
The status code to return when failing to handle a websocket HTTP request to this route. default: BadRequest
The status code to return to a client making a non-websocket HTTP request to this route.
The status code to return to a client making a non-websocket HTTP request to this route. default: NotImplemented
The receive side of the Exchange is a sink to which the framework will push the incoming websocket messages Once both streams have terminated, the server will initiate a close of the websocket connection.
The receive side of the Exchange is a sink to which the framework will push the incoming websocket messages
Once both streams have terminated, the server will initiate a close of the websocket connection.
As defined in the websocket specification, this means the server
will send a CloseFrame to the client and wait for a CloseFrame in response before closing the
connection, this ensures that no messages are lost in flight. The server will shutdown the
connection when it receives the CloseFrame message back from the client. The connection will also
be closed if the client does not respond with a CloseFrame after some reasonable amount of
time.
Another way of closing the connection is by emitting a CloseFrame in the stream of messages
heading to the client. This method allows one to attach a message to the CloseFrame as defined
by the websocket protocol.
Unfortunately the current implementation does not quite respect the description above, it violates
the websocket protocol by terminating the connection immediately upon reception
of a CloseFrame. This bug will be addressed soon in an upcoming release and this message will be
removed.
Currently, there is no way for the server to be notified when the connection is closed, neither in
the case of a normal disconnection such as a Close handshake or due to a connection error. There
are plans to address this limitation in the future.
The send side of the Exchange represents the outgoing stream of messages that should be sent to the client
Build a response which will accept an HTTP websocket upgrade request and initiate a websocket connection using the supplied exchange to process and respond to websocket messages.
The send side of the Exchange represents the outgoing stream of messages that should be sent to the client
The receive side of the Exchange is a sink to which the framework will push the incoming websocket messages Once both streams have terminated, the server will initiate a close of the websocket connection. As defined in the websocket specification, this means the server will send a CloseFrame to the client and wait for a CloseFrame in response before closing the connection, this ensures that no messages are lost in flight. The server will shutdown the connection when it receives the
CloseFramemessage back from the client. The connection will also be closed if the client does not respond with aCloseFrameafter some reasonable amount of time. Another way of closing the connection is by emitting aCloseFramein the stream of messages heading to the client. This method allows one to attach a message to theCloseFrameas defined by the websocket protocol. Unfortunately the current implementation does not quite respect the description above, it violates the websocket protocol by terminating the connection immediately upon reception of aCloseFrame. This bug will be addressed soon in an upcoming release and this message will be removed. Currently, there is no way for the server to be notified when the connection is closed, neither in the case of a normal disconnection such as a Close handshake or due to a connection error. There are plans to address this limitation in the future.Handshake response headers, such as such as:Sec-WebSocket-Protocol.
The status code to return to a client making a non-websocket HTTP request to this route. default: NotImplemented
The status code to return when failing to handle a websocket HTTP request to this route. default: BadRequest