Kestrel with MemoryTransport

[Ninds]

Hi,
I am making use of Bedrock or at least some components of Bedrock in building a small framework for multiprotocol Kestrel based services.
Briefly the design is as follows :
When an app based on the framework is launched it starts up a (parent) Kestrel service bound to a socket.
In addition a pool of AssemblyLoadContexts are spun up.
Each of these ALCs hosts an instance of a (child) Kestrel.
Each child Kestrel however is bound to a (Bedrock) MemoryEndPoint not a socket.
The parent Kestrel is enhanced with a connectionhandler that dispatches each incoming ConnectionContext to an available child Kestrel from the pool.

All of this works and works very well ….. WITH a small modifcation.
Kestrel will only bind to an IPEndPoint not an EndPoint. I therefore modified Bedrock.Framework/Transports/Memory/MemoryEndPoint.cs
to inherit from IPEndPoint and implemented the method Create(SocketAddress) with a no-op.
That’s essentially the design and it meets the requirements.

Further I have also investigated binding the parent Kestrel to a MemoryEndPoint instead of a socket. This was accomplished by adding IConnectionListnerFactory & IConnectionFactory to the service provider.
This ability would certainly be quite useful for testing. However when the ConnectionContext (born in the MemoryTransport) is sent down the kestrel pipeline a NullReferenceException is thrown . It transpires that the feature IMemoryPoolFeature is required and missing. When this feature is set on the ConnectionContext everything appears to work.

What doesn't work however is if you want to simultaneously bind your parent kestrel to a socket AND a MemoryEndPoint. This would again be a very useful feature.

Can it be envisaged that some of these quite modest modifications be added to Bedrock ? Currently I am taking the source files from Bedrock but would prefer to take them and leave them unmodified.

I have spoken with @Drawaes and he told me MemoryEndPoint was never designed to be used with Kestrel. But it could be :-)

Thanks
N

[Drawaes]

I suspect that the Memory feature that kestrel is expecting should be delt with there. If it was up to me I would make the component that is expecting that fall back to the default shared memory pool if the memory pool feature is unavailable.

[davidfowl]

Ah yes, I think it's reasonable to implement the IMemoryPoolFeature (I actually thought I fixed Kestrel to not require it but it looks like not).

As for the end point thing, it's going to be fixed in 5 dotnet/aspnetcore#12428. Though it's currently in the backlog. It's not a huge change to make.

[davidfowl]

@Ninds send a pull request with the changes let me take a look.

[halter73]

What doesn't work however is if you want to simultaneously bind your parent kestrel to a socket AND a MemoryEndPoint. This would again be a very useful feature.

This is an interesting idea. Kestrel would need to be able to use multiple different IConnectionListenerFactories simultaneously which isn't possible today. It would also require something like a KestrelServerOptions.Listen() API that accepts arbitrary EndPoint types (Edit: It looks like this is described by dotnet/aspnetcore#12428).

One way to support this would be to provide a mechanism to test if a factory supports an endpoint, and a way to specify the order factories should be tried in. I suppose we could just test if BindAsync throws to check endpoint support, and use DI's IEnumerable ordering to determine preference order.

I think @davidfowl was looking into an API that would allow you to specify which IConnectionListenerFactory to use for each endpoint you tell Kestrel to listen on, but maybe I'm misremembering (Edit: dotnet/aspnetcore#15006). Either way, this might be preferable to testing factories against endpoints in preference order as I suggest above, since it gives even more explicit control and flexibility.

This also seems a little bit related into @jkotalik's IMultiplexedConnectionListenerFactory API proposal (dotnet/aspnetcore#17037). @jkotalik's proposal is dealing with how to deal with transport-level multiplexing, but Kestrel will need to support using multiple transports simultaneously to support QUIC and HTTP/3.

I suspect that the Memory feature that kestrel is expecting should be delt with there. If it was up to me I would make the component that is expecting that fall back to the default shared memory pool if the memory pool feature is unavailable.

Agreed.

[Drawaes]

This also seems a little bit related into @jkotalik's IMultiplexedConnectionListenerFactory API proposal (dotnet/aspnetcore#17037). @jkotalik's proposal is dealing with how to deal with transport-level multiplexing, but Kestrel will need to support using multiple transports simultaneously to support QUIC and HTTP/3.

That's the solution we came to when looking at this as actually Kestrel takes a single factory but making a factory that takes an IEnumerable of factories it it's constructor first allows you to have more than one type of listener.

[Ninds]

@davidfowl My first modification, to have MemoryEndPoint inherit from IPEndpoint instead of EndPoint is clearly a temporary workaround that will be made unnecessary by dotnet/aspnetcore#12428. The second change required would be, given Tim's comments, in
aspnetcore/src/Servers/Kestrel/Core/src/Middleware/HttpConnectionMiddleware.cs
to change
MemoryPool = memoryPoolFeature.MemoryPool
in OnConnectionAsync to
MemoryPool = memoryPoolFeature?.MemoryPool ?? System.Buffers.MemoryPool<byte>.Shared

So I have created a pull request for that.

[davidfowl]

This should be fixed now