Struct tungstenite::protocol::WebSocket

pub struct WebSocket<Stream> { /* fields omitted */ }

WebSocket input-output stream.

This is THE structure you want to create to be able to speak the WebSocket protocol. It may be created by calling connect, accept or client functions.

Methods

impl<Stream> WebSocket<Stream>

pub fn from_raw_socket(
    stream: Stream,
    role: Role,
    config: Option<WebSocketConfig>
) -> Self

Convert a raw socket into a WebSocket without performing a handshake.

Call this function if you're using Tungstenite as a part of a web framework or together with an existing one. If you need an initial handshake, use connect() or accept() functions of the crate to construct a websocket.

pub fn from_partially_read(
    stream: Stream,
    part: Vec<u8>,
    role: Role,
    config: Option<WebSocketConfig>
) -> Self

Convert a raw socket into a WebSocket without performing a handshake.

Call this function if you're using Tungstenite as a part of a web framework or together with an existing one. If you need an initial handshake, use connect() or accept() functions of the crate to construct a websocket.

pub fn get_ref(&self) -> &Stream

Returns a shared reference to the inner stream.

pub fn get_mut(&mut self) -> &mut Stream

Returns a mutable reference to the inner stream.

pub fn set_config(&mut self, set_func: impl FnOnce(&mut WebSocketConfig))

Change the configuration.

pub fn can_read(&self) -> bool

Check if it is possible to read messages.

Reading is impossible after receiving Message::Close. It is still possible after sending close frame since the peer still may send some data before confirming close.

pub fn can_write(&self) -> bool

Check if it is possible to write messages.

Writing gets impossible immediately after sending or receiving Message::Close.

impl<Stream: Read + Write> WebSocket<Stream>

pub fn read_message(&mut self) -> Result<Message>

Read a message from stream, if possible.

This will queue responses to ping and close messages to be sent. It will call write_pending before trying to read in order to make sure that those responses make progress even if you never call write_pending. That does mean that they get sent out earliest on the next call to read_message, write_message or write_pending.

Closing the connection

When the remote endpoint decides to close the connection this will return the close message with an optional close frame.

You should continue calling read_message, write_message or write_pending to drive the reply to the close frame until Error::ConnectionClosed is returned. Once that happens it is safe to drop the underlying connection.

pub fn write_message(&mut self, message: Message) -> Result<()>

Send a message to stream, if possible.

WebSocket will buffer a configurable number of messages at a time, except to reply to Ping requests. A Pong reply will jump the queue because the websocket RFC specifies it should be sent as soon as is practical.

Note that upon receiving a ping message, tungstenite cues a pong reply automatically. When you call either read_message, write_message or write_pending next it will try to send that pong out if the underlying connection can take more data. This means you should not respond to ping frames manually.

You can however send pong frames manually in order to indicate a unidirectional heartbeat as described in RFC 6455. Note that if read_message returns a ping, you should call write_pending until it doesn't return WouldBlock before passing a pong to write_message, otherwise the response to the ping will not be sent, but rather replaced by your custom pong message.

Errors

• If the WebSocket's send queue is full, SendQueueFull will be returned along with the passed message. Otherwise, the message is queued and Ok(()) is returned.
• If the connection is closed and should be dropped, this will return Error::ConnectionClosed.
• If you try again after Error::ConnectionClosed was returned either from here or from read_message, Error::AlreadyClosed will be returned. This indicates a program error on your part.
• Error::Io is returned if the underlying connection returns an error (consider these fatal except for WouldBlock).
• Error::Capacity if your message size is bigger than the configured max message size.

pub fn write_pending(&mut self) -> Result<()>

Flush the pending send queue.

pub fn close(&mut self, code: Option<CloseFrame>) -> Result<()>

Close the connection.

This function guarantees that the close frame will be queued. There is no need to call it again. Calling this function is the same as calling write_message(Message::Close(..)).

After queing the close frame you should continue calling read_message or write_pending to drive the close handshake to completion.

The websocket RFC defines that the underlying connection should be closed by the server. Tungstenite takes care of this asymmetry for you.

When the close handshake is finished (we have both sent and received a close message), read_message or write_pending will return Error::ConnectionClosed if this endpoint is the server.

If this endpoint is a client, Error::ConnectionClosed will only be returned after the server has closed the underlying connection.

It is thus safe to drop the underlying connection as soon as Error::ConnectionClosed is returned from read_message or write_pending.

Trait Implementations

impl<Stream: Debug> Debug for WebSocket<Stream>

fn fmt(&self, f: &mut Formatter) -> Result

Formats the value using the given formatter.