Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

struct und socket

Werbeanzeige

Anonymous

unregistriert

11

04.04.2009, 12:55

sende lieber binär, mit XML rangehen ist ungefähr so als ob du eine nuklearrakete auf ne ameise abfeuerst und ich denke für deinen fall mehr lam als nutzvoll.

xardias

Community-Fossil

Beiträge: 2 731

Wohnort: Santa Clara, CA

Beruf: Software Engineer

  • Private Nachricht senden

12

04.04.2009, 12:56

Google hat eine sehr schöne Bibliothek zur effizienten und einfachen Serialisierung von Daten veröffentlicht. (Opensource)
http://code.google.com/p/protobuf/
Das ist wesentlich flotter und vor allem platzsparender als die meisten XML Serialisierungsvarianten (Und meiner Meinung nach sogar einfacher zu verwenden)

Damit kann man sich auf jeden Fall sehr schnell ein einfaches Protokoll basteln.

VuuRWerK

Frischling

Beiträge: 59

Wohnort: Dresden

Beruf: Softwareentwickler

  • Private Nachricht senden

13

04.04.2009, 13:00

Na ganz einfach. Überlege Dir einen XML-Aufbau, bsp:

Quellcode

 
1
2
3
4
5

<data time="...unix timestamp...">
    <opponent health="25" health-type="int" ... usw. />
    <... weitere eigenschaften />
    <message>vllt noch bissel Text</message>
</data>


Das versendest Du wohin auch immer und liest es auf der jeweiligen Gegenseite wieder aus. Zum auslesen kannst Du eine freie XML-Lib verwenden: Xerces, etc.

@ulong: Das macht zur heutiegn Zeit gar nix mehr aus ;)

Gut Schuß
VuuRWerK ;)

Steven77

Alter Hase

Beiträge: 515

Wohnort: Münster - Gievenbeach

Beruf: Wissenschaftlicher Mitarbeiter

  • Private Nachricht senden

14

04.04.2009, 13:02

In deinem Fall XML zu verwenden wäre Quatsch. In irgendeiner Art konvertieren wirst du deine Daten ja schon müssen, insofern kannst du auch bei einem Binärformat bleiben (im Gegensatz zu einem textbasierten Format wie XML, was in größeren Datenmengen resultieren würde).

Vielleicht baust du dir eine Handvoll Funktionen, die verschiedene primitive und auch komplexe Datentypen serialisieren und in einen "binären Stream" schieben. Dann musst du entsprechenden Funktionen nur in der richtigen Reihenfolge aufrufen, z.B. für eine Instanz deiner Gegner-Klasse:

C-/C++-Quelltext

 
1
2
3

bytes += serialize( gegner.name, stream );
bytes += serialize( gegner.xpos, stream );
bytes += serialize( gegner.ypos, stream );


Worauf du zusätzlich achten könntest, ist, nicht immer alle Daten eines Objekts rüberzusenden, sondern nur die jeweils relevanten. Der Name wird sich ja wahrscheinlich im Laufe der Zeit nicht ändern, insofern wäre es sinnlos, den jedes Mal mitzusenden.
Kommen Sie nie mit einem Schwert zu einer Schießerei.

Anonymous

unregistriert

15

04.04.2009, 13:09

VuuRWerK
Das macht verdammt viel aus, gerade im Netzwerk wo es um Performance geht und dass geringe Fehleranfälligkeit benötigt wird.

In Binärdaten die nur 32 Byte groß sind kann sich weniger ein Übertragungsfehler einschleichen als bei einem String der Binär übertragen wird und über 512 Byte groß ist. Soviel dazu.

Dann das ganze Parsen und Erstellen von XML dauert enorm lange. Wenn man Datenbank-Backups damit mal gemacht hat, der kennt das "Drama". Im Netzwerk summiert sich das aber genau so gut.

Überlegen wir mal: ~20-60 Pakete müssen pro User in der Sekunde über das Netzwerk gesendet werden. Was ist wohl schneller bei einer summierung? 32 Byte oder 512 Byte XML? Denke eheres und bei einer Stunde Netzwerk kommt da schon ein gigantisches Sümmchen zusammen. Der arme Server der 32 Clients verarbeitet müss ja schon allein durch das Parsen regelrecht brennen und von Traffic möchte ich nicht mal reden.

Du musst hier mal die Langzeitfolgen betrachten.

Für dich müssen die Daten nicht in XML leserlich sein, die haben dich nicht zu interessieren. Binär ist hier einfacher, schneller implementierbarer, schneller in der übertragung, weniger fehleranfällig, traffic-sparender, performance sparender, usw.

xardias

Community-Fossil

Beiträge: 2 731

Wohnort: Santa Clara, CA

Beruf: Software Engineer

  • Private Nachricht senden

16

04.04.2009, 13:23

Aus genau den Gründen würde ich auch zu Google Protocol Buffers (siehe oben) raten, falls dir das selbst serialisieren zu viel Arbeit ist.
(Das erspart dir ein paar Probleme wie Endianness, unterschiedliche Datentypgrößen auf unterschiedlichen Plattformen, Serialisieren von Listen, strings, etc).

Wenn man das ganze unbedingt selbst lesen möchte kann man sich ein Wireshark Plugin dafür installieren, das dekodiert die Protocol Buffers Daten in ein menschlich lesbares Format.

VuuRWerK

Frischling

Beiträge: 59

Wohnort: Dresden

Beruf: Softwareentwickler

  • Private Nachricht senden

17

04.04.2009, 13:40

In einem früheren Post habe ich mehrere Sachen vorgeschlagen wie man etwas transportieren kann, u.a. auch binär. Da aber der Threadersteller nach XML gefragt hat hab ich es natürlich auch erklärt wie ich es meine. Ich weiß doch nicht wieviel er versenden möchte bzw. ob es vllt. noch erweitert werden muss etc. Ich habe vorgeschlagen und auf Fragen geantwortet mehr nicht. Ich habe lediglich erwähnt das ich XML bevorzuge.

Zudem ist das Parsen von XML bestimmt kein Akt mehr. Da muss sich keine CPU mehr groß anstrengen.

@ulong: Das binär "sicherer" sei wage ich zu bezweifeln, einmal ein Übertragungsfehler in form eines falschen bits und schon ist das komplette Paket hinüber. An der Stelle würde ich noch eine art Prüfsumme vorschlagen, denke da sollte CRC8 voll ausreichen.

Gut Schuß
VuuRWerK ;)

P.S.: Zudem sollte man sich vllt. ja doch mal das Google Protocol Buffers anschauen, klingt sehr interessant.

Anonymous

unregistriert

18

04.04.2009, 13:43

Du musst die Summen bedenken die sich da anhäufen und XML Parsen ist sehr Zeitaufwändig. Und wenn man noch UDP benutzt, wo das Protokoll keine Fehlerprüfung betreibt sind das Dimensionen jenseits von Gut und Böse. Da benutzt man sicherlich kein XML mehr.

n0_0ne

1x Contest-Sieger

Beiträge: 678

  • Private Nachricht senden

19

04.04.2009, 13:49

Jo, binär ist wohl sicherer, einfach weil es weniger Daten sind, die übertragen werden müssen, und somit auch weniger Fehler auftreten können. Was einzelne falsche Bits etc angeht, so werden die ja (wenn er es mit TCP verschickt) in beiden Fällen erkannt. Möglicherweise sind die XML Bibliotheken bei kleinen Fehlern sogar in der Lage aufgrund des großen Overheads Fehler zu korrigieren, aber 1. Treten Fehler bei sowas wirklich nur sehr selten auf, was diesen riesen Overhead nicht rechtfertigt und 2. treten dann immer sehr viele Fehler auf einmal auf, was denke ich auch im XML kontext nicht mehr korrigiert werden kann... Was das parsen von XML angeht, denke ich auch, dass das wohl noch das geringste Problem bei der Sache ist. :D

VuuRWerK

Frischling

Beiträge: 59

Wohnort: Dresden

Beruf: Softwareentwickler

  • Private Nachricht senden

20

04.04.2009, 13:57

@ulong: Ich weiß ja nicht was für XML-Libs Du benutzt aber meine Erfahrungen sind das XML parsern verschwindent gering im Zeitaufwand sind. Eine ~20MB XML-Datei war so innerhalb weniger ms geparsed und in einen AST aufgebaut, ein einfacher AST also nicht vergleichbar mit DOM aber es war geparsed.
Ich weiß ja was Du meinst und wie gesagt hab ich nicht gesagt er soll XML nehmen ich habs nur vorgeschlagen da es gängig ist wenn es um das kommunizieren im Netzwerk geht. Bei Zeitkritischen spielen wird denke ich generell binär und dann auch nur das nötigste übertragen weil es, wie Du schon sagtest, natürlich die schnellere Variante ist.

Also jetzt mal weg vom XML, hin zur binären Version damit ist allen geholfen ;)
Aber auch da würde ich boost::serialization vorschlagen, hat man sogar noch die Wahl wie man es am Ende kodiert :)
Oder, wie auch schon vorher vorgeschlagen: Google Protocol Buffers

Gut Schuß
VuuRWerK ;)

Werbeanzeige