Internet-Performence

Übersicht

BlitzBasic

Allgemein

	Smokie Betreff: Internet-Performence	Mo, Jul 03, 2006 20:26 Antworten mit Zitat
Hallo, ich wollte gerne wissen, ob man wenn man bei einem Spiel ,das viele Daten verschickt/empfängt, die Daten schneller versenden kann, wenn man den Netcode in C++ o.a. schreibt, als wenn man ihn in BB schreibt. Ich meine hat man in C++ mehr Möglichkeiten die übertragungszeit zu beeinflussen als in BB. Also ich meine es ist ja in BB so Code: [AUSKLAPPEN] [EINKLAPPEN] Stream=createudpstream(port) Writebyte Stream,485 Sendudpmsg Stream,ip,port Da kann man net viel verändern außer, dass man die Daten sparsam verschickt. Wie sieht das in C++ aus? Kann man da noch mehr rausholen als mit BB? Danke für die Mühe sich den Text durchzulesen und danke für jede Antwort Grüße Smokie
M-Soft Studios Mit selbst gemachtem Forum!!! Unbequem lebt's sich schwer. Musik macht erst Spaß, wenn man sie mit 2,8 facher Geschwindigkeit hört Zuletzt bearbeitet von Smokie am Fr Jan 01, 1888 51:58 PM, insgesamt 1000-mal bearbeitet

Smokie

Betreff: Internet-Performence

Mo, Jul 03, 2006 20:26
Antworten mit Zitat

Hallo,

ich wollte gerne wissen, ob man wenn man bei einem Spiel ,das viele Daten verschickt/empfängt, die Daten schneller versenden kann, wenn man den Netcode in C++ o.a. schreibt, als wenn man ihn in BB schreibt. Ich meine hat man in C++ mehr Möglichkeiten die übertragungszeit zu beeinflussen als in BB. Also ich meine es ist ja in BB so

Code: [AUSKLAPPEN]

Stream=createudpstream(port)
Writebyte Stream,485
Sendudpmsg Stream,ip,port

Da kann man net viel verändern außer, dass man die Daten sparsam verschickt.

Wie sieht das in C++ aus? Kann man da noch mehr rausholen als mit BB?

Danke für die Mühe sich den Text durchzulesen und danke für jede Antwort

Grüße
Smokie

M-Soft Studios Mit selbst gemachtem Forum!!!
Unbequem lebt's sich schwer.
Musik macht erst Spaß, wenn man sie mit 2,8 facher Geschwindigkeit hört
Zuletzt bearbeitet von Smokie am Fr Jan 01, 1888 51:58 PM, insgesamt 1000-mal bearbeitet

	BIG BUG	Mo, Jul 03, 2006 22:43 Antworten mit Zitat
Naja, bei TCP kann man schon mehr machen, bei UDP machts vermutlich keinen Unterschied...
B3D-Exporter für Cinema4D!(V1.4) MD2-Exporter für Cinema4D!(final)

BIG BUG

Mo, Jul 03, 2006 22:43
Antworten mit Zitat

Naja, bei TCP kann man schon mehr machen, bei UDP machts vermutlich keinen Unterschied...

B3D-Exporter für Cinema4D!(V1.4)
MD2-Exporter für Cinema4D!(final)

	Dreamora	Di, Jul 04, 2006 8:24 Antworten mit Zitat
Nein mehr rausholen kannst du nicht. Den einzigen Vorteil den C++ oder "richtige" Sprachen mit sich bringen ist Multithreading. Sprich das Programm muss die Abfrage des Datenstroms nicht so machen, dass der Rest des Programmes warten muss ...
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Di, Jul 04, 2006 8:24
Antworten mit Zitat

Nein mehr rausholen kannst du nicht.
Den einzigen Vorteil den C++ oder "richtige" Sprachen mit sich bringen ist Multithreading. Sprich das Programm muss die Abfrage des Datenstroms nicht so machen, dass der Rest des Programmes warten muss ...

Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

	Markus2	Di, Jul 04, 2006 12:13 Antworten mit Zitat
TCP ist langsam , UDP ist ganz gut und du solltest nur Daten die sich verändert haben schicken was ist BB eigentlich schnell genug geht .

Markus2

Di, Jul 04, 2006 12:13
Antworten mit Zitat

TCP ist langsam , UDP ist ganz gut und du solltest nur Daten die
sich verändert haben schicken was ist BB eigentlich schnell genug geht .

	Nox	Sa, Jul 08, 2006 1:49 Antworten mit Zitat
TCP ist keineswegs langsam! Es hat keinen Einfluss auf die Geschwindigkeit, welches Protokoll du nutzt. TCP hat nur bei Spielen den Nachteil, dass es einen ziemlich Overhead an Daten sendet. D.h. viele Daten müssen in kürzester Zeit zugestellt werden, um angenehme Pings zu erreichen. Allerdings flitzen die TCP-Pakete genauso schnell über die Leitung wie UDP-Pakete. Nur da mehr Daten zu übermitteln sind, dauert's logischerweise länger als bei UDP-Paketen, sofern die selbe Menge an Nutzdaten vorhanden ist. Welches Protokoll man verwendet, hängt ganz vom Einsatzgebiet ab. Ich halte nen Mix von beiden Protokollen für sehr gut. Dinge, bei denen ein Paketverlust nicht gravierend wäre ((viele) Positionsupdates vom Client zum Server) übermittle ich mit UDP. Allerdings verlasse ich mich bei Daten, die sicher ankommen müssen doch lieber auf TCP, denn dieses bringt ein Errorchecking direkt mit. Würde ich da UDP einsetzen, wäre der Unterschied auch nicht wirklich groß, denn dann müsste ich selbst für das richtige Empfangen der Pakete sorgen, was wiederrum Datenmenge kostet...

Nox

Sa, Jul 08, 2006 1:49
Antworten mit Zitat

TCP ist keineswegs langsam! Es hat keinen Einfluss auf die Geschwindigkeit, welches Protokoll du nutzt. TCP hat nur bei Spielen den Nachteil, dass es einen ziemlich Overhead an Daten sendet. D.h. viele Daten müssen in kürzester Zeit zugestellt werden, um angenehme Pings zu erreichen. Allerdings flitzen die TCP-Pakete genauso schnell über die Leitung wie UDP-Pakete. Nur da mehr Daten zu übermitteln sind, dauert's logischerweise länger als bei UDP-Paketen, sofern die selbe Menge an Nutzdaten vorhanden ist.

Welches Protokoll man verwendet, hängt ganz vom Einsatzgebiet ab. Ich halte nen Mix von beiden Protokollen für sehr gut. Dinge, bei denen ein Paketverlust nicht gravierend wäre ((viele) Positionsupdates vom Client zum Server) übermittle ich mit UDP. Allerdings verlasse ich mich bei Daten, die sicher ankommen müssen doch lieber auf TCP, denn dieses bringt ein Errorchecking direkt mit. Würde ich da UDP einsetzen, wäre der Unterschied auch nicht wirklich groß, denn dann müsste ich selbst für das richtige Empfangen der Pakete sorgen, was wiederrum Datenmenge kostet...

	SoNenTyp	Sa, Jul 08, 2006 3:05 Antworten mit Zitat
Ich empfehle wenn möglich nur TCP zu verwenden. Der vorteil ist bei defekten oder nicht ankokmenden Paketen, wird das automatisch berichtigt und garantiert schneller als es mit BB gehen würde. Zu dem hat man noch den vorteil das man durch eine Firewall hindurch senden kann, zumindest wenn der, hinter der Firewall, die Verbindung erstellt hat.
Gruss Der Typ. User posted image

SoNenTyp

Sa, Jul 08, 2006 3:05
Antworten mit Zitat

Ich empfehle wenn möglich nur TCP zu verwenden. Der vorteil ist bei defekten oder nicht ankokmenden Paketen, wird das automatisch berichtigt und garantiert schneller als es mit BB gehen würde. Zu dem hat man noch den vorteil das man durch eine Firewall hindurch senden kann, zumindest wenn der, hinter der Firewall, die Verbindung erstellt hat.

Gruss Der Typ.

User posted image

	Dreamora	Sa, Jul 08, 2006 9:02 Antworten mit Zitat
Nox hat Folgendes geschrieben: TCP ist keineswegs langsam! Es hat keinen Einfluss auf die Geschwindigkeit, welches Protokoll du nutzt. TCP hat nur bei Spielen den Nachteil, dass es einen ziemlich Overhead an Daten sendet. D.h. viele Daten müssen in kürzester Zeit zugestellt werden, um angenehme Pings zu erreichen. Allerdings flitzen die TCP-Pakete genauso schnell über die Leitung wie UDP-Pakete. Nur da mehr Daten zu übermitteln sind, dauert's logischerweise länger als bei UDP-Paketen, sofern die selbe Menge an Nutzdaten vorhanden ist. Es dauert aus einem anderen Grund länger. Das hat relativ wenig mit overhead zu tun. Und zwar hat TCP die Eigenschaft, dass Daten in der Reihenfolge ankommen, in der sie versandt werden. Klingt eigentlich gut. Doch was, wenn Mal ein Paket verloren geht? Genau, es wird nochmal gesandt. Klingt auch gut. Dummerweise müssen aber alle anderen, nachfolgenden Pakete solange warten, bis dieses eine Paket auch sauber angekommen ist, bevor sie versandt werden können. UDP macht das nicht, deswegen erscheint es schneller. Wenn man UDP auch die ganzen Dinge einbaut ist es nur noch bedingt schneller (deswegen baut man sie häufig so ein, dass man die Eigenschaften selektiv nutzen kann, zb wichtiges muss ankommen und in der richtigen reihenfolge, bei positionsupdates ist es egal, etc)
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Sa, Jul 08, 2006 9:02
Antworten mit Zitat

Nox hat Folgendes geschrieben:

Es dauert aus einem anderen Grund länger. Das hat relativ wenig mit overhead zu tun. Und zwar hat TCP die Eigenschaft, dass Daten in der Reihenfolge ankommen, in der sie versandt werden. Klingt eigentlich gut. Doch was, wenn Mal ein Paket verloren geht? Genau, es wird nochmal gesandt. Klingt auch gut. Dummerweise müssen aber alle anderen, nachfolgenden Pakete solange warten, bis dieses eine Paket auch sauber angekommen ist, bevor sie versandt werden können.

UDP macht das nicht, deswegen erscheint es schneller.
Wenn man UDP auch die ganzen Dinge einbaut ist es nur noch bedingt schneller (deswegen baut man sie häufig so ein, dass man die Eigenschaften selektiv nutzen kann, zb wichtiges muss ankommen und in der richtigen reihenfolge, bei positionsupdates ist es egal, etc)

Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

	Plasma Betreff: noch ne frage	Sa, Jul 08, 2006 12:12 Antworten mit Zitat
wenn ich tcp ip mit blitz (writeline) verwende , kann ich einfluss auf die den speed nehmen indem ich den zu versendenden string auf die paketgrösse setze ? und wenn ja wie gross sollte er dann sein .

Plasma

Betreff: noch ne frage

Sa, Jul 08, 2006 12:12
Antworten mit Zitat

wenn ich tcp ip mit blitz (writeline) verwende , kann ich einfluss auf die den
speed nehmen indem ich den zu versendenden string auf die paketgrösse setze ?
und wenn ja wie gross sollte er dann sein .

	Nox	So, Jul 09, 2006 13:54 Antworten mit Zitat
@plasma2: Das hast du richtig erkannt, also das Senden von möglichst vielen Daten in einem Paket. Zerstreust du Daten auf mehrere Pakete, die womöglich nicht alle sauber eintreffen und ggf. neu angefordert werden müssen, resultiert das in einer niedrigeren Geschwindigkeit. Falls du allerdings gemeint hast, jeden String auf die max. Paketgröße zu verlängern, ist das nicht sinnvoll. Denn dann versendest du mehr Daten als notwendig. Festgelegt ist für TCP eine Nutzdatenlänge von max. 1460 Bytes (siehe Wikipedia "TCP" für genauere Erklärungen). Generell verwendet man aber gerne einfach 1024 Byte-Frames, was IMHO auch ausreichen sollte. @Dreamora: Völlig korrekt. Blöd dass ich das öhm "vergessen" habe. Aber das ist ja auch der riesen Vorteil von TCP, wie du gesagt hast. Bei UDP würden genau solche Pakete in willkürlicher Reihenfolge eintreffen und man müsste selbst Sorge tragen, sie in die richtige Reihenfolge zu bringen (über fortlaufende Message-Nummern oder wie auch immer). Allerdings ist der Verkehr von TCP und UDP ja derselbe. IP kann sich für seine Pakete willkürliche Routen suchen (was es egtl auch tut). Deshalb finde ich, dass man für sensible Daten der Einfachheit halber TCP verwenden sollte und sich somit den ganzen Prüfungskram mit UDP schenken kann.

Nox

So, Jul 09, 2006 13:54
Antworten mit Zitat

@plasma2:
Das hast du richtig erkannt, also das Senden von möglichst vielen Daten in einem Paket. Zerstreust du Daten auf mehrere Pakete, die womöglich nicht alle sauber eintreffen und ggf. neu angefordert werden müssen, resultiert das in einer niedrigeren Geschwindigkeit. Falls du allerdings gemeint hast, jeden String auf die max. Paketgröße zu verlängern, ist das nicht sinnvoll. Denn dann versendest du mehr Daten als notwendig.
Festgelegt ist für TCP eine Nutzdatenlänge von max. 1460 Bytes (siehe Wikipedia "TCP" für genauere Erklärungen). Generell verwendet man aber gerne einfach 1024 Byte-Frames, was IMHO auch ausreichen sollte.

@Dreamora:
Völlig korrekt. Blöd dass ich das öhm "vergessen" habe. Wink

Aber das ist ja auch der riesen Vorteil von TCP, wie du gesagt hast. Bei UDP würden genau solche Pakete in willkürlicher Reihenfolge eintreffen und man müsste selbst Sorge tragen, sie in die richtige Reihenfolge zu bringen (über fortlaufende Message-Nummern oder wie auch immer). Allerdings ist der Verkehr von TCP und UDP ja derselbe. IP kann sich für seine Pakete willkürliche Routen suchen (was es egtl auch tut). Deshalb finde ich, dass man für sensible Daten der Einfachheit halber TCP verwenden sollte und sich somit den ganzen Prüfungskram mit UDP schenken kann.

	BIG BUG	So, Jul 09, 2006 23:18 Antworten mit Zitat
Das Problem in BlitzBasic mit TCP ist, dass die komplette Anwendung stehen bleibt, wenn ein Paket noch nicht angekommen ist. Bei rundenbasierten Sachen oder einer guten Verbindung mag das nicht weiter stören, ansonsten kann das aber schon eklig werden. Generell gibt es bei TCP noch eine non-blocking-Einstellung die genau dieses Warten verhindert, mit BB kannst Du diese aber eben nicht setzen.
B3D-Exporter für Cinema4D!(V1.4) MD2-Exporter für Cinema4D!(final)

BIG BUG

So, Jul 09, 2006 23:18
Antworten mit Zitat

Das Problem in BlitzBasic mit TCP ist, dass die komplette Anwendung stehen bleibt, wenn ein Paket noch nicht angekommen ist. Bei rundenbasierten Sachen oder einer guten Verbindung mag das nicht weiter stören, ansonsten kann das aber schon eklig werden.

Generell gibt es bei TCP noch eine non-blocking-Einstellung die genau dieses Warten verhindert, mit BB kannst Du diese aber eben nicht setzen.

B3D-Exporter für Cinema4D!(V1.4)
MD2-Exporter für Cinema4D!(final)

	Markus2	Mo, Jul 10, 2006 0:00 Antworten mit Zitat
BB und UDP geht super

Markus2

Mo, Jul 10, 2006 0:00
Antworten mit Zitat

BB und UDP geht super

	StepTiger	Mo, Jul 10, 2006 0:03 Antworten mit Zitat
BIG BUG hat Folgendes geschrieben: Das Problem in BlitzBasic mit TCP ist, dass die komplette Anwendung stehen bleibt, wenn ein Paket noch nicht angekommen ist. Bei rundenbasierten Sachen oder einer guten Verbindung mag das nicht weiter stören, ansonsten kann das aber schon eklig werden. Generell gibt es bei TCP noch eine non-blocking-Einstellung die genau dieses Warten verhindert, mit BB kannst Du diese aber eben nicht setzen. Also ich hab da noch nie ne Wartezeit gemerkt! Wenn man mit "If readavail(thehandle) then da$=Readline(thehandle)" prüft, wartet da doch nix
Noch gestern standen wir am Abgrund, doch heute sind wir schon einen Schritt weiter. Computer: AMD Sempron 3000+; ATI Radeon 9800 Pro; 512 MB DDR RAM 400Mhz; Asus E7N8X-E Deluxe; Samsung 200GB HD 5.4ns acces t Gewinner: BP Code Compo #2 Π=3.141592653589793238...<--- und das aus dem kopf Seit der Earthlings-Diskussion überzeugter Fleisch(fr)esser.

StepTiger

Mo, Jul 10, 2006 0:03
Antworten mit Zitat

BIG BUG hat Folgendes geschrieben:

Also ich hab da noch nie ne Wartezeit gemerkt!

Wenn man mit "If readavail(thehandle) then da$=Readline(thehandle)" prüft, wartet da doch nix

Noch gestern standen wir am Abgrund, doch heute sind wir schon einen Schritt weiter.
Computer:
AMD Sempron 3000+; ATI Radeon 9800 Pro; 512 MB DDR RAM 400Mhz; Asus E7N8X-E Deluxe; Samsung 200GB HD 5.4ns acces t
Gewinner: BP Code Compo #2
Π=3.141592653589793238...<--- und das aus dem kopf Laughing

Seit der Earthlings-Diskussion überzeugter Fleisch(fr)esser.

	Nox	Mo, Jul 10, 2006 1:03 Antworten mit Zitat
Bin da nicht genau genug involviert, aber gibt's nicht genau dafür eine Multithreading-Bibliothek, die sich über BB einbinden lässt und eventbasierend läuft?

Nox

Mo, Jul 10, 2006 1:03
Antworten mit Zitat

Bin da nicht genau genug involviert, aber gibt's nicht genau dafür eine Multithreading-Bibliothek, die sich über BB einbinden lässt und eventbasierend läuft?