Project Bedrock

Laying the foundation for the .NET Networking stack

Transcript

1. Project Bedrock Laying the foundation for the .NET Networking stack
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
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.
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)
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.
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 • …
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.
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.
9. Architecture: Transports IConnectionListener IConnectionFactory .NET Sockets Libuv WebSockets Named Pipes QUIC
10. Architecture: Middleware Connection Middleware (ConnectionDelegate) TLS Logging Compression Throttling Metrics
11. Architecture: Protocols ConnectionHandler HTTP MQTT AMQP SignalR RSocket
12. Architecture: The pipeline Transports Middleware Protocols
13. Architecture: The pipeline IConnectionListener Transport IConnectionFactory Connection Middleware Protocols
14. Example: HTTP Server/Client Sockets TLS ConnectionLimits Http1/Http2 QUIC ConnectionLimits Http3
15. Contribute to the project https://github.com/davidfowl/BedrockFramework @davidfowl