All Projects → Maksims → Web Udp Public

Maksims / Web Udp Public

Licence: mit
Public demand for Web UDP

Projects that are alternatives of or similar to Web Udp Public

Quic.net
A .NET C# Implementation of QUIC protocol - Google's experimental transport layer.
Stars: ✭ 173 (-44.55%)
Mutual labels:  networking, udp
Computer Networking
Free resources for a self-taught education in Computer Networking
Stars: ✭ 201 (-35.58%)
Mutual labels:  networking, udp
Hazel Networking
Hazel Networking is a low level networking library for C# providing connection orientated, message based communication via TCP, UDP and RUDP.
Stars: ✭ 194 (-37.82%)
Mutual labels:  networking, udp
Ignorance
Ignorance utilizes the power of ENet to provide a reliable UDP networking transport for Mirror Networking.
Stars: ✭ 158 (-49.36%)
Mutual labels:  networking, udp
Drop watch
Monitor reasons why and where linux drops UDP packets
Stars: ✭ 289 (-7.37%)
Mutual labels:  networking, udp
Litenetlib
Lite reliable UDP library for Mono and .NET
Stars: ✭ 2,179 (+598.4%)
Mutual labels:  networking, udp
Netcode.io.net
A pure managed C# implementation of the Netcode.IO spec
Stars: ✭ 201 (-35.58%)
Mutual labels:  networking, udp
Objecttransport
Send and Receive objects over TCP or UDP
Stars: ✭ 39 (-87.5%)
Mutual labels:  networking, udp
Enet
⚡️ ENet reliable UDP networking library
Stars: ✭ 202 (-35.26%)
Mutual labels:  networking, udp
Benchmarknet
Benchmark for testing the reliable UDP networking solutions
Stars: ✭ 206 (-33.97%)
Mutual labels:  networking, udp
Ruffles
Lightweight and fully managed reliable UDP library.
Stars: ✭ 131 (-58.01%)
Mutual labels:  networking, udp
Wireguard Docs
📖 Unofficial WireGuard Documentation: Setup, Usage, Configuration, and full example setups for VPNs supporting both servers & roaming clients.
Stars: ✭ 3,201 (+925.96%)
Mutual labels:  networking, udp
Udp Ue4
Convenience UDP wrapper for Unreal Engine 4
Stars: ✭ 94 (-69.87%)
Mutual labels:  networking, udp
Spitfire
An easy to use WebRTC Datachannels library for .NET applications.
Stars: ✭ 164 (-47.44%)
Mutual labels:  networking, udp
Netdynamics
Data-oriented networking playground for the reliable UDP transports
Stars: ✭ 65 (-79.17%)
Mutual labels:  networking, udp
Netlink
Socket and Networking Library using msgpack.org[C++11]
Stars: ✭ 197 (-36.86%)
Mutual labels:  networking, udp
Ngtcp2
ngtcp2 project is an effort to implement IETF QUIC protocol
Stars: ✭ 589 (+88.78%)
Mutual labels:  networking, udp
Chill Netcat
UDP-only netcat implementation with OCaml / MirageOS
Stars: ✭ 13 (-95.83%)
Mutual labels:  networking, udp
Mirror
#1 Open Source Unity Networking Library
Stars: ✭ 2,905 (+831.09%)
Mutual labels:  networking, udp
React Native Udp
node's dgram for react-native
Stars: ✭ 238 (-23.72%)
Mutual labels:  networking, udp

WebSockets UDP (or alternative) Extension

This repo is to express public need for a technology to enable server-client low-latency communication, without mandatory reliability and/or ordered delivery mechanics of underlying transport protocol.

And shape the requirements from existing needs and potential future applications. To motivate W3C Members, IETF Community and Browser Vendors to start discussion and propose RFC to fuel further development for a solution.

PR's and discussions in Issues are welcome. Spread the word, RT's are welcome.

Table of Contents

Overview

Web evolved over past years rapidly, improving networking capabilities using such technologies as: WebSockets, WebRTC, HTTP/2, Server-Sent Events, QUIC.

Those technologies have own area of application and enabled web platform to have:

  1. Voice and video communication between browsers (WebRTC)
  2. Peer-to-peer data exchange (WebRTC)
  3. Real-time server-client communication (WebSockets)
  4. Faster website delivery (HTTP/2)
  5. Faster connection and transfer of data (QUIC)
  6. Efficient updating website content in real-time (Server-Sent Events)

and many more rich and powerful experiences

In recent years another medium have born: HTML5 Games. Adobe Flash is going away, and HTML5 games industry is steadily growing.

Which lead to birth of IO Games - one of the most accessible multiplayer games out there. Some of popular examples: agar.io, slither.io and many more. They all rely on currently the only viable technology for real-time server-client communication - WebSockets. WebRTC for server-client is overly complex (read further).

But this limits network capabilities as TCP for games has limits. It's worth mentioning that it's not only about the games - there are plenty use cases for low-latency unreliable and unordered server-client communications.

Problem

Latency and congestion. TCP has reliable and ordered packet delivery and is connection based protocol. The need of UDP (or alternative) over TCP is not under a question as it is widely discussed in many articles about benefits of UDP (or alternative) over TCP in different cases. Here we trying just to summarize it. Worth mentioning that UDP being the most popular, but not the only transport protocol option for this effort.

Reliability - this is not always desired by application logic, outdated information might not be relevant anymore and can be ignored. TCP will ensure delivery of packets, which leads to congestions that results in latency spikes due to need of acknowledgments and redelivery of packets. UDP (or alternative) does not guarantee reliability out of the box, thus avoids congestion problem which can be used as a benefit to ensure latest data is delivered ASAP.

Ordered Delivery - TCP uses sequencing and acknowledgments to guarantee ordered read and re-delivery of packets. This leads to blocking read, which leads to latency spikes and gets worse if network environment has higher packet loss.

Possible Solutions

Protocol that does not guarantee reliability and ordered delivery out of the box, allowing developer to implement any of the techniques on top of it if required or use hybrid approaches. This provides stable delivery timings and low latency in less than perfect network environments. With congestion control to mitigate overwhelming the internet infrastructure to address security concern.

1. WebSockets UDP (or alternative) Extension

One of the option to solve this, is by adding new extension to existing WebSockets protocol using negotiation mechanics described in RFC 6455. Which would implement extra functionality to establish UDP (or alternative) protocol communication. This would benefit from existing origin-based security model of WebSockets and allow developers to follow progressive approach where they can fall-back to TCP logic if such extension is not supported by either side (server or client).

2. WebUDP (or alternative) - new simple API

Another approach would be by developing completely new API, very similar to WebSockets that would address unique features of UDP (or alternative) networking logic, as well as potentially provide extra features for developer with fine-grain options of how to send messages.

3. WebRTC 2.0 - simplified

Current state of WebRTC is overly complex and was designed primarily for peer-to-peer communication. Due to this is not well adopted for server-client communication and requires a lot of developer resources. Simply speaking, it is not solo-web-dev friendly like WebSockets are today. Potential option of extending the spec to modularize and simplify the requirements that would allow use of some parts of WebRTC making it more accessible for server-client scenarios and simplified API that would make it more accessible for web developers.

4. WebTransport

There's a draft spec of the WebTransport API that allows web applications to establish interactive, bidirectional, multiplexed network connections - with support for both reliable and unreliable communication.

Requirements

  1. Security
  2. Origin-based security model - to prevent UDP (or alternative) probing (port scanning) and suit server-client networking model.
  3. Server-client - p2p is already solved by WebRTC, the goal of this effort is to find simple to adopt and use solution for server-client communication scenarios.
  4. Simple to use - WebSockets success is very much because of its simplicity to implement on server-side and how easy it is to use in the browser.
  5. Minimum header overhead - some of extra data framing over pure UDP (or alternative) will be potentially required but has to be kept at minimum.
  6. Minimum opinion or tech requirements - WebRTC suffers from complexity and requirements when WebSockets are minimal by that enabling rapid adaption by wide variety of platforms and web developers.

Security

Such API and underlying protocol implementation should address security concerns to make it web friendly:

  1. DDoS attacks - not exposing raw protocol functionality will utilize security practices similar to WebSockets.
  2. Ports scanning - using origin-based security model will require handshaking and validation of headers to prevent possibility to connect to any IPs and ports.
  3. Encryption - utilize existing encryption mechanics of HTTP/HTTPS.
  4. Congestion control - to avoid overflowing the internet infrastructure, the underlying transport protocol has to implement congestion control.

API should address those security concerns, without overcomplicating the API for front-end as well as implementation for the back-end. That's why UDPSocket is not an option.

Transport Protocols

List of potential underlying protocols that can be used for an implementation:

  1. DCCP (RFC-4340) - is connection based message protocol that implements feature negotiation and congestion control. It does not implement reliability or ordered delivery as part of a protocol leaving it to an application layer. This protocol also has DCCP-UDP (RFC-6773) implementation path over UDP to utilize existing NAT with UDP capabilities before DCCP is natively supported by internet infrastructure.
  2. QUIC (IETF Draft) - is fairly new connection-based transport layer protocol implemented by Google and available already in Chrome. It is fast growing and evolving protocol which is implemented on top of UDP. It is designed to reduce connection and transport latency as well as bandwidth. Although it has reliability built in which might be undesirable for current effort.
  3. SCTP (RFC-4960) - is standardized message based protocol with optional reliability and ordered delivery built in, as well as congestion control. It is also used in WebRTC for DataChannel. Due to adoption by WebRTC it lead to better support by internet infrastructure and implementations on OS level.
  4. DTLS (RFC-6347) - is a layer that can be implemented on top of transport protocol to provide security to meet web requirements. It is also used by WebRTC implementation.

Public discussions and demand

Potential first adapters

Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].