glyde/websocket/stream

The loop around frame: a socket read lands whatever bytes arrived, which may be half a frame, four frames, or one whose message needs three more reads. This holds the leftovers and the half-built message together.

Types

pub type Next {
  Ready(message: frame.Message, stream: Stream)
  Waiting(stream: Stream)
  Failed(reason: frame.Violation)
  Overflowed(bytes: Int)
}

Constructors

  • Ready(message: frame.Message, stream: Stream)

    Ask again before reading the socket: one read often lands several frames.

  • Waiting(stream: Stream)

    Nothing complete yet. Read more bytes and feed them.

  • Failed(reason: frame.Violation)

    The stream is not RFC 6455 any more. The reason is frame’s, unrendered, so a caller can match it.

  • Overflowed(bytes: Int)

    The bytes held went past max_bytes without becoming a message. They are gone, and so is the stream: a peer that keeps fragmenting will not stop because the next read was refused.

Bytes waiting to be read, and the message being put back together. max_bytes lives in here so it cannot drift between calls.

pub type Stream {
  Stream(
    buffer: BitArray,
    assembly: frame.Assembly,
    max_bytes: Int,
  )
}

Constructors

  • Stream(
      buffer: BitArray,
      assembly: frame.Assembly,
      max_bytes: Int,
    )

Values

pub fn buffered(stream: Stream) -> Int

Bytes held, unparsed plus half-assembled, which is what max_bytes bounds.

pub fn feed(stream: Stream, bytes: BitArray) -> Stream
pub fn new(leftover: BitArray, max_bytes: Int) -> Stream

Start from whatever followed the handshake: a server may put its first frame in the same packet as the 101.

max_bytes bounds what one stream will hold with no whole message out of it. Without a bound a peer that fragments forever grows the process until the VM dies.

pub fn next(stream: Stream) -> Next

Take the next whole message out of the buffer. Even a Waiting hands back a stream with absorbed fragments moved into the assembly; dropping it loses them.

Search Document