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, geben IAsyncResult
  • Aufruf der TcpClient.EndConnect Methode mit der angegebenen IAsyncResult
  • NullReferenceException passiert auf EndConnect (?)
  • 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).

TcpClient.EndConnect wirft NullReferenceException wenn der socket geschlossen ist

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. 🙂
Schreibe einen Kommentar