-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
add support for abstract namespaces in Unix domain sockets #77931
Comments
Tagging subscribers to this area: @dotnet/ncl Issue DetailsIt would be wonderful if support for abstract namespaces in Unix domain sockets was added.
This is something that may benefit several WSL scenarios.
|
In my current use case, I was able to start
Unfortunately, I can't connect to it using the GenevaExporter.
Program.cs using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;
using IHost host = Host.CreateDefaultBuilder(args)
.ConfigureLogging(logging =>
logging.AddOpenTelemetry(openTelemetryLogger=>
{
openTelemetryLogger.AddGenevaLogExporter(genevaExporter =>
{
genevaExporter.ConnectionString = "Endpoint=unix:/home/cataggar/mdsd_fluent.socket";
});
})
)
.ConfigureServices((_, services) =>
services.AddHostedService<Worker>()
)
.Build();
await host.RunAsync();
internal class Worker : IHostedService
{
ILogger log;
public Worker(ILogger<Worker> log)
{
this.log = log;
}
public Task StartAsync(CancellationToken cancellationToken)
{
log.LogInformation("start");
return Task.CompletedTask;
}
public Task StopAsync(CancellationToken cancellationToken)
{
log.LogInformation("stop");
return Task.CompletedTask;
}
} csproj <Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net6.0</TargetFramework>
<ImplicitUsings>enable</ImplicitUsings>
<Nullable>enable</Nullable>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.Extensions.Hosting" Version="6.0.1" />
<PackageReference Include="Microsoft.Extensions.Logging" Version="6.0.0" />
<!-- The releases in August allows setting the TraceFlags, but avoids updating System.Diagnostics.DiagnosticSource -->
<!-- https://github.com/open-telemetry/opentelemetry-dotnet/blob/main/src/OpenTelemetry.Api/CHANGELOG.md -->
<PackageReference Include="OpenTelemetry.Api" Version="1.4.0-alpha.1" />
<PackageReference Include="OpenTelemetry.Exporter.Geneva" Version="1.3.0" />
<PackageReference Include="OpenTelemetry.Extensions.Hosting" Version="1.0.0-rc9.5" />
<PackageReference Include="OpenTelemetry.Instrumentation.Http" Version="1.0.0-rc9.5" />
</ItemGroup>
</Project> |
They're already supported on Linux and have been for years. Can you elaborate on what doesn't work? Paths that begin with null runtime/src/libraries/System.Net.Sockets/tests/FunctionalTests/UnixDomainSocketTest.cs Lines 389 to 404 in 15f015f
|
Unix sockets were supported as an interoperability bridge between Linux and Windows under WSL1. Unless things changed recently, they killed them in WSL2. Using WSL1 today is very niche (and I would not be surprised if they kill it altogether at some point). Of course they do work in WSL2, but not as Windows<->Linux interopability anymore. Just local to Linux, as in any Linux system. For portable zero-conf networking today (ie, avoiding TCP for some reason), the preferred method would be AF_HYPERV+AF_VSOCK. |
I think this is because for isolation win WSL2 -> I'm not sure we can cross the OS boundaries inside of .NET. |
This issue has been marked |
It is not a WSL issue. Forget that I mentioned WSL at all. Can support be added for Linux abstract namespaces in Unix domain sockets? |
@cataggar, as I noted in #77931 (comment), UnixDomainSocketEndPoint in .NET already supports abstract addresses. What specifically isn't working? |
Thanks for pointing that out again, @stephentoub. Closing this. |
It would be wonderful if support for abstract namespaces in Unix domain sockets was added.
This is something that may benefit several WSL scenarios.https://devblogs.microsoft.com/commandline/af_unix-comes-to-windows/
https://devblogs.microsoft.com/commandline/windowswsl-interop-with-af_unix/
The text was updated successfully, but these errors were encountered: