Was ist die beste Kompressionsbibliothek für sehr kleine Datenmengen (3-4 kib?)

Question

Ich arbeite an einem Game-Engine, die losen von Quake 2 abstammt, einige Dinge hinzugefügt wie scripted Effekte (so dass der Server Spezialeffekte im Detail an einem Kunden angeben, sondern nur eine begrenzte Anzahl von fest einprogrammierten Auswirkungen, welche die Client in der Lage ist.) Dies ist ein Kompromiss von Netzwerk-Effizienz für Flexibilität.

Ich habe eine interessante Barriere getroffen. Siehe, die maximale Paketgröße 2800 Bytes ist, und nur einer kann gehen pro Kunden pro Frame.

Hier ist das Skript einen „Funken“ -Effekt zu tun (könnte gut für die Kugel Schlagfunken sein, elektrische Schläge, etc.) http://pastebin.com/m7acdf519 (Wenn Sie es nicht verstehen, nicht schwitzen, es ist eine benutzerdefinierte Syntax ich auf die Frage und nicht relevant gemacht frage ich.)

Ich habe alles getan, um die Größe des Skripts zu schrumpfen. Ich habe sogar die Variablennamen auf einzelne Buchstaben reduziert. Aber das Ergebnis ist genau 405 Bytes. Das heißt, Sie höchstens 6 davon pro Rahmen passen. Ich habe auch ein paar serverseitige Änderungen im Auge, die es auf einem anderen 12 und eine Protokolländerung rasieren könnte, die eine andere 6. Obwohl die Einsparungen sparen könnte würden variieren, je nachdem, was Skript arbeiten.

Doch dieses 387 Bytes, schätze ich, dass nur 41 würde zwischen mehreren Verwendungen des Effekts eindeutig sein. Mit anderen Worten, dies ist ein Hauptkandidat für die Kompression.

Es passiert einfach so, dass R1Q2 (ein rückwärtskompatibel Quake 2 Engine mit einem erweiterten Netzwerk-Protokoll) Zlib Komprimierungscode hat. Ich könnte diesen Code heben oder zumindest folgen sie eng als Referenz.

Aber ist Zlib unbedingt die beste Wahl hier? Ich kann denken zumindest eine Alternative, LZMA, und es könnte leicht sein.

Die Anforderungen:

1. muss sehr schnell sein (muss sehr kleine Leistungseinbußen, wenn Lauf über 100-mal pro Sekunde).
2. Müssen so viele Daten wie möglich in 2800 Bytes stopfen
3. Kleine Metadaten Fußabdruck
4. GPL kompatibel

Zlib sieht gut aus, aber gibt es etwas Schöneres? Denken Sie daran, keine dieser Code wird noch verschmolzen, so gibt es viel Raum für Experimente.

Danke, -Max

EDIT: Dank denen, die die Skripte in Bytecode kompiliert vorgeschlagen haben. Ich sollte dieses clear-- ja gemacht haben, ich dies tue. Wenn Sie möchten, können Sie den entsprechenden Quellcode auf meiner Website finden, obwohl es noch nicht ist „geschönt“.
Dies ist der serverseitigen Code:
Lua Komponente: http://meliaserlow.dyndns.tv:8000/alienarena/ lua_source / lua / scriptedfx.lua
C-Komponente: http://meliaserlow.dyndns.tv:8000/alienarena/ lua_source / Spiel / g_scriptedfx.c
Für das spezifische Beispiel Skript, das ich geschrieben, wird dies eine 1172-Byte-Quelle bis zu 405 bytes-- noch nicht klein genug. (Denken Sie daran, möchte ich so viele von ihnen wie möglich in 2800 Bytes passen!)

EDIT2: Es gibt keine Garantie, dass ein bestimmtes Paket ankommt. Jedes Paket soll enthalten „um den Zustand der Welt“, ohne sich auf Informationen in den vorherigen Paketen übermittelt. Im Allgemeinen werden diese Skripte kommunizieren „Augenschmaus“. Wenn es für einen keinen Raum, wird es aus dem Paket fallen gelassen, und das ist keine große Sache. Aber wenn zu viele get fallen gelassen, beginnen die Dinge seltsam aussehen visuell und dies ist unerwünscht.

Answer 1

FINAL UPDATE: Die beiden Bibliotheken scheinen etwa gleichwertig. Zlib gibt etwa 20% bessere Kompression, während LZO der Decodierung Geschwindigkeit etwa doppelt so schnell ist, aber die Performance-Einbußen für entweder sehr klein ist, fast vernachlässigbar. Das ist meine endgültige Antwort. Vielen Dank für alle anderen Antworten und Kommentare!

UPDATE: Nach LZO-Kompression Implementierung und nur sightly ein bessere Leistung zu sehen, ist es klar, dass mein eigener Code ist für die Performance-Einbußen (massiv erhöhte Anzahl von scripted Effekten möglich, im Paket zu beschuldigen, mein so Effekt „Dolmetscher“ ist viel mehr ausgeübt zu werden.) ich möchte demütig für kriechen, um Verschiebung Schuld entschuldigen, und ich hoffe, dass es keine harten Gefühle sind. Ich werde einige Profilierung tun und dann werde ich vielleicht in der Lage, einige Zahlen zu erhalten, die an jemanden anderen mehr von Nutzen sein wird.

ORIGINAL POST:

OK, ich habe endlich um, um etwas Code dafür zu schreiben. Ich begann mit Zlib, hier ist die erste meine Ergebnisse.

Zlib Compression ist irrsinnig groß. Es wird zuverlässig reduziert Pakete von, sagen wir, 8,5 KiB bis zu etwa 750 Bytes oder weniger, selbst wenn sie mit Z_BEST_SPEED Komprimieren (statt Z_DEFAULT_COMPRESSION.) Die Kompressionszeit ist auch ziemlich gut.

Allerdings habe ich keine Ahnung hatte, die Dekompression Geschwindigkeit von alles könnte möglicherweise sogar so schlimm sein. Ich habe keine tatsächlichen Zahlen, aber es muss 1/8 Sekunde pro Paket zumindest nehmen! (Core2Duo T550 @ 1,83 Ghz.) Völlig inakzeptabel.

Von dem, was ich gehört habe, ist LZMA ein Kompromiss von schlechter Leistung gegen eine bessere Kompression als zu Zlib verglichen. Da Zlib Compression bereits viel des Guten ist und seine Leistung ist schon unglaublich schlecht, ist LZMA die Tabelle ungesehen für jetzt aus.

Wenn LZO die Nullzeit so gut ist, wie es behauptet, ist zu sein, dann ist das, was ich verwende. Ich denke, dass der Server am Ende noch in der Lage sein wird, Zlib Pakete in extremen Fällen zu senden, aber Kunden konfiguriert werden können, um sie zu ignorieren, und das wird der Standard sein.

Answer 2

LZO könnte ein guter Kandidat für diese sein.

Answer 3

zlib könnte ein guter Kandidat sein - Lizenz ist sehr gut, arbeitet schnell und seine Autoren sagen, dass es sehr wenig hat Aufwand und Aufwand ist es, was macht für kleine Datenmengen problematisch verwenden.

Answer 4

Sie sollten sehen OpenTNL und passen einige der Techniken, die sie dort zu verwenden, wie das Konzept der Netzwerk-Strings

Answer 5

Ich würde inclinded werden, um die höchstwertigen Bits jedes Zeichen zu verwenden, die zur Zeit verschwendet wird, durch Verschieben Gruppen von 9 Bytes nach links, werden Sie in 8 Bytes passen.

Man könnte noch weiter gehen und ordnen Sie die Zeichen in einen kleinen Raum - können Sie sie erhalten auf 6 Bits nach unten (dh nur 64 gültige Zeichen haben) durch, zum Beispiel, nicht Großbuchstaben ermöglicht und von jedem Zeichen 0x20 Subtrahieren (so dass Raum wird Wert 0)

Man könnte noch weiter gehen durch die Abbildung der Frequenz der einzelnen Zeichen und machen eine Komprimierung Huffman-Typ macht die avarage Anzahl Bits jedes Zeichens zu reduzieren.

Ich vermute, dass es keine Algorithmen, die Daten besser sparen, dass im allgemeinen Fall, da es im Wesentlichen keine Redundanz in der Nachricht nach den Änderungen ist, dass Sie alrady gemacht haben.

Answer 6

Wie wäre es eine binäre Darstellung des Skripts zu senden?

Also habe ich mit jedem Verfahren eine Kennung.

in den Zeilen eines Abstract Syntax-Baum denke

Diese Mittel preformance Verstärkung an den Kunden aufgrund des einmal Parsing und Abnahme der Größe aufgrund der Methodennamen zu entfernen.