Example of using tcp/udp transport in a generic host

[natilivni]

I am interested in comparing cluster performance between http2, udp, and tcp as transport. It seems like the generic host JoinCluster is closely coupled with http transport. Have you thought about making the JoinCluster method configurable so that it can use any transport?

[sakno]

JoinCluster is an extension method for compatibility with ASP.NET Core and DI infrastructure. UDP/TCP transports are not relying on ASP.NET Core. You can write the wrapper by yourself if needed.

[sakno]

Anyway, I'll take a look at this in .NEXT 3.x which I'm currently working on.

[natilivni]

I think it would be a good idea. The protocol is just a transfer layer. Tcp, udp, http can all do the work and none of them are closely coupled to the dotnet core generic host pattern. Since JoinCluster is an extention method on IHostBuilder, it is not necessary to closely couple it to kestrel or http. If it sets up any communication layer and also registers the services, it would have wider application. If I build an extention method which does this, would you like me to create a pull request?

[sakno]

TCP and UDP transports were introduced for very advanced scenarios where the performance is a must-have. These implementations don't provide messaging capability between cluster nodes, only replication. So IMessageBus interface is not implemented. And I have no plans to do that. As a result, their integration into ASP.NET Core infrastructure gives illusion that they behave in the same way as the implementation for HTTP.

New extension method is far from complete support:

1. TCP/UDP implementation doesn't support membership changes. It should be implemented as well.
2. General-purpose messaging is not supported. And I will not do that on top of raw UDP/TCP because there are a lot of alternative implementations: NetMQ, RabbitMQ Client for .NET, MessagePack and tons of them. This is not a goal to develop Yet Another Fast Binary Protocol. The current implementation contains only Raft-specific messaging highly optimized for UDP and TCP.
3. Configuration extension methods for bridging between RaftCluster.NodeConfiguration class and ASP.NET Core configuration model.

As a result, I considered this work as low-priority. Anyway, feel free to make a PR.

[sakno]

One more thing, DotNext.AspNetCore.Cluster is not tightly coupled with Kestrel at all. Any OWIN-compatible Web Server or even IIS is allowed.