dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
14.96k stars 4.65k forks source link

SSLStream write delay on Android #106885

Closed Santoshramani closed 2 days ago

Santoshramani commented 3 weeks ago

I have Xamarin native project which I've migrated to dotnet project using dotnet SDK 8.0. In this I've one feature in which i'm sending camera frames to server using TCP SSL communication so, when project was in xamarin framework this communication was working good and speed of SslStream write was around 1ms(to get send callback from socket) but now in migrated dotnet project with same code SslStream write is taking around 4-5ms(to get send callback from socket).

This is happening in only in ANDROID. IOS is still working fine.

Both platform uses same Socket from System.Net.Sockets package and SslStream from System.Net.Security package.

Output of dotnet --info

.NET SDK:
 Version:           8.0.401
 Commit:            811edcc344
 Workload version:  8.0.400-manifests.56cd0383
 MSBuild version:   17.11.4+37eb419ad

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  14.6
 OS Platform: Darwin
 RID:         osx-arm64
 Base Path:   /usr/local/share/dotnet/sdk/8.0.401/

.NET workloads installed:
Configured to use loose manifests when installing new manifests.
 [ios]
   Installation Source: SDK 8.0.400
   Manifest Version:    17.5.8020/8.0.100
   Manifest Path:       /usr/local/share/dotnet/sdk-manifests/8.0.100/microsoft.net.sdk.ios/17.5.8020/WorkloadManifest.json
   Install Type:        FileBased

 [android]
   Installation Source: SDK 8.0.400
   Manifest Version:    34.0.113/8.0.100
   Manifest Path:       /usr/local/share/dotnet/sdk-manifests/8.0.100/microsoft.net.sdk.android/34.0.113/WorkloadManifest.json
   Install Type:        FileBased

Host:
  Version:      8.0.8
  Architecture: arm64
  Commit:       08338fcaa5

.NET SDKs installed:
  8.0.303 [/usr/local/share/dotnet/sdk]
  8.0.401 [/usr/local/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 6.0.32 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.20 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.0 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.7 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.8 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 6.0.32 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.20 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.0 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.7 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.8 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
  None

Environment variables:
  Not set

global.json file:
  Not found
baronfel commented 3 weeks ago

@jonathanpeppers do you know the best way to route Android+runtime related issues?

jonathanpeppers commented 3 weeks ago

Since this is using SslStream directly, I think we move it to dotnet/runtime.

If they were using HttpClient, it's possible the issue could be dotnet/android because we have AndroidMessageHandler.

wfurt commented 3 weeks ago

Make sure you set NoDelay on the Socket @Santoshramani. Since SslStream takes stream to write you, you can easily write wrapper stream to check if the delay truly comes from the SSL.

Santoshramani commented 6 days ago

@wfurt Thanks but NoDelay is not working.

wfurt commented 6 days ago

Perhaps you can try to write wrapper Stream to track the IO. Since pretty much all the SslStream primitives are synchronous I would be surprised if that really comes from SslStream directly. Perhaps @simonrozsival may have more insight. Also some repro app would be beneficial IMHO. It is going to be difficult to investigate as currently written.

simonrozsival commented 4 days ago

The only thing I can think of is that it might be possible this is related to an issue we fixed in .NET 9: #95295. Previously, we would often split the data across more TLS frames than on other platforms. Although I'm not sure if that could account for the write delay you're observing. @Santoshramani could you try testing with .NET 9 RC 1 if the delay is still present?

Santoshramani commented 2 days ago

@simonrozsival Thanks a lot for your response It's working superb now. But can you please tell when will SDK 9 be available in stable release.

simonrozsival commented 2 days ago

@Santoshramani thanks for trying it out. I'm glad the problem is resolved in the current RC. The release date for stable .NET 9 should be in mid November during .NET Conf.

I'm closing this issue now since this has been fixed in .NET 9 and there are no plans to backport the relevant changes to .NET 8.

wfurt commented 2 days ago

note that rc1 already gets support and it should be ready for consumption