Project Bedrock

1fe64ebb176498be5f73ab51986c6b7b?s=47 David Fowler
January 14, 2020

Project Bedrock

Laying the foundation for the .NET Networking stack

1fe64ebb176498be5f73ab51986c6b7b?s=128

David Fowler

January 14, 2020
Tweet

Transcript

  1. 2.

    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. 3.

    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. 4.

    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. 5.

    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. 6.

    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. 7.

    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. 8.

    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.