TCP so langsam?

Übersicht

BlitzBasic

Allgemein

	kreisman Betreff: TCP so langsam?	Mi, Jun 07, 2006 23:02 Antworten mit Zitat
Ich bastle im moment an den Multiplayerteil für mein rundenstrategiespiel und hab mich der sicherheit halber für tcp entschieden.Allerdings hab ich ab und zu Lag.Dann hab ich mal gemessen wie lang der server braucht um ein Packet zu empfangen.Das dauerte so zwischen 150 und 250 Millisekunden.Das kommt mir ein bischen lang vor. Meine Frage mach ich etwas falsch bei tcp? Muss auf etwas wichtiges achten?Oder ist das einfach nur so langsam? Achso ich benutze nur WriteLine um auf den Stream zu schreiben.Hat mir schon nen ordentlichen Geschwindigkeits-Schub gegeben. Edit: sry das ich hier nen neuen Thread aufgemacht hab -.- .Ich hab ne neue Idee durch die Forumssuche bekommen.Den Writebytes Befehl.Ich hoff mal der hilft.

kreisman

Betreff: TCP so langsam?

Mi, Jun 07, 2006 23:02
Antworten mit Zitat

Ich bastle im moment an den Multiplayerteil für mein rundenstrategiespiel und hab mich der sicherheit halber für tcp entschieden.Allerdings hab ich ab und zu Lag.Dann hab ich mal gemessen wie lang der server braucht um ein Packet zu empfangen.Das dauerte so zwischen 150 und 250 Millisekunden.Das kommt mir ein bischen lang vor. Meine Frage mach ich etwas falsch bei tcp? Muss auf etwas wichtiges achten?Oder ist das einfach nur so langsam?

Achso ich benutze nur WriteLine um auf den Stream zu schreiben.Hat mir schon nen ordentlichen Geschwindigkeits-Schub gegeben.

Edit: sry das ich hier nen neuen Thread aufgemacht hab -.- .Ich hab ne neue Idee durch die Forumssuche bekommen.Den Writebytes Befehl.Ich hoff mal der hilft.

	Jan_ Ehemaliger Admin	Do, Jun 08, 2006 8:40 Antworten mit Zitat
was für nen server hast du? beachte bitte, das TCP doppelt-dreimal so lange bracuht wie udp und ein Ping von 150 ist ja net so schlimm. falls es hin und zurück ist, gehts noch. mann sollte immer die max. Größe des Packets ausnutzen, und dafür weniger senden. ...
between angels and insects

Jan_

Ehemaliger Admin

Do, Jun 08, 2006 8:40
Antworten mit Zitat

was für nen server hast du?

beachte bitte, das TCP doppelt-dreimal so lange bracuht wie udp
und ein Ping von 150 ist ja net so schlimm.
falls es hin und zurück ist, gehts noch.
mann sollte immer die max. Größe des Packets ausnutzen, und dafür weniger senden.

...

between angels and insects

	stfighter01	Do, Jun 08, 2006 14:45 Antworten mit Zitat
tcp ist so langsam weil es ein zuverlässiges protocoll ist. alle daten die abgeschickt wurden kommen auch (in richtiger reihenfolge!) beim empfänger an. das bedingt aber auch rückfragen ob die daten angekommen sind bzw. neusenden der daten. das benötigt natürlich zeit verlorene daten müssen erst erkannt und wieder gesendet werden -> lag im spiel. bei udp wird diese überprüfung nicht durchgeführt. udp kann trotzdem nützlich sein. positionsdaten werden z.b.: regelmässig geupdated. daher ist es egal ob zwischendurch ein paket verlorengeht od. nicht - wichtig ist das möglichst viele pakete in möglichst kurzer zeit ankommen um ein schnellstmöglichstes updaten zu gewährleisten.
Denken hilft!

stfighter01

Do, Jun 08, 2006 14:45
Antworten mit Zitat

tcp ist so langsam weil es ein zuverlässiges protocoll ist.
alle daten die abgeschickt wurden kommen auch (in richtiger reihenfolge!) beim empfänger an.
das bedingt aber auch rückfragen ob die daten angekommen sind bzw. neusenden der daten.
das benötigt natürlich zeit
verlorene daten müssen erst erkannt und wieder gesendet werden ->
lag im spiel.

bei udp wird diese überprüfung nicht durchgeführt.
udp kann trotzdem nützlich sein.
positionsdaten werden z.b.: regelmässig geupdated.
daher ist es egal ob zwischendurch ein paket verlorengeht od. nicht -
wichtig ist das möglichst viele pakete in möglichst kurzer zeit ankommen um ein schnellstmöglichstes updaten zu gewährleisten.

Denken hilft!

	kreisman	Do, Jun 08, 2006 14:58 Antworten mit Zitat
Jan_ hat Folgendes geschrieben: mann sollte immer die max. Größe des Packets ausnutzen, und dafür weniger senden. Was war nochmal die maximale Größe 8Kb oder? EDIT: Problem gelößt!!! Hab jetzt das ganze auf Banks umgestellt,benutzte nun den WriteBytes-Befehl und komme auf Übertragungszeit von 30 - 50 Millisekunden!!!!

kreisman

Do, Jun 08, 2006 14:58
Antworten mit Zitat

Jan_ hat Folgendes geschrieben:

mann sollte immer die max. Größe des Packets ausnutzen, und dafür weniger senden.

Was war nochmal die maximale Größe 8Kb oder?

EDIT: Problem gelößt!!!

Hab jetzt das ganze auf Banks umgestellt,benutzte nun den WriteBytes-Befehl und komme auf Übertragungszeit von 30 - 50 Millisekunden!!!!

	Hummelpups	Do, Jun 08, 2006 22:22 Antworten mit Zitat
stfighter01 hat Folgendes geschrieben: tcp ist so langsam weil es ein zuverlässiges protocoll ist. alle daten die abgeschickt wurden kommen auch (in richtiger reihenfolge!) beim empfänger an. Naja, kommt drauf an von welcher schicht des OSI modells du es aus betrachtest, auch fragmentierte TCP Pakete können andere Routen benutzen. (Schicht 3) Sie werden jedoch wieder in richtiger Reihenfolge zusammengesetzt und solange das erste Paket felht, wird eine bestimmte Zeit gewartet. Kommt in dieser Zeit nicht das fehlende Fragment, wird es neu bestellt. Kommt das Paket an, ist es auch wieder "in der richtigen reihenfolge" und wird an schicht 4 bzw. 5 weiter gegeben. Eine verwandte Methode davon ist das "Sliding Window" was nach dem "3 Way Handshake" benutzt wird. Naja, nur um das klar zu stellen ;D IMurDOOM
blucode - webdesign - Ressource - NetzwerkSim BlitzBasic 2D - BlitzMax - MaxGUI - Monkey - BlitzPlus

Hummelpups

Do, Jun 08, 2006 22:22
Antworten mit Zitat

stfighter01 hat Folgendes geschrieben:

tcp ist so langsam weil es ein zuverlässiges protocoll ist.
alle daten die abgeschickt wurden kommen auch (in richtiger reihenfolge!) beim empfänger an.

Naja, kommt drauf an von welcher schicht des OSI modells du es aus
betrachtest, auch fragmentierte TCP Pakete können andere Routen benutzen.
(Schicht 3)
Sie werden jedoch wieder in richtiger Reihenfolge zusammengesetzt und
solange das erste Paket felht, wird eine bestimmte Zeit gewartet.
Kommt in dieser Zeit nicht das fehlende Fragment, wird es neu bestellt.
Kommt das Paket an, ist es auch wieder "in der richtigen reihenfolge"
und wird an schicht 4 bzw. 5 weiter gegeben.

Eine verwandte Methode davon ist das "Sliding Window" was nach dem
"3 Way Handshake" benutzt wird.

Naja, nur um das klar zu stellen ;D

IMurDOOM

blucode - webdesign - Ressource - NetzwerkSim
BlitzBasic 2D - BlitzMax - MaxGUI - Monkey - BlitzPlus

	stfighter01	Fr, Jun 09, 2006 13:53 Antworten mit Zitat
IMurDOOM hat Folgendes geschrieben: Sie werden jedoch wieder in richtiger Reihenfolge zusammengesetzt und solange das erste Paket felht, wird eine bestimmte Zeit gewartet. Kommt in dieser Zeit nicht das fehlende Fragment, wird es neu bestellt. IMurDOOM wobei wir wieder bei meiner (zugegebenermassen diletantischen) definition von tcp wären und tcp ist nur von der 4 ten schicht aus zu sehen. in der 3ten schicht liegt das ip protokoll.
Denken hilft!

stfighter01

Fr, Jun 09, 2006 13:53
Antworten mit Zitat

IMurDOOM hat Folgendes geschrieben:

Sie werden jedoch wieder in richtiger Reihenfolge zusammengesetzt und
solange das erste Paket felht, wird eine bestimmte Zeit gewartet.
Kommt in dieser Zeit nicht das fehlende Fragment, wird es neu bestellt.
IMurDOOM

wobei wir wieder bei meiner (zugegebenermassen diletantischen) definition von tcp wären Wink