TCP listener stuck while processing TLS handshake

[amoerie]

TCP listener stuck while processing TLS handshake

[aerik]

Ooooh, good find. I hadn't thought about that, but I've seen that too; the TLS connection routinely takes a couple seconds or more to finish the handshake. Seems like the only viable solution is to pull the TLS code out of the Networkstream constructor so that it can run in parallel to the listener continuing to listen...

[EDIT] Or - and this is maybe a little clunky - you could make some sort of lazy initializer happen inside AsStream... but if it failed, then we are potentially throwing in unexpected places

[amoerie]

@aerik I have a fix! #1767 ;-)

[aerik]

Hmm... You probably don't want to reference DesktopNetworkStream inside DicomServer...?

var networkStream = new DesktopNetworkStream(tcpClient, _tlsAcceptor, true);

What if you make an asynchronous method on the listener instead, so it will return the right kind of INetworkStream?

Maybe something like this

    var tcpClient = await listener.AcceptTcpClientAsync(noDelay, this.cancellationSource.Token).ConfigureAwait(false);
    if(tcpClient != null)
    {
        Task<INetworkStream> streamTask = listener.GetNetorkStream(tcpClient, this.certificateName);
        _ = streamTask.ContinueWith(task =>
        {
            if (!task.IsFaulted)
            {
                var scp = this.CreateScp(task.Result);
                if (this.Options != null)
                {
                    scp.Options = this.Options;
                }
                lock (_clientLocker)
                {
                    this.clients.Add(scp);
                }
            }
        });
    }

?

[EDIT] Just realized I don't need .ConfigureAwait(false) since it's not awaiting.

[amoerie]

Hmm... You probably don't want to reference DesktopNetworkStream inside DicomServer...?

Good call. There is already some "CreateNetworkStream" responsibility in INetworkManager so I'll add an overload there.