Netzwerkdaten kommen nicht in einem Stück an

[PMV]

Fals du dich traust ein bischen mehr mit Zeigern zu arbeiten:
Du kannst auch Longs senden. Diese haben immer 4 Byte länge, so
brauchst du keine "Füllbytes", fals nicht alle 10-Zeichen für die Zahl als
String verwendet werden und du müsstest nicht ständig zwischen Long
und String konvertieren.

Code: Alles auswählen

Len.l = Len(String)
SendNetworkData(#ConID, @Len, SizeOf(LONG))

Empfangen tust so wie sonnst, nur das du dann kein PeekS() sondern
ein mal PeekL() für jedes Paket nutzt.

MFG PMV

[mk-soft]

Die Datenpackete nicht zu klein senden. Es kommt ja immer die gesamten Header dazu.
- Mac->IP->TCP->Daten

Eigene Headerstruktur würde ich so aufbauen

Code: Alles auswählen

Structure udtHeader
  Ident.w
  Version.w
  Command.w
  Size.w
EndStructure

Einige Beispiele für CLI-Server (Varserver) und Streamserver findet ihr auf
http://home.arcor.de/m_kastner/MyCodes/PB4/

FF

[dreamtec]

Fals du dich traust ein bischen mehr mit Zeigern zu arbeiten:
Du kannst auch Longs senden. Diese haben immer 4 Byte länge, so
brauchst du keine "Füllbytes", fals nicht alle 10-Zeichen für die Zahl als
String verwendet werden und du müsstest nicht ständig zwischen Long
und String konvertieren.

Code: Alles auswählen

Len.l = Len(String)
SendNetworkData(#ConID, @Len, SizeOf(LONG))

Empfangen tust so wie sonnst, nur das du dann kein PeekS() sondern
ein mal PeekL() für jedes Paket nutzt.

MFG PMV

An diese Möglichkeit habe ich bisher noch gar nicht gedacht.
Das Prinzip von Zeigern habe ich eigentlich (durch mein derzeitiges Studium) verstanden (glaube ich zumindest).

Also ich würd das jetzt so machen, dass ich einfach mit hilfe von PokeL die länge des strings+4 ermittle ( +4, weil ich ja auch PokeL berücksichtigen muss), diesen in den Buffer reinschreibe, dann mit PokeS dahinter meinen String anhänge und zum schluss die Daten sende.

Und beim Empfänger schau ich mir einfach die ersten 4 Bytes mithilfe von PeekL an, überprüfe ob die Länge der Empfangenen Daten dem Wert von PeekL entspricht, und arbeite dementsprechend weiter.

Würde das so funktionieren, oder habe ich da was falsch verstanden?



@mk-soft

Ich weiss, wie das TCP/IP Protokoll funktioniert, und wie es auch aufgebaut ist. Nur verstehe ich grad nicht, was das Problem ist, wenn die Pakete zu klein sind und ich deshalb die Headerstruktur ändern sollte.

Vermute ich richtig, dass ich durch das Senden von kleinen Datenpacketen im endeffekt erheblich mehr Headerinformationen sende, als ich an Daten eigentlich habe, und somit mein Netzwerk unnötigerweise überlaste?

[PMV]

Sorry das ich jetzt erst schreib, kam die letzten Tage leider nur zum
mitlesen.

Ob du in die Long nun die 4 Byte dieses Variablentypes mit berücksichtigst
oder nicht spielt eigentlich keine wirkliche Rolle. Wichtig ist, dass du dir
das irgend wo merkst/ aufschreibst, damit du das auch später noch weist
wei du das gemacht hast.

Wichtig ist, dass du bei den Längenangaben nicht durcheinander kommst.
Vorallem bei PokeS() musst du aufpassen. PokeS() schreibt nämlich immer
ein NULL hinter den String. Du musst also entweder schauen, dass dein
Speicherbereich wo du deine String rein schreiben willst
4 + Stringlänge + 1 groß ist. Alternativ kannst du aber auch
CopyMemory() verwenden. So oder so brauchst du das NULL natürlich
nicht mit senden.

MFG PMV

[Brügge]

hi

ich hatte das problem auch schon...
das lag daran, das ich zu schnell gesendet habe.
anscheinend dauert das empfangen länger als das senden...

ich habe das so gelöst.

beim sender habe ich eine schleife laufen lassen, mit einem etwas höheren delay als beim empfänger...

danach ging es supiee! ^^

hoffe ich konnte dir weiterhelfen!

[dreamtec]

@PMV

Hi, danke für den Hinweis. Das mit dem NULL zeichen habe dank der PureBasic-Hilfe gewusst (hat mir stundenlange fehlersuche erspart )

Aufjedenfall läufts jetzt einwandfrei. Danke euch allen für die Hilfe.


@Brügge
Das Problem mit dem zu schnellen Datensenden kenne ich. Dies konnte aber mein Problem nicht lösen.
Ich sende nämlich nicht viele kleine Daten hintereinander, sondern einen großen Datensatz in einem Stück. Und solange nicht alles gesendet wurde, macht der sender nicht weiter. Von daher bringt das höhere delay nichts.