Probleme mit Datenempfang über asynchronen Socket

[sx2008]

Mal so ganz grundsätzlich:
Auf der Empfangsseite darfst du keinerlei Erwartungen haben, wieviele Bytes auf einen Rutsch eintreffen.
Stell' Dir einfach vor, ein Zufallsgenerator würde dem Empfänger die Bytes zuteilen.
Angenommen der Sender schickt 4 Bytes Länge + 100 Bytes Objektdaten.
Am Empfänger könnten zuerst 15 Bytes und dann 89 Bytes eintreffen.
Oder auch 3 Bytes, 64 Bytes und dann 85 Bytes.
(das wären in der Summe mehr als 104 Bytes denn ein Teil der nächsten Message hängt noch hinten dran)

Daher muss der empfangene Datenblock an einen Puffer angehängt werden.
Danach wird untersucht, ob eine vollständige Message im Puffer enthalten ist.
Falls ja, die Message aus dem Puffer ausschneiden, Message verarbeiten und schauen ob noch eine weitere Message im Puffer ist.

[Meflin]

Zitat von sx2008:

Auf der Empfangsseite darfst du keinerlei Erwartungen haben, wieviele Bytes auf einen Rutsch eintreffen.
Stell' Dir einfach vor, ein Zufallsgenerator würde dem Empfänger die Bytes zuteilen.

Das ist mir durchaus bewusst - auf der Netzwerkebene. ABER: genau davon sollte doch ein TCP-Socket bereits abstrahieren. Müsste ich die TCP Segmente manuell wieder zusammensetzen, könnte ich mir ja das Protokoll sparen - oder ist dies bereits eine Fehlannahme

Und so viel ist sicher: Der Socket-Callback wird auch nicht per Segment aufgerufen. Leider halt auch nicht per Paket, was logischerweise durch dieses dämliche Buffergehandhabe auch garnicht möglich wäre (wegen potentiell größerer Pakete).

so ganz schlau werde ich aus der Sache noch nicht...

[Satty67]

Liest Du hier nicht ab dem falschen offset das Objekt?

Code:

state.receivedObject.Write(state.buffer, 0, bytesRead);

state.buffer ist ja ein byte[] array und kein Stream, der die zuletzt gelesenen Position behält. Würde zumindest auf den ersten Blick die Abweichungen um 4 Byte erklären.

state und damit state.lengthRead ist auch lokal innerhalb des Handlers deklariert und somit bei jedem Aufruf erst einmal false. Passt nur, wenn der Handler pro Objekt-Abruf nicht mehr als einmal aufgerufen wird (kenne aber die Logik des Handlers nicht)

[Meflin]

Zitat von Satty67:

Liest Du hier nicht ab dem falschen offset das Objekt?

Ich denke nicht. Alles was im Buffer steht wird ja ausgelesen und der nächste Callback durch das aufrufen von BeginReceive ausgelöst (bessergesagt ermöglicht), womit auch von vorne in den Buffer geschrieben wird.

Zitat:

Würde zumindest auf den ersten Blick die Abweichungen um 4 Byte erklären.

Die 4 Byte Abweichung ist richtig. Problematisch sind die <-- markierten Stellen

[Satty67]

Ja aber beim ersten Aufruf des Handlers pro Objekt, gehören die ersten 4 Byte ja nicht zum Objekt. Werden aber auch da mit in den Stream geschrieben.

Kommt der zweite Aufruf beim gleichen Objekt, werden wieder 4 Byte als Längen Angabe ermittelt, obwohl diesmal alle Bytes zum Objekt gehören (weil state lokal definiert ist).

€: Ok... rekusrsiver Aufruf mit Übergabe des alten state. Der erste Teil sollte aber trotzdem wie beschrieben falsch alufen.

[Meflin]

Zitat von Satty67:

Kommt der zweite Aufruf beim gleichen Objekt, werden wieder 4 Byte als Längen Angabe ermittelt, obwohl diesmal alle Bytes zum Objekt gehören (weil state lokal definiert ist).

Der state wird ja beim Aufruf von Receive erstellt. Das wird aber pro Objekt nur einmal aufgerufen. Was öfter aufgerufen wird ist ReceiveCallback, aber da wird der State ja nur wiederverwendet. Ich bin mir relativ sicher, dass das nicht das problem ist. Andernfalls würde ja mit jedem ReceiveCallback auch ein neuer length-Wert gelesen, und das wäre mit relativ hoher Wahrscheinlichkeit eine sehr große Zahl (kaum aufeinanderfolgende Nullbytes in den Daten). Damit würde auch das Console.Log sehr viel später erreicht.

Zum Thema 4-Byte-Differenz: siehe mein Edit im vorigen Beitrag. Das stimmt so, ist nur ne Ausgabesache

[Satty67]

Ja, OK

War wohl zuviel information im ersten Post. Hatte auch zu spät gesehen, dass state als Parameter wiederverwendet wird und mich an der wenig relevanten 4-Byte Abweichung festgekrallt.