Ich hab ihn durchgelesen, aber ich wollt halt meine Idee auch posten. Die Idee von dir liest ja solange bis keine Daten mehr empfangen werden, die ist also nicht ganz korrekt, denn es könnte zwischendurch ein NaS(Not a String, wär eigentlich mal gut einzuführen, da es ja auch NaN gibt) sein.Laurin hat geschrieben:> Da steht, dass die Puffergröße nur 8 Kilobyte groß ist. Ist das schlimm, wenn mein STring, 10 KB groß ist?
> Dann wird dein String halt bei den 8KB abgeschnitten.
Habt ihr euch den Quelltext nicht durchgelesen? Da ist eine Schleife.
Wenn die Daten > 8 KB sind, dann wird sie nochmal durchlaufen , sodass alle Daten abgefragt werden.
Kann mir einer ein "ReceiveNetworkString()" bastel
-
DarkDragon
- Beiträge: 6291
- Registriert: 29.08.2004 08:37
- Computerausstattung: Hoffentlich bald keine mehr
- Kontaktdaten:
Angenommen es gäbe einen Algorithmus mit imaginärer Laufzeit O(i * n), dann gilt O((i * n)^2) = O(-1 * n^2) d.h. wenn man diesen Algorithmus verschachtelt ist er fertig, bevor er angefangen hat.
danke euch, Jungs.
Laurin, sei mir bitte nicht böse, ich denke, ich nehme dann eher den code von DarkDragon, wegen der 0 am Ende. Scheint mir sicherer zu sein, dass zwei vom Client gesendete Strings nicht verssehentlich in einen einzigen String vom Server gepackt werden.
Dabei hatte ich deinen Code, Laurin, schon etxra abgespeichert und zur späteren Verwendung vorbereitet...
mal ne andere Frage an euch:
Egal ob ich ein Spiel schreibe oder eine GUI-Applikation. Wenn ich Daten habe, die möglichst schnell ankommen sollen, lohnt es sich dann, diese Daten irgendwie zu komprimieren? Oder wenn es Daten sind, die wenigstens leicht verschlüsselt werden sollen? Oder wenn es sich um einen Ping handelt?
Wie bekommt ich diese Daten am schnellsten rüber? Gibt es noch andere Dinge, die man beachten muss, um ein Netzwerk optimal zu nutzen?
Und was ich noch gehört habe ist: Bei SendNetworkFile() und ReceiveNetworkFile(9 wird (angeblich) das Programm solange angehalten, bis die Datei drüben ist. Stimmt das? Ist das bei SendNetworkString() genauso?
Laurin, sei mir bitte nicht böse, ich denke, ich nehme dann eher den code von DarkDragon, wegen der 0 am Ende. Scheint mir sicherer zu sein, dass zwei vom Client gesendete Strings nicht verssehentlich in einen einzigen String vom Server gepackt werden.
Dabei hatte ich deinen Code, Laurin, schon etxra abgespeichert und zur späteren Verwendung vorbereitet...
mal ne andere Frage an euch:
Egal ob ich ein Spiel schreibe oder eine GUI-Applikation. Wenn ich Daten habe, die möglichst schnell ankommen sollen, lohnt es sich dann, diese Daten irgendwie zu komprimieren? Oder wenn es Daten sind, die wenigstens leicht verschlüsselt werden sollen? Oder wenn es sich um einen Ping handelt?
Wie bekommt ich diese Daten am schnellsten rüber? Gibt es noch andere Dinge, die man beachten muss, um ein Netzwerk optimal zu nutzen?
Und was ich noch gehört habe ist: Bei SendNetworkFile() und ReceiveNetworkFile(9 wird (angeblich) das Programm solange angehalten, bis die Datei drüben ist. Stimmt das? Ist das bei SendNetworkString() genauso?
PB 4.30
Code: Alles auswählen
Macro Happy
;-)
EndMacro
Happy End
> Laurin, sei mir bitte nicht böse
Ach iwo.
> Dabei hatte ich deinen Code, Laurin, schon etxra abgespeichert und zur späteren Verwendung vorbereitet...
Das genügt mir
> Wenn ich Daten habe, die möglichst schnell ankommen sollen, lohnt es sich
> dann, diese Daten irgendwie zu komprimieren?
Das kommt darauf an. Einen Ping würde ich nicht komprimieren. Die paar Bytes lohnen den Rechenaufwand gar nicht. Anders sieht es bei größeren Datenmengen aus, da sollte man schon eine Komprimierung verwenden. Du müsstest mal ausprobieren, ab welchen Mengen sich eine Komprimierung lohnt.
> Wie bekommt ich diese Daten am schnellsten rüber?
Die Schnelligkeit, mit der die Pakete durch die Leitung rauschen, kannst du nicht (oder nur in sehr geringem Maße, zB MTU einstellen) beeinflußen. Das Einzige, was du machen kannst, ist die zu übertragende Datenmenge so gering wie möglich zu halten. Entweder durch Komprimierung oder nur Senden absolut notwediger Daten oder ein Mix aus den beiden Sachen.
> Gibt es noch andere Dinge, die man beachten muss, um ein Netzwerk
> optimal zu nutzen?
Nicht über Kabel stolpern
(Passiert mir auf jeder LAN-Party :/)
> Bei SendNetworkFile() und ReceiveNetworkFile(9 wird (angeblich) das
> Programm solange angehalten, bis die Datei drüben ist.
Ja.
> Ist das bei SendNetworkString() genauso?
Öhm... ja. Allerdings kannst du selber festlegen, wieviele Daten empfangen werden sollen bis der Empfang (vorläufig) unterbrochen wird. Denk an die Puffergröße.
Ach iwo.
> Dabei hatte ich deinen Code, Laurin, schon etxra abgespeichert und zur späteren Verwendung vorbereitet...
Das genügt mir
> Wenn ich Daten habe, die möglichst schnell ankommen sollen, lohnt es sich
> dann, diese Daten irgendwie zu komprimieren?
Das kommt darauf an. Einen Ping würde ich nicht komprimieren. Die paar Bytes lohnen den Rechenaufwand gar nicht. Anders sieht es bei größeren Datenmengen aus, da sollte man schon eine Komprimierung verwenden. Du müsstest mal ausprobieren, ab welchen Mengen sich eine Komprimierung lohnt.
> Wie bekommt ich diese Daten am schnellsten rüber?
Die Schnelligkeit, mit der die Pakete durch die Leitung rauschen, kannst du nicht (oder nur in sehr geringem Maße, zB MTU einstellen) beeinflußen. Das Einzige, was du machen kannst, ist die zu übertragende Datenmenge so gering wie möglich zu halten. Entweder durch Komprimierung oder nur Senden absolut notwediger Daten oder ein Mix aus den beiden Sachen.
> Gibt es noch andere Dinge, die man beachten muss, um ein Netzwerk
> optimal zu nutzen?
Nicht über Kabel stolpern
(Passiert mir auf jeder LAN-Party :/)> Bei SendNetworkFile() und ReceiveNetworkFile(9 wird (angeblich) das
> Programm solange angehalten, bis die Datei drüben ist.
Ja.
> Ist das bei SendNetworkString() genauso?
Öhm... ja. Allerdings kannst du selber festlegen, wieviele Daten empfangen werden sollen bis der Empfang (vorläufig) unterbrochen wird. Denk an die Puffergröße.
Now these points of data make a beautiful line.
And we're out of beta. We're releasing on time.
And we're out of beta. We're releasing on time.
> Laurin, sei mir bitte nicht böse
Ach iwo.
Das ist gut!
Einen Ping würde ich nicht komprimieren. Die paar Bytes lohnen den Rechenaufwand gar nicht.
OK, ja das stimmt.
Du müsstest mal ausprobieren, ab welchen Mengen sich eine Komprimierung lohnt.
Hab ich mir schon gedacht, aber: "Probieren geht über studieren!"
Nicht über Kabel stolpern (Passiert mir auf jeder LAN-Party :-/ )
OK, das ist wahrhaftig ein Argument... Wie wärs mit W-LAN?
Allerdings kannst du selber festlegen, wieviele Daten empfangen werden sollen bis der Empfang (vorläufig) unterbrochen wird. Denk an die Puffergröße.
Stimmt, bei 8 KB Puffergröße würde ja automatisch agberochen, wenn der String 10 KB groß wäre. Aber der Client würde weitersenden, ne?
Übrigens: Wenn beim TCP/IP Protokoll ein paket nicht ankommt, muss es ja nochmal gesendet werden. Muss ich dann die Daten selbst neu senden, oder übernimmt das PureBasic, Windows oder wer-auch-immer?
Ach iwo.
Das ist gut!
Einen Ping würde ich nicht komprimieren. Die paar Bytes lohnen den Rechenaufwand gar nicht.
OK, ja das stimmt.
Du müsstest mal ausprobieren, ab welchen Mengen sich eine Komprimierung lohnt.
Hab ich mir schon gedacht, aber: "Probieren geht über studieren!"
Nicht über Kabel stolpern (Passiert mir auf jeder LAN-Party :-/ )
OK, das ist wahrhaftig ein Argument... Wie wärs mit W-LAN?
Allerdings kannst du selber festlegen, wieviele Daten empfangen werden sollen bis der Empfang (vorläufig) unterbrochen wird. Denk an die Puffergröße.
Stimmt, bei 8 KB Puffergröße würde ja automatisch agberochen, wenn der String 10 KB groß wäre. Aber der Client würde weitersenden, ne?
Übrigens: Wenn beim TCP/IP Protokoll ein paket nicht ankommt, muss es ja nochmal gesendet werden. Muss ich dann die Daten selbst neu senden, oder übernimmt das PureBasic, Windows oder wer-auch-immer?
PB 4.30
Code: Alles auswählen
Macro Happy
;-)
EndMacro
Happy End> Stimmt, bei 8 KB Puffergröße würde ja automatisch agberochen, wenn der
> String 10 KB groß wäre. Aber der Client würde weitersenden, ne?
Nach 8 KB wird nicht abgebrochen, das habe ich schon gesagt. Nach 8 KB fängt die Schleife nur neu an, so dass weitere 8 KB eingelesen werden. Die Schleife kannst du aber auch rausnehmen, dann werden nur 8 KB eingelesen.
Der Client/Server kann währenddessen ruhig weitersenden, kein Byte an Daten geht verloren.
> Übrigens: Wenn beim TCP/IP Protokoll ein paket nicht ankommt, muss es
> ja nochmal gesendet werden. Muss ich dann die Daten selbst neu senden,
> oder übernimmt das PureBasic, Windows oder wer-auch-immer?
Das übernimmt das TCP/IP-Protokoll. Du musst da nix tun.
Du hast nur anzugeben, welche Daten gesendet werden sollen, TCP übernimmt das eigendliche Senden, korrigiert Sendefehler automatisch, etc.
> String 10 KB groß wäre. Aber der Client würde weitersenden, ne?
Nach 8 KB wird nicht abgebrochen, das habe ich schon gesagt. Nach 8 KB fängt die Schleife nur neu an, so dass weitere 8 KB eingelesen werden. Die Schleife kannst du aber auch rausnehmen, dann werden nur 8 KB eingelesen.
Der Client/Server kann währenddessen ruhig weitersenden, kein Byte an Daten geht verloren.
> Übrigens: Wenn beim TCP/IP Protokoll ein paket nicht ankommt, muss es
> ja nochmal gesendet werden. Muss ich dann die Daten selbst neu senden,
> oder übernimmt das PureBasic, Windows oder wer-auch-immer?
Das übernimmt das TCP/IP-Protokoll. Du musst da nix tun.
Du hast nur anzugeben, welche Daten gesendet werden sollen, TCP übernimmt das eigendliche Senden, korrigiert Sendefehler automatisch, etc.
Now these points of data make a beautiful line.
And we're out of beta. We're releasing on time.
And we're out of beta. We're releasing on time.
Das übernimmt das TCP/IP-Protokoll. Du musst da nix tun.
Du hast nur anzugeben, welche Daten gesendet werden sollen, TCP übernimmt das eigendliche Senden, korrigiert Sendefehler automatisch, etc.
Geil... Jetzt weiß ich das TCP/IP Protokoll noch mehr als vorher zu schätzen...
Du hast nur anzugeben, welche Daten gesendet werden sollen, TCP übernimmt das eigendliche Senden, korrigiert Sendefehler automatisch, etc.
Geil... Jetzt weiß ich das TCP/IP Protokoll noch mehr als vorher zu schätzen...
PB 4.30
Code: Alles auswählen
Macro Happy
;-)
EndMacro
Happy End