Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Project Bedrock

David Fowler
January 14, 2020

Project Bedrock

Laying the foundation for the .NET Networking stack

David Fowler

January 14, 2020

More Decks by David Fowler

Other Decks in Programming


  1. Why? • Writing good networking code is hard. • Usually

    full of manual memory management. • Tight control over threading. • Dealing with untrusted clients is usually an after thought (security is hard) • Good networking code is the core of lots of applications and components • HTTP Client/Servers • Database drivers • Proxies/Gateways/Routers • Caches • Core APIs only cover the basics
  2. Why? • New transport protocols appear all the time. Applications

    shouldn’t have to rewrite their networking stack to take advantage. • HTTP/2 • QUIC • Aeron • The ecosystem needs primitives to build application protocols on top of. • Without a trusted solution, the ecosystem recreates protocol implementations that aren’t reusable. • It allows experts to innovate at different parts of the networking stack while still leveraging other reusable components. • We can swap out the SSL implementation with something more efficient and still use ASP.NET Core and Kestrel. • Remove boilerplate from writing parsers and protocols. • Provide helpers to protocols authoring easy and efficient.
  3. Landscape • Java – Netty https://github.com/netty/netty • Rust – Tokio

    https://tokio.rs/ • Swift – SwiftNIO https://apple.github.io/swift- nio/docs/current/NIO/index.html • ServiceTalk - https://apple.github.io/servicetalk/servicetalk/SNAPSHOT/ • .NET – DotNetty https://github.com/Azure/DotNetty (port of the java framework)
  4. The Solution • We built SignalR and Kestrel on top

    of the same networking primitives. • We’ve been our own customers of this tech and have hardened it over a couple of .NET Core releases. • We have a couple of OSS projects using it already. We’re starting to see some demand from internal teams. • Orleans is using it and saw a 30% performance improvement. • MQTTnet is a popular OSS MQTT library built on top of it • Redhat built a better linux native sockets implementation on top. This beats our implementation on the TechEmpower benchmarks. • CoreWCF is built on top of this it.
  5. The Solution: Ecosystem • We want to seed an ecosystem

    of reusable application protocol implementations. • This should be a community driven effort, but we can seed implementations from .NET Core. • HTTP • WebSockets • TLS • AMQP • MQTT • …
  6. Architecture • The design is centered around 3 core concepts

    • Transports • Middleware • Protocols • ProtocolReader/ProtocolWriter • IMessageReader/IMessageWriter • Transports have support for both a server and a client • Servers and clients only differ in how they obtain a connection. • Single connection abstraction for server and client • Cross cutting concerns are middleware and can be applied to both servers and clients. • Protocols are terminal middleware (the last one in the chain) that transform the byte stream into other frames.
  7. Architecture: Connection abstraction • An abstraction over a connection shared

    between client and server • Loosely based on the same ideas ASP.NET Core’s HttpContext • “Features” allow the transport and middleware to flow rich context to the other layers in the stack.