Skip to content

Decouple the Kestrel transport layer from Microsoft.AspNetCore.Hosting #11479

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
davidfowl opened this issue Jun 23, 2019 · 7 comments
Open
Labels
affected-very-few This issue impacts very few customers api-suggestion Early API idea and discussion, it is NOT ready for implementation area-networking Includes servers, yarp, json patch, bedrock, websockets, http client factory, and http abstractions 🥌 Bedrock breaking-change This issue / pr will introduce a breaking change, when resolved / merged. enhancement This issue represents an ask for new feature or an enhancement to an existing one severity-nice-to-have This label is used by an internal tool
Milestone

Comments

@davidfowl
Copy link
Member

Both Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets and Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv depend on Microsoft.AspNetCore.Hosting because they expose extension methods on IWebHostBuilder, with the move to generic host and exposing the ability to create client connections from these transports (#10872), it's odd to have this dependency.

It seems like to preserve UseSockets and UseLibuv, we'll need to have extensions methods like these somewhere, either on the IWebHostBuilder or on the IServiceCollection. It seems like we'll need to introduce new packages to that have just the code without the extensions and another one that has the wire up code (much like we have the kestrel meta package today).

cc @shirhatti @anurse

@analogrelay
Copy link
Contributor

Feels post-3.0 based on your description :). But sounds like goodness

@analogrelay
Copy link
Contributor

analogrelay commented Jun 25, 2019

Work in 3.0:

  • Make sure the only public things in the transport packages are the extension methods. OR any public types are in the expected final namespace so they can be Type Forwarded.

Post 3.0:

  • New Packages: Microsoft.AspNetCore[?].Transports.[Sockets/Libuv] with extension methods that hang off IServiceCollection
  • Keep the old packages as back-compat for the IWebHostBuilder extension methods.

@analogrelay analogrelay added this to the 3.0.0-preview8 milestone Jun 25, 2019
@analogrelay analogrelay added breaking-change This issue / pr will introduce a breaking change, when resolved / merged. enhancement This issue represents an ask for new feature or an enhancement to an existing one and removed triage-review labels Jun 25, 2019
@analogrelay
Copy link
Contributor

This feels super at risk for 3.0.

@analogrelay
Copy link
Contributor

If we don't take it in 3.0, the next main place is 5.0 which isn't LTS anyway so it's perfect to do a major reshuffle like this.

@davidfowl davidfowl added the api-suggestion Early API idea and discussion, it is NOT ready for implementation label Jul 22, 2019
@analogrelay analogrelay modified the milestones: 3.0.0-preview8, Backlog Jul 23, 2019
@analogrelay
Copy link
Contributor

It's too late, among the other things, to try and squeeze this in. It sounds like a good fit for 5.0 though.

@davidfowl
Copy link
Member Author

Agreed

@davidfowl davidfowl modified the milestones: Backlog, 5.0.0-alpha1 Aug 14, 2019
@analogrelay analogrelay removed this from the 5.0.0-preview1 milestone Mar 11, 2020
@analogrelay analogrelay added this to the Backlog milestone Mar 23, 2020
@jkotalik jkotalik added affected-very-few This issue impacts very few customers severity-nice-to-have This label is used by an internal tool labels Nov 12, 2020 — with ASP.NET Core Issue Ranking
@amcasey amcasey added area-networking Includes servers, yarp, json patch, bedrock, websockets, http client factory, and http abstractions and removed area-runtime labels Jun 2, 2023
@AntonPetrov83
Copy link

AntonPetrov83 commented Nov 26, 2023

Upvoted this ticket.

I love SocketConnection implementation and to me it looks natural to make entire Transport.Sockets namespace available outside of Kestrel and web hosting.

Would be nice to have it available for generic host too.

Actually it is doable now, maybe it is just an undoccumented feature?

var host = Host.CreateDefaultBuilder(args)
    .ConfigureServices((context, services) =>
    {
        services.AddSingleton<IConnectionListenerFactory, SocketTransportFactory>();
    })
    .Build();

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
affected-very-few This issue impacts very few customers api-suggestion Early API idea and discussion, it is NOT ready for implementation area-networking Includes servers, yarp, json patch, bedrock, websockets, http client factory, and http abstractions 🥌 Bedrock breaking-change This issue / pr will introduce a breaking change, when resolved / merged. enhancement This issue represents an ask for new feature or an enhancement to an existing one severity-nice-to-have This label is used by an internal tool
Projects
None yet
Development

No branches or pull requests

7 participants