Ich habe ein Kommunikationssystem, das auf TcpClient basiert, und es funktioniert hervorragend, außer wenn HTTPS für eine bestimmte IP-Adresse ausgeführt wird. Dann fängt es an zu scheitern.

Bei Verwendung eines Browsers oder HttpWebRequest habe ich keine Probleme, HTTPS mit dieser IP-Adresse auszuführen.

Ich habe ein Testprogramm erstellt, um mein Problem auf das Wesentliche einzugrenzen. Sie können es hier ansehen, wenn Sie möchten: TestViaTcp

Das Testprogramm funktioniert perfekt für einfaches HTTP mit derselben IP-Adresse. Es gibt immer eine erfolgreiche Antwort auf die Anforderung. Ich lege es in eine Schleife, löse es mit einem Tastendruck aus, es wird den ganzen Tag über erfolgreich sein. Sobald ich das HTTPS umschalte, erhalte ich ein wiederkehrendes Muster. Es wird funktionieren, dann wird es nicht, Erfolg, gefolgt von Misserfolg, gefolgt von Erfolg den ganzen Tag hin und her.

Das besondere Versagen, das ich immer wieder bekomme, ist das Folgende:

{"Authentication failed because the remote party has closed the transport stream."}
    [System.IO.IOException]: {"Authentication failed because the remote party has closed the transport stream."}
    Data: {System.Collections.ListDictionaryInternal}
    HelpLink: null
    InnerException: null
    Message: "Authentication failed because the remote party has closed the transport stream."
    Source: "System"
    TargetSite: {Void StartReadFrame(Byte[], Int32, System.Net.AsyncProtocolRequest)}

Und hier ist der dazugehörige Stack-Trace:

   at System.Net.Security.SslState.StartReadFrame(Byte[] buffer, Int32 readBytes, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtoco,lRequest asyncRequest)
   at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)
   at System.Net.Security.SslStream.AuthenticateAsClient(String targetHost, X509CertificateCollection clientCertificates, SslProtocols enabledSslProtocols, Boolean checkCertificateRevocation)
   at DeriveClassNameSpace.Services.Web.TcpMessaging.TestViaTcp(IPEndPoint endpoint, String auth, Boolean useSSL)

HttpWebRequest und der Browser verwenden beide (IIRC) die Win32-Bibliotheken zur Abwicklung der Hin- und Her-Kommunikation, während TcpClient (AFAIK) die verwaltete .net-Socket-Klasse verwendet. Ich bin mir also sicher, dass es einen großen Unterschied zwischen ihnen gibt. Ich muss dies mit TcpClient tun, daher kann ich leider nicht einfach "HttpWebRequest verwenden, da ich weiß, dass ich es zum Laufen bringen kann".

Der größte Hinweis darauf, wo das Problem liegt, ist wahrscheinlich das Muster "funktioniert, funktioniert nicht, funktioniert nicht", was verursacht das? Was kann ich tun, um die IOException zu vermeiden, die ich erhalte? Gibt es eine Möglichkeit, das Verhalten "immer funktioniert" zu erhalten, das ich sehen kann, wenn ich HTTPS mit HttpWebRequest durchführe?

Es sollte etwas geben, das ich mit TcpClient tun kann, um es zum Handeln und Reagieren zu bringen, so wie es HttpWebRequest tut, aber ich bin noch nicht da. Irgendwelche Ideen

Hinweis: Der Server, mit dem ich kommuniziere, kann konfiguriert werden, welchen Port er abhört und welches Protokoll er erwartet, ist aber ansonsten vollständig nicht änderbar.

Auch Anmerkung: Ich habe gelesen, dass .net 3.5 dieses spezielle Problem mit SslStream vor SP1 hatte, aber ich habe SP1 und mein Programm ist mit Targeting 3.5 erstellt, also gehe ich davon aus, dass dies kein "bekannter Fehler" ist laufe hier rein.