Ich verwende die BeginReceive() und EndReceive() -Methode für asynchrone IO mit Sockets in .NET. Der Client sendet fortlaufende Datenpakete, und der Aufruf von EndReceive() gibt die Anzahl der gelesenen Bytes zurück.So vermeiden Sie Socket.EndReceive() blockieren, wenn keine Daten verfügbar sind
Das Problem ist, dass der Client Datenpakete sendet, aber die Datenlänge ist NULL. Dies wurde durch die Analyse des Traffics in WireShark festgestellt. Wenn die Länge der Daten Null ist, wird der Aufruf von EndReceive() dort nur blockiert.
Gibt es eine Möglichkeit, die ZERO-Länge Daten zu identifizieren, ohne tatsächlich auf EndReceive() zu blockieren?
Die ReceiveTimeout-Eigenschaft scheint auch nicht mit Async-Methoden zu funktionieren.
Beispielquellcode:
// This method runs on a separate thread
private void ProcessRequest()
{
BeginReceive(OnClientReceive);
// Do some work here in a loop
}
// Callback method
private void OnClientReceive(IAsyncResult result)
{
int receivedCount = socket.EndReceive(result); // this one blocks
// Do some work here
// Again start listening for data
BeginReceive(OnClientReceive);
}
Ich denke, Aziz beantwortet Ihre Frage? Selbst wenn der Client Daten mit einer Länge von Null sendet, sollte EndRecieve ausgelöst und beendet werden. Wenn der Client den Socket vor Abschluss des Sendevorgangs schließt, sollte EndRecieve eine Exception auslösen, wenn die Socket-Fehler behoben sind. Ich denke, hier passiert etwas anderes ... Ich denke, es blockiert, weil der Client niemals sendet. Sind Sie sicher, dass der Client an dieselbe Steckdose sendet, die wartet? – Jess
Auch wenn der Client eine Null-Senden-Nachricht abschließt, sollte er dennoch die Nachrichtenkopfzeile senden und dann sollte EndRecieve diese empfangen und 0 empfangene Bytes zurückgeben. – Jess
Haben Sie die Kontrolle über den Client-Code? Können Sie den Fall erfassen, in dem Daten null sind, und einfach nicht senden? Dies könnte Ihr Problem lösen, aber ich glaube, es passiert noch etwas anderes. – Jess