Korrekte Behandlung von Netzwerk-Timeouts unter Windows CE

Question

Ich versuche einen relativ einfachen TCP-Socket-Sende-/Empfangsvorgang unter Windows CE mit .NET Compact Framework durchzuführen. Ich versuche, den Timeout-Wert so festzulegen, dass das Lesen/Schreiben bei einem langsamen Verbindungstimeout statt für immer blockiert wird. Auf dem gesamten Framework kann ich einfach die ReceiveTimeout und SendTimeout Eigenschaften auf dem Socket Objekt festlegen. Leider führt das Setzen dieser Eigenschaften auf das kompakte Framework sofort zu einer SocketException über die Verwendung einer nicht unterstützten Socket-Option.

Nach ein wenig weiter zu graben, stieß ich auf this Seite, die das folgende sagt:

 
    The following table shows BSD options not supported for setsockopt: 

    Value   Type  Description 
    SO_ACCEPTCONN BOOL  Sets socket listening. 
    SO_RCVLOWAT  int  Sets recv low watermark. 
    SO_RCVTIMEO  int  Sets time-out for recv. 
    SO_SNDLOWAT  int  Sets send low watermark. 
    SO_SNDTIMEO  int  Sets time-out value for send. 
    SO_TYPE   int  Sets socket type. 

So sieht es nicht wie Windows CE Timeouts unterstützt. Bei einer nicht mehr reagierenden Verbindung kommt es zu einem Timeout, aber es dauert ungefähr eine Minute (muss in WinCE fest codiert sein). Jetzt versuche ich herauszufinden, wie man das manuell implementiert. Mein erster Gedanke ist, asynchrone IO zu verwenden, die mir erlaubt. Dies wird jedoch nicht den asynchronen Thread stoppen, der auf EndSend() oder EndReceive() stecken wird. Selbst wenn ich meinen Hauptthread aussetzen kann, werden immer noch Threads herumstehen, bis das festgeschriebene Timeout erreicht ist. Während dieser Zeit wird meine Anwendung nicht ordnungsgemäß heruntergefahren. Die einzige Möglichkeit, um dieses Problem zu umgehen, wäre, den asynchronen Thread abzubrechen, aber das scheint eine sehr schlechte Idee zu sein, und würde ich gerne vermeiden.

Also, was ist der richtige Weg, damit umzugehen? Es muss einen einfachen Weg geben, da andere Anwendungen (z. B. IE auf WinCE) scheinbar keine Schwierigkeiten haben, ausstehende Netzwerkoperationen zu terminieren oder zu löschen, und sie scheinen in der Lage zu sein, auch ohne Probleme herunterzufahren.

Answer 1

Ich fand einen sauberen Weg, dies zu tun. Grundsätzlich mache ich das Senden und Empfangen in einem separaten Thread und warte dann auf ein Ereignis (manuelles oder automatisches Zurücksetzen sollte funktionieren). Wenn die Wartezeit abgelaufen ist, wird der blockierende Lese-/Schreibzugriff in dem anderen Thread durch einfaches Schließen (oder Entsorgen) des Sockets aufgehoben, wodurch ein Fehler verursacht wird (eine Exception wird auf den Send()/Receive() -Aufruf für diesen Thread ausgelöst). Hoffentlich wird dies für jemand anderen hilfreich sein ...