diff --git a/README.md b/README.md index 4e1a403..5d0d50d 100644 --- a/README.md +++ b/README.md @@ -17,9 +17,9 @@ Introduction [![MIT licensed](https://img.shields.io/badge/license-MIT-blue.svg)](./LICENSE) [![Crate](http://meritbadge.herokuapp.com/ws)](https://crates.io/crates/ws) -**[Homepage](https://ws-rs.org)** +**[Homepage](https://housleyjk.github.io/ws-rs/)** -**[API Documentation](https://ws-rs.org/docs)** +**[API Documentation](https://docs.rs/ws/0.9.1/ws/)** This library provides an implementation of WebSockets, [RFC6455](https://tools.ietf.org/html/rfc6455) using [MIO](https://github.com/carllerche/mio). It diff --git a/docs/404.md b/docs/404.md new file mode 100644 index 0000000..dec91a3 --- /dev/null +++ b/docs/404.md @@ -0,0 +1,7 @@ +--- +permalink: /404.html +--- + +## Page not found + +### [Home](index.md) \ No newline at end of file diff --git a/docs/deflate.md b/docs/deflate.md new file mode 100644 index 0000000..8ca7d92 --- /dev/null +++ b/docs/deflate.md @@ -0,0 +1,66 @@ +# Permessage-Deflate extension + +WS-RS supports the [permessage-deflate extension](https://tools.ietf.org/html/rfc7692) which allows for the compression of WebSocket messages. To enable the feature, specify it in your ```Cargo.toml```: + +``` +[dependencies.ws] +version = "*" +features = ["permessage-deflate"] +``` + +Once the feature is enabled, you will need to wrap your message handler inside of a ```DeflateHandler```, which will negotiate the extension with the other endpoint and perform the compression and decompression of messages. + +```rust +// An echo server that compresses and decompresses messages using the deflate algorithm +extern crate ws; + +use ws::deflate::DeflateHandler; + +fn main() { + ws::listen("127.0.0.1:3012", |out| { + DeflateHandler::new(move |msg| { + out.send(msg) + }) + }).expect("Failed to build WebSocket"); +} +``` +The ```DeflateHandler``` will accept any other valid handler. In other words, any struct that implements the ```Handler``` trait. If you would like to configure the extension, for example if you wanted to limit the size of the sliding window, use the ```DeflateBuilder``` struct and pass in the settings. + +```rust +// A WebSocket client that sends a message to an echo server using the permessage-deflate +// extension with a sliding window of 10 bits. +extern crate ws; + +use ws::deflate::{DeflateBuilder, DeflateSettings}; + +fn main() { + ws::connect("ws://127.0.0.1:3012", |out| { + DeflateBuilder::new().with_settings(DeflateSettings { + max_window_bits: 10, + ..Default::default() + }).build(Client { + out: out, + }) + }).expect("Failed to build WebSocket"); +} + +struct Client { + out: ws::Sender, +} + +impl ws::Handler for Client { + fn on_open(&mut self, _: ws::Handshake) -> ws::Result<()> { + self.out.send("This is the message. + It will be compressed by the client and sent to the server, which will decompress it + and send it back (recompressing it) for the client to then decompress and print.") + } + + fn on_message(&mut self, msg: ws::Message) -> ws::Result<()> { + println!("{}", msg); + self.out.clode(ws::CloseCode::Normal) + } +} +``` + + +### [Home](index.md) \ No newline at end of file diff --git a/docs/examples.md b/docs/examples.md new file mode 100644 index 0000000..0c9dc82 --- /dev/null +++ b/docs/examples.md @@ -0,0 +1,22 @@ +# Examples + +[Server](https://github.com/housleyjk/ws-rs/tree/stable/examples/server.rs) +A simple WebSocket echo server using closures. + +[Client](https://github.com/housleyjk/ws-rs/tree/stable/examples/client.rs) +A simple WebSocket client for connecting to an echo server using closures. + +[Shared](https://github.com/housleyjk/ws-rs/tree/stable/examples/shared.rs) +An example of an echo client and an echo server on one thread using closures. + +[Threaded](https://github.com/housleyjk/ws-rs/tree/stable/examples/threaded.rs) +An example of an echo client and an echo server on separate threads. This demonstrates using a struct as a WebSocket handler. + +[Channel](https://github.com/housleyjk/ws-rs/tree/stable/examples/channel.rs) +A more complex example using channels to communicate with a WebSocket handler to accomplish a separate task. + +[Pong](https://github.com/housleyjk/ws-rs/tree/stable/examples/pong.rs) +An example demonstrating how to send and recieve a custom ping/pong frame. + + +### [Home](index.md) \ No newline at end of file diff --git a/docs/guide.md b/docs/guide.md new file mode 100644 index 0000000..435b335 --- /dev/null +++ b/docs/guide.md @@ -0,0 +1,223 @@ +# Guide + +### [Home](index.md) + +### Installation + +To start using WS-RS simply add it to your ```Cargo.toml``` file. + +``` +[dependencies] +ws = "*" +``` +Using ```"*"``` will give you the latest stable version. If you want the development version, link to the master branch of the WS-RS respository. + +``` + [dependencies] + ws = { version = "*", git = "https://github.com/housleyjk/ws-rs"} +``` + +### Usage +For simple applications, use one of the utility functions ```listen``` and ```connect```: + +```listen``` accepts a string representation of a socket address and a ```Factory```. + +```rust +// A WebSocket echo server + +extern crate ws; + +use ws::listen; + +fn main() { + listen("127.0.0.1:3012", |out| { + move |msg| { + out.send(msg) + } + }).unwrap() +} +``` + +```connect``` accepts a string that represents a WebSocket URL (i.e. one that starts with ws:// or wss://), and it will attempt to connect to a WebSocket server at that location. It also accepts a ```Factory```. + +```rust +// A WebSocket client that sends one message then closes +extern crate ws; + +use ws::{connect, CloseCode}; + +fn main() { + connect("ws://127.0.0.1:3012", |out| { + out.send("Hello WebSocket").unwrap(); + + move |msg| { + println!("Got message: {}", msg); + out.close(CloseCode::Normal) + } + }).unwrap() +} +``` + +Each of these functions encapsulates a mio EventLoop, creating and running a WebSocket in the current thread. These are blocking functions, so they will only return after the encapsulated WebSocket has been shutdown. + +## Architecture + +A WebSocket requires two basic components: a Factory and a Handler. A Factory is any struct that implements the ```Factory``` trait. WS-RS already provides an implementation of ```Factory``` for closures that take a ```Sender``` as the first argument, so it is possible to pass a closure as a Factory to either of the utility functions. Your Factory will be called each time the underlying TCP connection has been successfully established, and it will need to return a Handler that will handle the new WebSocket connection. + +Factories can be used to manage state that applies to multiple WebSocket connections, whereas Handlers manage the state of individual connections. Most of the time, a closure Factory is sufficient, and you will only need to focus on writing your Handler. Your Factory will be passed a ```Sender``` struct that represents the output of the WebSocket. The Sender allows the Handler to send messages, initiate a WebSocket closing handshake by sending a close code, and other useful actions. If you need to send messages from other parts of your application it is possible to clone and send the Sender across threads allowing other code to send messages on the WebSocket without blocking the event loop. + +Just as with the Factory, it is possible to use a closure as a simple Handler. The closure must take a ```Message``` as it's only argument, and it may close over variables that exist in the Factory. For example, in getting started examples with ```listen``` and ```connect```, the closure Factory returns another closure as the Handler for the new connection. This handler closure closes over the variable ```out```, which is the Sender, representing the output of the WebSocket, so that it can use that sender later to send a Message. Closure Handlers generally need to take ownership of the variables that they close over because the Factory may be called multiple times. Think of Handlers as though they were running on separate threads and they should make sense within Rust's memory model. Closure Handlers must return a ```Result<()>```, in order to handle errors without panicking. + +Sender methods, such as ```close``` and ```send``` both actually return a ```Result<()>``` indicating whether they were able to schedule the requested command (either ```close``` or ```send```) with the EventLoop. + +**It is important that your Handler does not panic carelessly because a handler that panics will disconnect every other connection that is using that WebSocket. Don't panic unless you want all connections to immediately fail.** + +## Implementing a header + +You may have noticed in the usage examples that the client example calls ```unwrap``` when sending the first message, which will panic in the factory if the Message can't be sent for some reason. Also, sending messages before a handler is returned means that the message will be queued before the WebSocket handshake is complete. The handshake could fail for some reason, and then the queued message would be wasted effort. Sending messages in the Factory is not bad for simple, short-lived, or toy projects, but let's explore writing a handler that is better for long-running applications. In order to solve the problem of sending a message immediately when a WebSocket connection is established, you will need to write a Handler that implements the ```on_open``` method. For example: + +```rust +extern crate ws; + +use ws::{connect, Handler, Sender, Handshake, Result, Message, CloseCode}; + +// Our Handler struct. +// Here we explicity indicate that the Client needs a Sender, +// whereas a closure captures the Sender for us automatically. +struct Client { + out: Sender, +} + +// We implement the Handler trait for Client so that we can get more +// fine-grained control of the connection. +impl Handler for Client { + + // `on_open` will be called only after the WebSocket handshake is successful + // so at this point we know that the connection is ready to send/receive messages. + // We ignore the `Handshake` for now, but you could also use this method to setup + // Handler state or reject the connection based on the details of the Request + // or Response, such as by checking cookies or Auth headers. + fn on_open(&mut self, _: Handshake) -> Result<()> { + // Now we don't need to call unwrap since `on_open` returns a `Result<()>`. + // If this call fails, it will only result in this connection disconnecting. + self.out.send("Hello WebSocket") + } + + // `on_message` is roughly equivalent to the Handler closure. It takes a `Message` + // and returns a `Result<()>`. + fn on_message(&mut self, msg: Message) -> Result<()> { + // Close the connection when we get a response from the server + println!("Got message: {}", msg); + self.out.close(CloseCode::Normal) + } +} + +fn main() { + // Now, instead of a closure, the Factory returns a new instance of our Handler. + connect("ws://127.0.0.1:3012", |out| Client { out: out } ).unwrap() +} +``` + +That is a big increase in verbosity in order to accomplish the same effect as the original example, but this way is more flexible and gives you access to more of the underlying details of the WebSocket connection. + +It's also important to note that using ```on_open``` allows you to tie in to the lifecycle of the WebSocket. If the opening handshake is successful and ```on_open``` is called, the WebSocket is now open and alive. Until that point, it is not guaranteed that the connection will be upgraded. So, if you have important state that you need to tear down, or if you have some state that tracks closely the lifecycle of the WebScoket connection, it is best to set that up in the ```on_open``` method rather than when your handler is first created. If ```on_open``` returns Ok, then you are guaranteed that ```on_close``` will run when the WebSocket connection is about to go down, unless a panic has occurred. + +Therefore you will probably want to implement ```on_close```. This method is called anytime the WebSocket connection will close. The ```on_close``` method implements the closing handshake of the WebSocket protocol. Using ```on_close``` gives you a mechanism for informing the user regarding why the WebSocket connection may have been closed even if no errors were encountered. It also gives you an opportunity to clean up any resources or state that may be dependent on the connection that is now about to disconnect. An example server might use this as follows: + +```rust +extern crate ws; + +use ws::{listen, Handler, Sender, Result, Message, CloseCode}; + +struct Server { + out: Sender, +} + +impl Handler for Server { + + fn on_message(&mut self, msg: Message) -> Result<()> { + // Echo the message back + self.out.send(msg) + } + + fn on_close(&mut self, code: CloseCode, reason: &str) { + // The WebSocket protocol allows for a utf8 reason for the closing state after the + // close code. WS-RS will attempt to interpret this data as a utf8 description of the + // reason for closing the connection. I many cases, `reason` will be an empty string. + // So, you may not normally want to display `reason` to the user, + // but let's assume that we know that `reason` is human-readable. + match code { + CloseCode::Normal => println!("The client is done with the connection."), + CloseCode::Away => println!("The client is leaving the site."), + _ => println!("The client encountered an error: {}", reason), + } + } +} + +fn main() { + listen("127.0.0.1:3012", |out| Server { out: out } ).unwrap() +} +``` + +When errors occur, your handler will be informed via the ```on_error``` method. Depending on the type of the error, the connection may or may not be about to go down. If the error is such that the connection needs to close, your handler's ```on_close``` method will be called and WS-RS will send the appropriate close code to the other endpoint if possible. A server that tracks state related to the life of the WebSocket connection and informs the user of errors might be as follows: + +```rust +extern crate ws; + +use std::rc::Rc; +use std::cell::Cell; + +use ws::{listen, Handler, Sender, Result, Message, Handshake, CloseCode, Error}; + +struct Server { + out: Sender, + count: Rc>, +} + +impl Handler for Server { + + fn on_open(&mut self, _: Handshake) -> Result<()> { + // We have a new connection, so we increment the connection counter + Ok(self.count.set(self.count.get() + 1)) + } + + fn on_message(&mut self, msg: Message) -> Result<()> { + // Tell the user the current count + println!("The number of live connections is {}", self.count.get()); + + // Echo the message back + self.out.send(msg) + } + + fn on_close(&mut self, code: CloseCode, reason: &str) { + match code { + CloseCode::Normal => println!("The client is done with the connection."), + CloseCode::Away => println!("The client is leaving the site."), + CloseCode::Abnormal => println!( + "Closing handshake failed! Unable to obtain closing status from client."), + _ => println!("The client encountered an error: {}", reason), + } + + // The connection is going down, so we need to decrement the count + self.count.set(self.count.get() - 1) + } + + fn on_error(&mut self, err: Error) { + println!("The server encountered an error: {:?}", err); + } + +} + +fn main() { + // Cell gives us interior mutability so we can increment + // or decrement the count between handlers. + // Rc is a reference-counted box for sharing the count between handlers + // since each handler needs to own its contents. + let count = Rc::new(Cell::new(0)); + listen("127.0.0.1:3012", |out| { Server { out: out, count: count.clone() } }).unwrap() +} +``` + +There are other Handler methods that allow even more fine-grained access, but most applications will usually only need these four methods. + +### [Home](index.md) \ No newline at end of file diff --git a/docs/index.md b/docs/index.md new file mode 100644 index 0000000..7ce03cd --- /dev/null +++ b/docs/index.md @@ -0,0 +1,24 @@ +## Lightweight, event-driven WebSockets for Rust + +#### [Repository](https://github.com/housleyjk/ws-rs) + +### About +This library provides an implementation of WebSockets (RFC6455) in Rust. WS-RS uses [MIO](https://github.com/carllerche/mio) to leverage asynchronous IO to allow for handling multiple WebSocket connections on a single thread. WS-RS embraces the bidirectional nature of WebSockets allowing for both client and server connections to coexist as part of one WebSocket component. The WS-RS API aims to keep simple WebSocket applications simple and make advanced WebSocket programming possible in [Rust](https://rust-lang.org/) by abstracting away the menial parts of the WebSocket protocol while still providing enough low-level access to allow for custom extensions and subpotocols. For example, WS-RS supports the [permessage-deflate extension](deflate.md) as an optional feature. This library also supports SSL encrypted websockets using the [ssl feature](ssl.md). WS-RS is regularly tested and there are several [examples](examples.md) demonstrating various tasks that can be solved with WebSockets. Make sure to check out the [guide](guide.md) to help get started. The documentation is also available as a static page [here](https://docs.rs/ws/0.9.1/ws/). + +### Comparison with other WebSocket libraries +You don't need to use this library to the exclusion of other WebSocket libraries, in Rust or other languages, but if you find yourself considering which library to use: choose the one that has the API you like the most. The API is generally more important than performance. The library API is what you will have to deal with as you build your WebSocket application. The design of WS-RS aims to provide a clean, consistent API. If you identify possible improvements please make a [feature request](https://github.com/housleyjk/ws-rs/issues). + +However, if performance is what you value most and you want a WebSocket library in Rust please consider WS-RS. Here is how it stacks up against some other common frameworks using the example [benchmark tool](https://github.com/housleyjk/ws-rs/tree/stable/examples/bench.rs) to open 10,000 simultaneous connections and send 10 messages. These results are **not** reliable as a serious benchmark: + +Library | Time (ms) +:--- |:--- +WS-RS | 1,709 +libwebsockets | 2,067 +rust-websocket | 8,950 +\* websockets CPython 3.4.3 | 12,638 +Autobahn CPython 2.7.10 | 48,902 +\*\* NodeJS via ws | 127,635 + +\* websockets encountered a few (3) broken pipe errors +\*\* NodeJS encountered several (229) connection timeout errors +Your results will vary. The system specs for this test were as follows: Intel(R) Core(TM) i3 CPU 560 @ 3.33GHz, 8GB RAM \ No newline at end of file diff --git a/docs/ssl.md b/docs/ssl.md new file mode 100644 index 0000000..4b46630 --- /dev/null +++ b/docs/ssl.md @@ -0,0 +1,26 @@ +# SSL feature + +WS-RS supports WebSocket connections using SSL (e.g. `wss://my/secure/websocket`). To enable the ssl feature, require WS-RS in your ```Cargo.toml``` with the feature listed: + +``` +[dependencies.ws] +version = "*" +features = ["ssl"] +``` + +With the ssl feature enabled, you can connect to an encrypted socket by using the ```wss``` scheme. + +```rust +// An encypted Websocket echo client +extern crate ws; + +fn main() { + ws::connect("wss://localhost:3012", |out| { + move |msg| { + out.send(msg) + } + }) +} +``` + +### [Home](index.md) \ No newline at end of file