TcpClient.EndConnect wirft NullReferenceException wenn der socket geschlossen ist
Ich versuche eine Verbindung zu meinem server mit einer TcpClient.BeginConnect /TcpClient.EndConnect
combo. Allerdings werden einige Dinge nicht funktionieren wie Sie sollten.
Das Szenario ist wie folgt:
- Aufruf der
TcpClient.BeginConnect
- Server ist absichtlich offline (zum testen) - und damit keine Verbindung hergestellt werden kann.
- Ich die Anwendung schließen (
client.Close()
aufgerufen wird, in welche schließt den socket, die wiederum Stoppt den asynchronen Betrieb) TcpClient
Verbindung callback-Methode passiert, gebenIAsyncResult
- Aufruf der
TcpClient.EndConnect
Methode mit der angegebenenIAsyncResult
NullReferenceException
passiert aufEndConnect
(?)- Seit der letzten form (Fenster) geschlossen wurde, sollte die app beenden - allerdings nicht, zumindest solange nicht, bis
BeginConnect
- Vorgang abgeschlossen ist (das ist seltsam, als callback-wurde bereits genannt).
Was hier passiert, ist, dass ein NullReferenceException
gefangen ist. Wie Sie sehen können aus dem Bild oben, keine client
noch ar
sind null
. Das problem ist, dass die MSDN-Dokumentation für die EndConnect erwähnt nicht den Fall, in dem diese Ausnahme wird geworfen.
Also im Grunde, ich habe keine Ahnung, was Los ist. Das problem ist, dass ich gezwungen bin, zu warten, bis die app zu schließen (wenn die Verbindung-Betrieb noch wartet, bis ein timeout). Wenn ein server online ist, es verbindet und trennt einfach gut.
Was bedeutet NullReferenceException
in diesem Zusammenhang bedeuten? Wie zu vermeiden BeginConnect
Betrieb, die Anwendung zu blockieren schließen, falls die Verbindung kann nicht aufgebaut werden?
Zusätzliche Hinweise (beantragt Kommentare):
Hier ist der code zum erstellen der client - (client ist eine member-variable:
public void Connect()
{
try
{
lock (connectionAccess)
{
if (State.IsConnectable())
{
//Create a client
client = new TcpClient();
client.LingerState = new LingerOption(false, 0);
client.NoDelay = true;
State = CommunicationState.Connecting;
client.BeginConnect(address, port, onTcpClientConnectionEstablished, null);
}
else
{
//Ignore connecting request if a connection is in a state that is not connectable
}
}
}
catch
{
Close(true);
}
}
Auch die Close-Methode:
public void Close(bool causedByError)
{
lock (connectionAccess)
{
//Close the stream
if (clientStream != null)
clientStream.Close();
//Close the gateway
if (client != null)
client.Close();
//Empty the mailboxes
incomingMailbox.Clear();
outgoingMailbox.Clear();
State = causedByError ? CommunicationState.CommunicationError : CommunicationState.Disconnected;
}
}
- Hat die InnerException-evtl. mehr Informationen geben über das, was war "NULL"?
- NÖ. InnerException null ist. Keine Hilfe von den StackTrace zu (onTcpClientConnectionEstablished > EndConnect). 🙁
- Ja, eindeutig ein framework Fehler. In dem Fall, dass die TcpClient geschlossen ist, bevor EndConnect() aufgerufen wird, ist es eigentlich zu werfen ObjectDisposedException. Ich scheine zu bekommen NullReferenceException anstatt die ersten ein oder zwei mal, dann wird es anfangen zu werfen ObjectDisposedException als erwartet. Ich schlage vor, Sie einfach Griff in der gleichen war, als würden Sie ObjectDisposedException (z.B. "Zeitüberschreitung der Verbindung/Fehler/was auch immer andere Grund, den Sie genannt Close()"). Allerdings weiß ich nicht, ob alle Ressourcen, die möglicherweise undichten hier seit EndConnect() ist nicht abgeschlossen. Wahrscheinlich nichts, das die GC nicht umgehen können. 🙂
Du musst angemeldet sein, um einen Kommentar abzugeben.
Den
NullReferenceException
ist wahrscheinlich aufgrundTcpClient.Client
null.Wenn Sie Folgen Sie den MSDN-Beispiel für
TcpClient.BeginConnect
und übergeben Sie dieTcpClient
Objekt als Staat Objekt:Dieser soll den Fall behandeln, wenn
Close()
wird aufgerufen, bevor der Rückruf.Zurück zu deinem problem, wie lange dauert es, bis die Anwendung schließlich in der Nähe?
ar.AsycResult
solltear.AsyncState
. Post editiert, um auf änderungen.connectionAccess
verursacht die Verzögerung, die Sinn machen würde, wenn Sie nicht erleben Sie die Verzögerung beim Durchlaufen des Codes.Dies ist offensichtlich ein bug in der TcpClient-Klasse. Ich habe auch gegenüber. TcpClient.Entsorgen können Client-Feld auf null, aber EndConnect nicht erwarten, dass.
Ich hatte einen ähnlichen Fehler und landete mit diesem code. Ich bin nicht sicher, ob es halten wird mit der IASyncResult-Schnittstelle, aber es kann sein, einen ähnlichen Weg zu laufen, diese zu überprüfen. Ich merke, dass deine ar.AsyncState == null, so vielleicht versuchen Sie es, also ist es null, wenn Sie richtig verbinden?
EDIT: Sorry, ich wusste nicht, dass ich nicht posten, was erzeugt meine AsyncCompletedEventArgs, die mehr Bezug zu dem, was Sie tun. Sie werden sehen, der Grund, warum ich Frage mich, als ar.AsyncState null.
Dies ist bekannte Fehler.
Sollten Sie werden empfangen 'ObjectDisposedException' statt 'NullReferenceException'.