Skip to content

Just enough hacks to get unreliable unordered WebRTC data channels between a browser and a server

License

Notifications You must be signed in to change notification settings

kyren/webrtc-unreliable

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

webrtc-unreliable


Build Status Latest Version API Documentation

This is a Rust library which allows you to write a game server with browser based clients and UDP-like networking.

This crate is not meant as a general purpose WebRTC data channel system, it is instead designed to be used as the bottom level UDP-like transport layer of a higher level protocol in an environment where UDP is not available. It provides an async API for accepting WebRTC connections from browsers and sending and receiving WebRTC unreliable data channel messages from multiple clients.

The full set of protocols needed to implement WebRTC is daunting. This crate implements only the bare minimum subset of WebRTC required to support unreliable, unordered data channel messages. Because the WebRTC support is so minimal, this crate does not need to depend on a pre-existing heavyweight WebRTC implementation, but as such the protocol support is extremely limited.

You should expect only WebRTC data channels to function, and only in unreliable, unordered mode. Additionally, there is a stricter limit on WebRTC message lengths than what would be supported in a full WebRTC implementation. Only unfragmented SCTP packets are handled, so any message large enough to cause an SCTP packet to need fragmentation causes an error on write and is simply dropped on read. The maximum message length depends on the particular browser you connect with, but in my testing currently it is slightly smaller than 1200 bytes.

This crate is async runtime agnostic by relying on the implementation of a Runtime trait for required functionality. The requirements are minimal: a Sleep future and a UdpSocket with polled recv / send. A tokio implementation is provided with activation of the tokio feature.

Running the example

In a terminal:

$ cargo run --features tokio --example echo-server -- --data 127.0.0.1:42424 --http 127.0.0.1:8080 --public 127.0.0.1:42424

Then, using a web browser, go to 'http://127.0.0.1:8080/index.html'. Open the debug console, if everything is working correctly you should see messages being sent and received.

Please note that if you are using Firefox, Firefox does not accept WebRTC connections to 127.0.0.1, so you may need to use a different IP address.

Credit

This was originally a Rust / Tokio port of the WebUDP project, so the credit for the original design goes there.

License

This project is licensed under the MIT license

About

Just enough hacks to get unreliable unordered WebRTC data channels between a browser and a server

Resources

License

Stars

Watchers

Forks

Packages

No packages published

Languages