websockets- A sensible and clean way to write WebSocket-capable servers in Haskell.

Safe HaskellNone



This module exposes connection internals and should only be used if you really know what you are doing.



data PendingConnection Source

A new client connected to the server. We haven't accepted the connection yet, though.




pendingOptions :: !ConnectionOptions

Options, passed as-is to the Connection

pendingRequest :: !RequestHead

Useful for e.g. inspecting the request path.

pendingOnAccept :: !(Connection -> IO ())

One-shot callback fired when a connection is accepted, i.e., *after* the accepting response is sent to the client.

pendingStream :: !Stream

Input/output stream

data AcceptRequest Source




acceptSubprotocol :: !(Maybe ByteString)

The subprotocol to speak with the client. If pendingSubprotcols is non-empty, acceptSubprotocol must be one of the subprotocols from the list.

data Connection Source




connectionOptions :: !ConnectionOptions
connectionType :: !ConnectionType
connectionProtocol :: !Protocol
connectionParse :: !(IO (Maybe Message))
connectionWrite :: !(Message -> IO ())
connectionSentClose :: !(IORef Bool)

According to the RFC, both the client and the server MUST send a close control message to each other. Either party can initiate the first close message but then the other party must respond. Finally, the server is in charge of closing the TCP connection. This IORef tracks if we have sent a close message and are waiting for the peer to respond.

data ConnectionOptions Source

Set options for a Connection.




connectionOnPong :: !(IO ())

Whenever a pong is received, this IO action is executed. It can be used to tickle connections or fire missiles.

receiveDataMessage :: Connection -> IO DataMessage Source

Receive an application message. Automatically respond to control messages.

When the peer sends a close control message, an exception of type CloseRequest is thrown. The peer can send a close control message either to initiate a close or in response to a close message we have sent to the peer. In either case the CloseRequest exception will be thrown. The RFC specifies that the server is responsible for closing the TCP connection, which should happen after receiving the CloseRequest exception from this function.

This will throw ConnectionClosed if the TCP connection dies unexpectedly.

receiveData :: WebSocketsData a => Connection -> IO a Source

Receive a message, converting it to whatever format is needed.

sendTextData :: WebSocketsData a => Connection -> a -> IO () Source

Send a message as text

sendBinaryData :: WebSocketsData a => Connection -> a -> IO () Source

Send a message as binary data

sendClose :: WebSocketsData a => Connection -> a -> IO () Source

Send a friendly close message. Note that after sending this message, you should still continue calling receiveDataMessage to process any in-flight messages. The peer will eventually respond with a close control message of its own which will cause receiveDataMessage to throw the CloseRequest exception. This exception is when you can finally consider the connection closed.

sendCloseCode :: WebSocketsData a => Connection -> Word16 -> a -> IO () Source

Send a friendly close message and close code. Similar to sendClose, you should continue calling receiveDataMessage until you receive a CloseRequest exception.

See http://tools.ietf.org/html/rfc6455#section-7.4 for a list of close codes.

sendPing :: WebSocketsData a => Connection -> a -> IO () Source

Send a ping

forkPingThread :: Connection -> Int -> IO () Source

Forks a ping thread, sending a ping message every n seconds over the connection. The thread dies silently if the connection crashes or is closed.