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!
Werbeanzeige
Für die Byte Reihenfolge gibt es sowas wie
htonl [] (3) - convert values between host and network byte order
htons [] (3) - convert values between host and network byte order
ntohl [] (3) - convert values between host and network byte order
ntohs [] (3) - convert values between host and network byte order
Das wird aber nicht automatisch von SDL_net gemacht werden können, Da dazu ja ein Wissen um die Interpretation des Inhalt existieren müsste. Das hat SDL_net aber nicht,
Wenn man nur ein relativ einfaches Event transportieren will, dann reicht vielleicht in weiten Bereichen tatsächlich sizeof() und memcpy().
simbad
unregistriert
Für die Byte Reihenfolge gibt es sowas wie
htonl [] (3) - convert values between host and network byte order
htons [] (3) - convert values between host and network byte order
ntohl [] (3) - convert values between host and network byte order
ntohs [] (3) - convert values between host and network byte order
Das wird aber nicht automatisch von SDL_net gemacht werden können, Da dazu ja ein Wissen um die Interpretation des Inhalt existieren müsste. Das hat SDL_net aber nicht,
Naja, ich dachte eher an endianness, oder verdreh ich da was?
Zitat
Wenn man nur ein relativ einfaches Event transportieren will, dann reicht vielleicht in weiten Bereichen tatsächlich sizeof() und memcpy().
Ich überlege gerade folgendes: ich verwende ja diese Kopierkonstruktor-ähnlichen Gebilde, die nur einen Pointer statt einer const Reference bekommen. Kann ich die Implementierung des Kopierkonstrukturs (im meinem Fall von Primitivdatentypen) mit sizeof() und memcpy() vermeiden?
Also:
- Event-ID mit switch überprüfen
- im entsprechenden Case ein neues, leeres Objekt des Typs erstellen.
- und mit memcpy(new_event, old_event, sizeof(MyEventType)) dann einfach kopieren?
Oder bekomme ich da an irgendeiner Stelle Probleme (z.B. bei []-Arrays) ?
LG Glocke
Der Compiler erzeugt normalerweise automatisch entsprechende Copy-Constructors. Die sind für die Basistypen alle vorhanden. Für Arrays der Basistypen sollte das auch gelten.
simbad
unregistriert
Host und Network Byteorder sind interessant für das Ausfüllen der Paketheader, für den Inhalt aber irrelevant. Für die übertragenen Daten zählt nur, dass beide Seiten sie verstehen. Im Falle eines Binärprotokolls, wirst du dich sehr wahrscheinlich auf eine Byteorder festlegen müssen. Welche das ist, ist aber völlig dir überlassen. Da die meisten Maschinen heutzutage wohl Little Endian sind, würde ich mich dafür entscheiden...
Sobald du in der Kommunikation zwischen zwei Maschinen mit unterschiedlicher Byte-Order zutun hast, wird diese für die Anwendung über das Netzwerk-Protokoll hinaus relevant.
Serialisierung, auch in binärer Form, kann auch in solchen Fällen so gestaltet werden, das die beiden Kommunikationspartner immer die Daten in der für sie richtigen Byte-Order erhalten.
Um eben nicht zuviel Aufwand zu betreiben hatte ich ja schon angeregt, bei einfachen Strukturen sizeof() und memcpy zu verwenden und sich eine Menge Aufwand zu sparen. Es kommt eben immer drauf an, was man damit erreichen will. Wenn du ganze threads übers Netzwerk verschieben willst, dann wird das wohl nur über Serialisierung funktionieren. Wenn es nur die Uhrzeit ist, kann man das auch mit einem statischen Speicher erledigen.
simbad
unregistriert
Sobald du in der Kommunikation zwischen zwei Maschinen mit unterschiedlicher Byte-Order zutun hast, wird diese für die Anwendung über das Netzwerk-Protokoll hinaus relevant.
Nicht unbedingt, wenn das der Fall ist, dann machst du imo etwas falsch.
Zitat
Serialisierung, auch in binärer Form, kann auch in solchen Fällen so gestaltet werden, das die beiden Kommunikationspartner immer die Daten in der für sie richtigen Byte-Order erhalten.
Das ist eine Möglichkeit, imo aber keine wirklich gute. Denn was dann als erstes mal gemacht werden muss, ist rauszufinden, in welcher Form die jeweilige Gegenstelle die Daten gerne hätte. Du brauchst also ein eigenes, Byte-Order-unabhängiges, Protokoll nur dafür. Zusätzlich müssen sämtliche Anwendungen, die über dein Protokoll kommunizieren wollen, auf sämtlichen Hardwarearchitekturen beide Varianten implementieren, was unnötigen Code, unnötige Bugs, unnötige Komplexität bedeutet. Abgesehen davon, leidet die Flexibilität des ganzen Systems, denn wenn du z.B. irgendwann mal auf einer exotischen Middle-Endian Maschine laufen willst, kann keine vorhandene Software mit dieser Maschine reden...
Zitat
Bessere Lösung: Die Byte-Order als Teil des Protokolls spezifizieren. Software weiß, auf was für einer Architektur sie läuft und kann, falls nötig, die Daten vor dem Senden bzw. nach dem Empfangen umwandeln...
Um eben nicht zuviel Aufwand zu betreiben hatte ich ja schon angeregt, bei einfachen Strukturen sizeof() und memcpy zu verwenden und sich eine Menge Aufwand zu sparen. Es kommt eben immer drauf an, was man damit erreichen will. Wenn du ganze threads übers Netzwerk verschieben willst, dann wird das wohl nur über Serialisierung funktionieren. Wenn es nur die Uhrzeit ist, kann man das auch mit einem statischen Speicher erledigen.
Das ist problematisch, weil nicht portabel (Byte-Order, Alignment, Padding)...
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »simbad« (20.03.2013, 15:33)
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
simbad
unregistriert
Das was Glocke implementiert hat ist der Presentation-Layer. Und dagehört sowohl die Serialisierung als auch das Re-Ordering hin.
Werbeanzeige