Unterschied zwischen NetworkStream.Read() und NetworkStream.BeginRead()?

Muss ich Lesen von NetworkStream würde Daten senden nach dem Zufallsprinzip und die Größe von Datenpaketen halten Sie auch unterschiedliche. Ich bin Implementierung einer multi-threaded-Anwendung, wo jeder thread seinen eigenen stream zum Lesen aus. Wenn es keine Daten auf den stream, muss die Anwendung warten, bis die Daten ankommen. Allerdings, wenn der server das senden der Daten und der Beendigung der Sitzung, dann sollte es beenden.

Zunächst hatte ich nutzte die Read Methode, um die Daten aus dem stream, aber es verwendet, um den thread zu blockieren und warten, bis die Daten erschienen auf dem stream.

In der Dokumentation auf der MSDN-Website schlägt vor,

Wenn keine Daten zum Lesen verfügbar sind,
die Read-Methode gibt 0 zurück. Wenn die
remote-host beendet die Verbindung,
alle verfügbaren Daten wurden
empfangen werden, wird die Read-Methode abgeschlossen ist
und sofort wieder von null bytes.

Aber in meinem Fall, ich habe noch nie die Read Methode 0 zurück und würdevoll beenden. Es wartet einfach nur auf unbestimmte Zeit.

In weitere nachforschungen stieß ich auf BeginRead die Uhren des Streams und ruft eine callback-Methode asynchron, sobald er die Daten empfängt. Ich habe versucht, zu suchen für verschiedene Implementierungen, mit diesem Ansatz als gut, allerdings war ich nicht in der Lage zu erkennen, Wann wäre mit BeginRead vorteilhaft sein, im Gegensatz zu Read.

Wie ich es sehe BeginRead hat nur den Vorteil, dass die asynchronen Aufruf, die blockiert den aktuellen thread. Aber in meiner Anwendung habe ich bereits einen separaten thread zu Lesen und zu verarbeiten die Daten aus dem stream, so dass würde nicht viel Unterschied für mich.

  • Kann jemand bitte helfen Sie mir zu verstehen, die Warten und Exit-Mechanismus für die
    BeginRead und wie unterscheidet es sich von Read?

  • Was wäre die beste Art der Umsetzung der gewünschten Funktionalität?

  • Sind Sie sicher, dass der remote-Seite ist richtig Herunterfahren die Verbindung? Ich hatte noch nie ein problem mit Read nicht zurück. Dein Ansatz, ansonsten scheint die richtige Richtung.
  • Nun, ehrlich gesagt, ich kann nicht sagen, dass für sicher. Seine Dritte Leistung, die wir Lesen. Sie haben angegeben das shutdown-Zeiten und wir gehen davon aus, dass es so geschieht, wie erwähnt. Ich will einfach nur, um zu überprüfen, und überprüfen Sie noch einmal an mein Ende der ersten vor dem auslösen eine fahne zu Ihnen.
InformationsquelleAutor Danish Khan | 2010-12-08
  1. 12

    Benutze ich BeginRead aber weiterhin blockiert den thread mit einem WaitHandle:

    byte[] readBuffer = new byte[32];
var asyncReader = stream.BeginRead(readBuffer, 0, readBuffer.Length, 
    null, null);

WaitHandle handle = asyncReader.AsyncWaitHandle;

//Give the reader 2seconds to respond with a value
bool completed = handle.WaitOne(2000, false);
if (completed)
{
    int bytesRead = stream.EndRead(asyncReader);

    StringBuilder message = new StringBuilder();
    message.Append(Encoding.ASCII.GetString(readBuffer, 0, bytesRead));
}

    Grundsätzlich ist es erlaubt einen timeout der asynchrone Lesevorgänge verwenden den WaitHandle und gibt einen booleschen Wert ( completed ), wenn das Lesen abgeschlossen wurde, in der eingestellten Zeit (2000 in diesem Fall).

    Hier mein full-stream-Lesung-code kopiert und eingefügt von einer meiner Windows-Mobile-Projekte:

    private static bool GetResponse(NetworkStream stream, out string response)
{
    byte[] readBuffer = new byte[32];
    var asyncReader = stream.BeginRead(readBuffer, 0, readBuffer.Length, null, null);
    WaitHandle handle = asyncReader.AsyncWaitHandle;

    //Give the reader 2seconds to respond with a value
    bool completed = handle.WaitOne(2000, false);
    if (completed)
    {
        int bytesRead = stream.EndRead(asyncReader);

        StringBuilder message = new StringBuilder();
        message.Append(Encoding.ASCII.GetString(readBuffer, 0, bytesRead));

        if (bytesRead == readBuffer.Length)
        {
            //There's possibly more than 32 bytes to read, so get the next 
            //section of the response
            string continuedResponse;
            if (GetResponse(stream, out continuedResponse))
            {
                message.Append(continuedResponse);
            }
        }

        response = message.ToString();
        return true;
    }
    else
    {
        int bytesRead = stream.EndRead(asyncReader);
        if (bytesRead == 0)
        {
            //0 bytes were returned, so the read has finished
            response = string.Empty;
            return true;
        }
        else
        {
            throw new TimeoutException(
                "The device failed to read in an appropriate amount of time.");
        }
    }
}
    • Danke @GenericTypeTea, Das sieht aus wie ein interessanter Ansatz, aber es gibt keine Möglichkeit für mich, um zu bestimmen, eine korrekte timeout-Zeit. Dennoch, ich denke, dies kann sein ein bisschen modifiziert, um eine Auflösung zu meinem problem. Ich würde versuchen, und berichten, falls es erfolgreich. BTW, der Griff hat mich lächelnd.. 🙂
    • Wenn ich mich nicht Irre muss man immer anrufen EndABC auf jeden BeginABC nennen. Im obigen code, wenn es zu einem timeout, das Ende wird nie genannt. Einen Rückruf, Anrufe zu Beenden (und behandelt alle möglichen Ausnahmen) sollte wohl Hinzugefügt werden, um den obigen code.
    • Ich glaube, Sie sind verwechselt. Ich habe immer anrufen ein Ende: int bytesRead = stream.EndRead(asyncReader);, aber vielleicht sollte ich ändern den code aufrufen, der code unmittelbar nach der Zeile bool fertig = handle.WaitOne(2000, false); damit entfernen Sie die Duplizierung.
    InformationsquelleAutor djdd87
  2. 4

    Async I/O kann benutzt werden, um die gleiche Menge an I/O in weniger threads.

    Als Sie merken sich jetzt Ihre app hat ein thread pro Stream. Das ist OK, mit einer geringen Anzahl von verbindungen, aber was, wenn Sie Bedarf an Unterstützung von 10000 auf einmal? Mit async I/O, ist dies nicht mehr notwendig, da die lese-completion-Rückruf können-Kontext übergeben werden, der die Identifizierung von relevanten stream. Ihr liest nicht mehr blockieren, so brauchen Sie nicht ein thread pro Stream.

    Ob sync oder async I/O, es ist ein Weg, zu erkennen und zu behandeln stream closedown auf die jeweiligen API-return-codes. BeginRead ausfallen sollte mit IOException-wenn der socket ist bereits geschlossen. Eine Abschaltung während die asynchrone Lesen ist anhängig wird daraufhin ein Rückruf, und EndRead wird, dann sagen Sie die state of play.

    Wenn Ihre Anwendung fordert BeginRead,
    das system wartet, bis die Daten
    empfangen wird oder ein Fehler Auftritt, und dann
    das system wird mit einem separaten thread
    zum ausführen der angegebenen callback
    Methode, und Blöcke auf EndRead bis
    die bereitgestellten NetworkStream liest Daten
    oder eine Ausnahme auslöst.

    • Danke @Steve. Das ein thread pro stream ist durch viele andere design-überlegungen und ist nicht wirklich ein Problem. Hätten wir 10 gleichzeitigen threads in der max.
    InformationsquelleAutor Steve Townsend
  3. 0

    Haben Sie versucht, die server.ReceiveTimeout? Sie können die Zeit einstellen, die Read () - functon warten darauf, dass die ankommenden Daten vor der Rückgabe null. In Ihrem Fall, diese Eigenschaft ist wahrscheinlich unendlich irgendwo.

    InformationsquelleAutor Огњен Шобајић
  4. 0

    BeginRead ist ein asynchroner Prozess, was bedeutet, dass Ihre Haupt-thread starten, ausführen, Lesen Sie in einem anderen Prozess. So jetzt haben wir 2 parallele Prozesse. wenn u wollen, um das Ergebnis zu erhalten, u haben, zu nennen, EndRead, die das Ergebnis liefert.

    einige psudo

    BeginRead()
//...do something in main object while result is fetching in another thread
var result = EndRead();

    aber wenn dein main thread hat nichts anderes zu tun, und u haben zu müssen, das Ergebnis, u should Read aufrufen.

    • Die Implikation, dass mehrere Prozesse beteiligt sind, ist hier völlig falsch.
    • Steve, ich glaube, @ Bonshington meinte "Thread", wenn er sagte, 'Prozess'.
    InformationsquelleAutor Bonshington
Schreibe einen Kommentar