Frage zu ReceiveNetworkData

[Jilocasin]

Deshalb sollte man sich für eigene Anwendungen unbedingt ein eigenes Containerformat fürs Netzwerk basteln
Aber in diesem Fall haben wir das ja schon, mehr oder weniger.

[Nino]

@Nino

Deine Variante wäre die richtige Variante abzubrechen wenn der Buffer des von ReceiveNetworkData() zuende ausgelesen wurde.
Aber nur weil nichts mehr im Buffer steht, heißt nicht, dass alles empfangen wurde, wie ja auf meinem ersten Beispiel hervorgeht.

Das war ja das, was mich irritiert hat.

Und so steht es ja auch in der Hilfe:
"'Ergebnis' gibt die Anzahl an tatsächlich bereits gelesenen Bytes an."

Da gehts nur ums lesen des Buffers, nicht um das eigentlich emfangen von Daten.

Ahh, das ist es. Ich hatte "gelesen" mit "empfangen" gleichgesetzt. Vielen Dank für die Erklärung!

Grüße, Nino

[Stevie63]

Wenn ich bis jetzt alles richtig verstanden habe und auch meinen Grübeleien Glauben schenken darf, komme ich auf jeden Fall nicht drum herum, die genaue Größe der gesendeten Daten zu kennen. Nochmals als Bsp. einen HTTP-Post-Request:
Gesendete Datenlänge: 5000 Bytes (steht in Content-Length)
Diese 5000 Bytes werden aufgrund der MTU in mehrere Pakete gesplittet, z.B. 14xx 14xx 14xx yyyy.

Mein Empfangspuffer ist 60kB groß. Obwohl alle 5000 Bytes "in einem Rutsch" reinpassen würde, werde ich (ich spekuliere jetzt mal) nur das erste Paket, was durch das Splitten entstanden ist mit ReceiveNetworkData empfangen. Jetzt ist das erste Paket natürlich kleiner als der Puffer und (da war wahrscheinlich mein Fehler) man könnte jetzt meinen, mit dem Empfangen aufhören zu können. Das ist aber falsch (richtig?). Denn die restlichen Pakete, die durch das Splitten entstanden sind, kriege ich nur durch einen erneute Aufrufe von NetworkServerEvent und dann ReceiveNetworkData. Der Wert von Content-Length aus dem ersten Paket beschränkt sich nicht auf die Länge der Daten im ersten Paket sondern meint die Gesamtdatenlänge aller Pakete (im zweiten Paket kommt kein HTTP-Header, z.B. 'POST xyz.html HTTP/1.1' etc vor).

Bin ich auf der richtigen Spur?

Grüße

Stevie

[Nino]

Was ist denn mit den Events?
Solange noch Daten empfangen werden, wird doch noch ein NetworkServerEvent() vom Typ #PB_NetworkEvent_Data ausgelöst, oder? Hieße das nicht, dass alle gesendeten Daten empfangen wurden, wenn kein solches Ereignis mehr eintritt?

Falls man das an Hand der Events nicht erkennen kann, bleibt als Kriterium ja nur noch die Länge oder eine eindeutige Ende-Markierung.

Grüße Nino

[Jilocasin]

Im Grunde richtig. Auf den Rückgabewert vom Receive kannst du dich in keinem Fall verlassen ob alles "gesendete auch angekommen ist." Der sagt ja nur aus, ob momentan der Puffer noch etwas hat, oder nicht.
Um den kompletten Request wirklich zu bekommen müsstest du immer beim Event den Puffer leer lesen, das Empfangene an einen temporären Speicher dranhängen und dann schauen ob du einen "ganzen" Request darin findest.

Außerdem hab ich bisher festgestellt, dass es auch darauf ankommt, "wann" man genau ReceiveNetworkData aufruft.
nehmen wir mal an, ich sende als Client viele 100 Byte Blöcke. Hab ichs direkt nach dem Event schon gemacht (was ja der Normalfall sein dürfte) kamen z.B. wirklich nur 100 Byte an (Trotz großer Buffer Größe im ReceiveNetworkData). Würde man zwischen dem #PB_NetworkEvent_Data und dem ReceiveNetworkData nur als Beispiel ein Delay(2000) schreiben ist es schon viel warscheinlicher, dass man mehr empfängt. Ist schwierig zu erklären, aber da das ganze Empfangen von Paketen insgesamt immer asynchron im Hintergrund geschieht, kann ReceiveNetworkData nur komplette, empfangene Pakete ausgeben. Aber davon eben soviele wie es gerade im Hintergrundbuffer hat (an den man nicht direkt heran kommt).
Andere Verdeutlichung: Bekommt man ein "Hier ist ein Paket für sie" und schaut sofort in den Briefkasten findet man ein einziges Paket. Bekommt man die Meldung und schaut erst zwei Stunden später in den Briefkasten, könnte es sein, dass der Postbote in der Zwischenzeit noch ein paar mehr reingeworfen hat und man diese aber dennoch in einem Gang zum Briefkasten (ReceiveNetworkData bis der Buffer leer ist) holen kann.

[helpy]

Hallo zusammen,

Ich mache das zur Zeit so:

1. Mit ReceiveNetworkData die anstehenden Daten einlesen und an die Daten in einem Zwischenspeicher anhängen. Je nach Länge der gesendeten Datenblöcke, können das mehrere kleine Datenblöcke oder auch nur ein Teil eines größeren Datenblocks sein.
2. Eine Routine, die auswertet, ob im Zwischenspeicher vollständige Daten vorhanden sind. Wenn ja, gebe ich die gültigen/vollständigen Daten zur weiteren Bearbeitung frei.

Bei einem HTTP-Request muss man immer auch die empfangenen Daten auswerten, ob der Request vollständig angekommen ist. Wie das auszuwerten ist, ist in der RFC 2616 ausführlichst beschrieben!

cu, guido

[STARGÅTE]

@Stevie63

Spur? Ja ... wie genau das bei HTTP geregelt ist, scheinst du ja in dem von helpy geposteten Link entnehmen zu können.

@Nino
Nein, wenn NetworkServerEvent() kein #PB_NetworkEvent_Data zurück gibt, heißt das nur das genau in diesem Augenblick keine Daten im Buffer sind, es könnten aber noch Daten zu einem Paket unterwegs sein, was vorallem bei langsammen leitungen der Fall ist, denn Send ist ja nun auch nicht SOFORT ^^


@helpy
Jo, so mach ich das auch "ähnlich" ...
allerdings, kann ich mit meinem "System" auch nur meine Daten senden/empfangen, weils halt n art kleinen Header gibt, geben muss.

[reiner jakob]

hi,

wir sind nach gleichen Problemen nach vielem Grübeln auf die fast gleiche Lösung gekommen. Auf unseren Xp Rechnern läuft das stabil.
Auf Windows 7 (client,64-bit), mit 32bit compiliert, funktioniert die gleiche Software über's netz nicht.

Weis jemand, woher die Probleme stammen können ?

reiner

[reiner jakob]

hi,

problem hat sich gelöst,
es lag an der comodo-firewall (auch wenn diese deaktivert oder prozess komplett beendet war!)
bei installation der comodo auf winxp hatten wir dann die gleichen probleme wieder. nach der
deinstallation läuft alles wieder bestens.

reiner