Versenden von Daten im binären vs. XML Format
Florian Scharinger
Meinereiner soll Daten regelmässig (z.b. alle 5sek) übers Netzwerk
verschicken (Das Ganze mit Java programmiert, welche
Kommunikationstechnologie (Sockets, XML-RPC,...) eingesetzt wird, steht
noch nicht fest).
Das Verarbeiten der Daten in XML hätte durchwegs Vorteile, allerdings
stellt sich die Frage, welchen Overhead XML verursacht und ob es dadurch
zu Engpässe im Netzwerk bzw. während der Verarbeitung kommen wird...
Hat entweder
jemand Erfahrung mit der Performance von XML mit Java
oder
kennt jemand Links zu Benchmarks die eben diesen Bereich abdecken.
Interessant wäre wohl ein Vergleich zw. binären und XML Format in
Abhängigkeit zur Datengröße (Byte, kByte,...)
Dank im Voraus,
mfg Florian.
Daniel Höh
Also prinzipiell ist XML ja eine schöne Sache. Und zwar deswegen, weil du drei Dinge gleichzeitig hast: Du versendest Daten, diese Daten bekommen zusätzliche Semantik, und sie sind menschenlesbar. Damit hat XML zwei Vorteile gegenüber Binär-Daten-Versenden. Aber es hat auch Nachteile: Die Größe der Daten wächst, die Interpretation ist schwieriger als die reiner Binärdaten (du brauchst einen Parser....), und du musst zusätzliche Fehler in Betracht ziehen, die durch die Redundanz der Daten entstehen.
XML sollte meiner Meinung nach dort angewendet werden, wo Systemgrenzen überschritten werden, wo viel debuggt werden muss, oder wo Maschinen-Daten von Menschen oder anderen, unbeteiligten Programmen, gelesen werden sollen.
Deine Anwendung, die du oben kurz beschrieben hast, hört sich für mich nicht so an, als sei XML dafür der richtige Weg. In dem Moment, wo du alle 5 Sekunden Daten verschickst, sollte es mehr auf Performance ankommen, als wenn man nur Konfigurationsdateien o.ä. auf Platte speichert. Du solltest dir die Frage beantworten, ob es wichtig ist, dass ein Mensch - oder ein anderes Programm - die verschickten Daten einsehen können soll, oder aber, ob die Schnittstelle vielleicht sehr lose sein soll, so dass z.B. leicht Erweiterungen eingefügt werden können (was beim Binär-Format nicht unbedingt gegeben ist).
Letztendlich kannst du auch einen Mittelweg wählen, XML mit codierten Binärdaten. Da hast du nicht allzuviel Overhead bei der Größe der Daten, und behältst trotzdem viele Vorteile von XML.
Soviel nur zur grundsätzlichen Überlegung.... Eigentlich war das ja nicht deine Frage, aber ich hoffe, ich konnte dir vielleicht trotzdem helfen.
Grüße,
Daniel
Florian Scharinger
Daniel Höh wrote:
> Deine Anwendung, die du oben kurz beschrieben hast, hört sich für
> mich nicht so an, als sei XML dafür der richtige Weg. In dem Moment,
> wo du alle 5 Sekunden Daten verschickst, sollte es mehr auf
> Performance ankommen, als wenn man nur Konfigurationsdateien o.ä. auf
> Platte speichert. Du solltest dir die Frage beantworten, ob es
> wichtig ist, dass ein Mensch - oder ein anderes Programm - die
> verschickten Daten einsehen können soll, oder aber, ob die
> Schnittstelle vielleicht sehr lose sein soll, so dass z.B. leicht
> Erweiterungen eingefügt werden können (was beim Binär-Format nicht
> unbedingt gegeben ist).
Die gesendeten Daten sollten eben 1. erweiterbar sein und 2. auf Grund
des Typs der Nachricht sollte eine entsprechende Visualisierung
erfolgen. Daher wäre mir XML eben sehr recht, allerdings ist die
Performance bei dem Ganzen eben auch sehr wichtig.
> Letztendlich kannst du auch einen Mittelweg wählen, XML mit codierten
> Binärdaten. Da hast du nicht allzuviel Overhead bei der Größe der
> Daten, und behältst trotzdem viele Vorteile von XML.
Kannst Du mir das genauer erklären ? "xml mit codierten Binäredaten"
> Eigentlich war das ja nicht deine Frage,
Richtig :)
> aber ich hoffe, ich konnte dir vielleicht trotzdem helfen.
Eine Anregung mehr,
Danke
Florian
Stefan Matthias Aust
> Meinereiner soll Daten regelmässig (z.b. alle 5sek) übers Netzwerk
> verschicken (Das Ganze mit Java programmiert, welche
> Kommunikationstechnologie (Sockets, XML-RPC,...) eingesetzt wird,
steht
> noch nicht fest).
Wäre aber wichtig, damit nicht etwa der Overhead von HTTP/XML-RPC/SOAP
usw. nicht größer als die Nutzdaten ist und so die ganze Diskussion
obsolete macht.
> Das Verarbeiten der Daten in XML hätte durchwegs Vorteile
Welche? Benenn sie konkret oder es gibt sie nicht.
>, allerdings
> stellt sich die Frage, welchen Overhead XML verursacht und ob es
dadurch
> zu Engpässe im Netzwerk bzw. während der Verarbeitung kommen wird...
> Hat entweder
> jemand Erfahrung mit der Performance von XML mit Java
> oder
> kennt jemand Links zu Benchmarks die eben diesen Bereich abdecken.
Ich denke nicht, dass du da etwas generisch benchmarken kannst sondern
du musst für deinen speziellen Fall in alle denkbaren Varianten einen
eigenen Test schreiben, den du dann durchmessen kannst.
Ich würde aus Performance-Gründen eher gegen XML tendieren.
Entscheidend ist, ob das Format auch von Menschen lesbar sein soll. In
diesem Fall würde ich ein eigenes Format benutzen falls ich dadurch
besser werde als XML, auf das ich gzip anwende. Dann ist entscheidend,
ob ich mir das Kodieren, Packen und Dekodieren der (Text-)Daten leisten
kann/will. Es kann effizienter sein, eher mehr bytes zu übertragen,
dafür aber das format einfacher lesen/schreiben zu können, als das
letzte Byte aus dem Text zu quetschen.
> Interessant wäre wohl ein Vergleich zw. binären und XML Format in
> Abhängigkeit zur Datengröße (Byte, kByte,...)
Kannst du dir doch einfach ausrechnen:
<?xml version="1.0"?>
<doc>
<value type="int">5</value>
</doc>
Nutzdaten: 1 Char
Gesamtgröße: 64 Chars (falls ich mich nicht verzählt habe)
Alternatives Encoding:
I5
Nutzdaten: 1 Char
Gesamtgröße: 2 Chars
Binär:
0x05
Nutzdaten: 1 Byte
Gesamtgröße: 1 Byte (Zahlen bis 200 oder so kann ich als 1 byte
kodieren, ansonsten fasse ich das Zeichen als Typ für die eigentlichen
Daten auf, die dann jeweils abhängig sind, etwa 200=String, danach Zahl
mit Länge und dann UTF-8 (oder ISO8859-15, falls das reicht) kodierte
Zeichen.)
bye
--
Stefan Matthias Aust
www.3plus4software.de
Florian Scharinger
Stefan Matthias Aust wrote:
>>Meinereiner soll Daten regelmässig (z.b. alle 5sek) übers Netzwerk
>>verschicken (Das Ganze mit Java programmiert, welche
>>Kommunikationstechnologie (Sockets, XML-RPC,...) eingesetzt wird,
>
> steht
>
>>noch nicht fest).
>
>
> Wäre aber wichtig, damit nicht etwa der Overhead von HTTP/XML-RPC/SOAP
> usw. nicht größer als die Nutzdaten ist und so die ganze Diskussion
> obsolete macht.
Genau kann ich's noch nicht sagen, zur Auswahl stehen wohl Socket,
XML-RPC, Corba.
SOAP sicher nicht.
>>Das Verarbeiten der Daten in XML hätte durchwegs Vorteile
>
>
> Welche? Benenn sie konkret oder es gibt sie nicht.
Wie schon im Reply von Daniel Höh erwähnt:
Die gesendeten Daten sollten eben 1. erweiterbar sein und 2. auf Grund
des Typs der Nachricht sollte eine entsprechende Visualisierung
erfolgen. Daher wäre mir XML eben sehr recht, allerdings ist die
Performance bei dem Ganzen eben auch sehr wichtig.
[...]
> Ich denke nicht, dass du da etwas generisch benchmarken kannst sondern
> du musst für deinen speziellen Fall in alle denkbaren Varianten einen
> eigenen Test schreiben, den du dann durchmessen kannst.
>
> Ich würde aus Performance-Gründen eher gegen XML tendieren.
Ich auch, die Frage ist, ob ichs trotzdem vertreten kann oder nicht :(
Danke mal für die Auflistung,
was ich wohl genau gemeint habe, ist ein Performancevergleich zw.
binären und XML Daten beim Versenden übers Netzwerk. Das XML prinzipiell
schlechter aussteigt ist klar, aber um wieviel?
BTW: Da du gzip erwähnt hast: Gibts in Java schon die Möglichkeit, XML
komprimiert übers Netz zu schicken ?
mfg Florian.
Aljoscha Rittner
[...]
> was ich wohl genau gemeint habe, ist ein Performancevergleich zw.
> binären und XML Daten beim Versenden übers Netzwerk. Das XML prinzipiell
> schlechter aussteigt ist klar, aber um wieviel?
Wie SMA schon schrieb. Abhängig von den Daten.
> BTW: Da du gzip erwähnt hast: Gibts in Java schon die Möglichkeit, XML
> komprimiert übers Netz zu schicken ?
Klar. Es gibt eine zip-API zum komprimieren von Streams. Es spricht
nichts dagegen einen XML-Strom zu zippen und auf der Gegenseite zu
entzippen. Der ZIP-Vorgang ist aber schon relativ aufwändig.
Vor einiger Zeit hatte ich einen Artikel gelesen, der sich mit
speziellen Zippern für XML-Dokumente befaßt hatte. Ich komme wirklich
nicht mehr drauf. Der angesprochene Zipper war verlußtbehaftet, was
die optische Strukturierung betraf (dh. Leerzeichen zum Einrücken
wurden erstmal komplett gelöscht). Ansonsten war der Huffman-Puffer
vorkonfigurierbar. Damit war der ZIP-Vorgang sehr schnell, weil die
Bibliothek der häufigsten Zeichenketten nicht erst erzeugt werden
mußte, wenn die Daten gezippt wurden, sondern schon aus dem XML-Schema
bekannt gemacht wurden. Der Verhältnis Nutzdaten zu Protokoll-Daten
war dadurch ziemlich gut.
Gruß,
Josch.
--
Einige Tags in de.comp.lang.java ( siehe http://www.dclj.de/dcljstart.html )
[OT] - OffTopic: Der Artikel ist außerhalb des Themas von dclj
[DB] - Fragen zu Datenbanken, JDBC und SQL über Java
[JPEC] - Java PEformance Contest. Wettbewerb für den schnellsten Source.
Stefan Matthias Aust
> Die gesendeten Daten sollten eben 1. erweiterbar sein und 2. auf Grund
> des Typs der Nachricht sollte eine entsprechende Visualisierung
> erfolgen.
Na und?
> Daher wäre mir XML eben sehr recht
Wieso? Bist du nicht in der Lage, ein erweiterbares Format selbst zu
definieren? :-) XML macht doch auch nichts magisches, sondern bietet nur
eine Beschreibungssprache, der du selbst eine Bedeutung zuweisen musst.
Ein Text wie
A=x,B=y,...
ist doch ein genauso erweiterbares Format wie
<A>x</A><B>y</B>
der einzige Vorteil von XML ist, dass du bereits fertige Parser dafür
bekommst. Diese sind aber meist so komplex, dass sie manchmal nicht
schnell genug sind bzw. so umfangreich, dass man sie auch selbst nicht
optimieren kann. Das XML ein gutes Austauschformat ist, ist für deinen
Zweck unerhelblich, da es ja nur um eine direkte Kommunikation zweier
Prozesse geht.
> was ich wohl genau gemeint habe, ist ein Performancevergleich zw.
> binären und XML Daten beim Versenden übers Netzwerk. Das XML
prinzipiell
> schlechter aussteigt ist klar, aber um wieviel?
Ich sagte doch, selbst messen macht klug. Wie willst du das allgemein
formulieren?
> BTW: Da du gzip erwähnt hast: Gibts in Java schon die Möglichkeit, XML
> komprimiert übers Netz zu schicken ?
Nimm einen GZip-Filter-Stream.
Christoph Seidel
> <?xml version="1.0"?>
> <doc>
> <value type="int">5</value>
> </doc>
oder
<d v = "5"/>
?
Florian Scharinger
Stefan Matthias Aust wrote:
> "Florian Scharinger" <florian.s...@siemens.at> schrieb ...
>
>
>>Die gesendeten Daten sollten eben 1. erweiterbar sein und 2. auf Grund
>>des Typs der Nachricht sollte eine entsprechende Visualisierung
>>erfolgen.
>
>
> Na und?
>
>
>>Daher wäre mir XML eben sehr recht
Z.B. denke ich an Visualisierung als Webpage via XLS ... wäre eine
Möglichkeit.
>
>
> Wieso? Bist du nicht in der Lage, ein erweiterbares Format selbst zu
> definieren? :-) XML macht doch auch nichts magisches, sondern bietet nur
> eine Beschreibungssprache, der du selbst eine Bedeutung zuweisen musst.
> Ein Text wie
>
> A=x,B=y,...
>
> ist doch ein genauso erweiterbares Format wie
>
> <A>x</A><B>y</B>
>
Richtig, aber warum ein properitäres Format einsetzen, wenns anders auch
geht. Ich gehe davon aus, dass Du (eben so wie ich) der Meinung bist,
dass XML vorallem z.Z. ein Hype ist. Ich bin nicht darauf aus, XML in
meine Anwendung zu bringen, nur um eben auch XML drin zu haben ... aber
wenns Vorteile bringt, warum nicht.
> der einzige Vorteil von XML ist, dass du bereits fertige Parser dafür
> bekommst. Diese sind aber meist so komplex, dass sie manchmal nicht
> schnell genug sind bzw. so umfangreich, dass man sie auch selbst nicht
> optimieren kann. Das XML ein gutes Austauschformat ist, ist für deinen
> Zweck unerhelblich, da es ja nur um eine direkte Kommunikation zweier
> Prozesse geht.
>
Dass es sich um direkte Kommunikation handelt ist richtig, allerdings
ist nicht gesagt, dass die Daten (in Zukunft) nicht auch anderweitig
verarbeitet werden...
>
>>was ich wohl genau gemeint habe, ist ein Performancevergleich zw.
>>binären und XML Daten beim Versenden übers Netzwerk. Das XML
>
> prinzipiell
>
>>schlechter aussteigt ist klar, aber um wieviel?
>
>
> Ich sagte doch, selbst messen macht klug.
Ich weiss, ich weiss, aber warum die Arbeit antun, wenn ev. schon wer
dies vor mir gemacht hat. Aus diesem Grunde war eben auch das Posting.
[...]
>>BTW: Da du gzip erwähnt hast: Gibts in Java schon die Möglichkeit, XML
>>komprimiert übers Netz zu schicken ?
>
>
> Nimm einen GZip-Filter-Stream.
Ok,
mfg Florian.
bernd hohmann
> Meinereiner soll Daten regelmässig (z.b. alle 5sek) übers Netzwerk
> verschicken [...]
wenn du es ganz einfach, sicher und erweiterbar haben willst und
gewährleistet ist, dass die programmstände bei sender und
empfänger gleich sind, dann machst du
class Message implements Serializable
public String strText1="";
public String strText2="";
public long lngValue1=-1;
public String toString() {
return "Message is: "+strText1+....
}
und verschickst das über einen ObjectOutputStream den du bei
entsprechender grösse deiner message nochmal in einen
Deflater/Inflater stream packen kannst (lohnt sich so ab 50kb).
das wirklich einzige problem ist, dass die klassen immer auf
beiden seiten synchron gehalten werden müssen (es sei denn, man
arbeitet mit einer seriennummer und überschreibt
readObject/writeObject und befüllt dort das fehlende mit
entsprechenden presets).
alles andere halte ich für übertriebenen aufwand oder den
versuch ein rundes klötzchen in ein viereckiges loch zu hämmern.
bernd
--
class Mandel{public static void main(String a[]){float b,e,r,n,d;int h;
for(e=1.1f;e>-1.2;e-=.1){for(b=-2;b<1;b+=.04){r=n=0;for(h=127;r*r+n*n<4
&&--h>32;){d=r;r=r*r-n*n+b;n=2*d*n+e;}System.out.write(b>0.98?10:h);}}}}
Frank Buss
> class Mandel{public static void main(String a[]){float b,e,r,n,d;int h;
> for(e=1.1f;e>-1.2;e-=.1){for(b=-2;b<1;b+=.04){r=n=0;for(h=127;r*r+n*n<4
> &&--h>32;){d=r;r=r*r-n*n+b;n=2*d*n+e;}System.out.write(b>0.98?10:h);}}}}
Interessant, aber sind mindestens 10 Zeichen zuviel drin :-)
class Mandel{public static void main(String[]a){float b,e,r,n,d;int h;
for(e=1.1f;e>-1.2;e-=.1)for(b=-2;b<1;b+=.04,System.out.write(b>1?10:h))
for(r=n=0,h=127;r*r+n*n<4&&--h>32;d=r,r=r*r-n*n+b,n=2*d*n+e);}}
--
Frank Buß, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Stefan Matthias Aust
> oder
>
> <d v = "5"/>
> ?
Also wenn schon, dann auch ohne Leerzeichen vor und nach dem
Gleichheitszeichen. Attributwerte für Text zweckzuentfremden ist aber
IMHO nicht gut, da das ganze nicht mehr funktioniert, wenn du
mehrzeilige Strings, Bilder, Binärdaten usw. darstellen willst. Dann
musst du irgendwie die Attributwerte encoden und hast so ein eigenes
Format in XML gewrappt.
Außerdem, waren wir nicht so weit, dass der Vorteil einer XML-Version
die Lesbarkeit auch für Menschen wäre? Das ist bei d v="5" nicht
wirklich gegeben.
bye
--
Stefan Matthias Aust //
www.3plus4software.de // Inter Deum Et Diabolum Semper Musica Est
Johann Burkard
> Das Verarbeiten der Daten in XML hätte durchwegs Vorteile, allerdings
> stellt sich die Frage, welchen Overhead XML verursacht und ob es dadurch
> zu Engpässe im Netzwerk bzw. während der Verarbeitung kommen wird...
XML macht da Sinn, wo Daten zwischen verschiedenen Systemen ausgetauscht
und in systemunabhängigen Formaten gespeichert werden sollen.
Wenn das bei dir nicht der Fall ist, blähst du deine Daten damit nur auf.
Ansonsten vielleicht interessant:
http://www.extreme.indiana.edu/~aslom/exxp/
Johann
--
Geh sterben, Du Abschaum...
(Klaus "Diego Alfredo Unada" Ketelaer in
<allefg$ml1$06$1...@news.t-online.com>)
Daniel Höh
> > Binärdaten. Da hast du nicht allzuviel Overhead bei der Größe der
> > Daten, und behältst trotzdem viele Vorteile von XML.
>
> Kannst Du mir das genauer erklären ? "xml mit codierten Binäredaten"
Was ich damit meinte ist so eine Art Base64-Codierung für Binärdaten, wie sie in der MIME-Codierung verwendet wird.
Du codierst deine Binärstrings einfach so, dass sie nur noch druckbare Zeichen enthalten, und schreibst sie in ein XML-Tag rein. Wie man sowas codieren kann, kannst du dir angooglen.
Die übrigen Header-Informationen lässt du dann einfach in XML-Form stehen.
Dabei hast du eben den Vorteil, menschenlesbare Header zu haben, und deine Binärdaten trotzdem relativ kompakt verschicken zu können (lediglich 8/6 so groß wie der Original-Binärstring, das kommt durch die Codierung von 8-Bit Binärdaten in 6-Bit druckbare Zeichen).
Daniel
bernd hohmann
> Interessant, aber sind mindestens 10 Zeichen zuviel drin :-)
frank , du hast eindeutig zu viel zeit oder keinen bock auf dein
derzeitiges projekt :-)
bernd
..
Boris Podolsky: James ?! Wie geht es dir, was machen die Ratten ?
James Moreland: Nun - zur Zeit sind es eher die Studenten, mit denen ich Experimentiere.
Kurt Gödel: Um Herrgottswillen, diese Labyrinthe müssen aber gross sein !
Frank Buss
> frank , du hast eindeutig zu viel zeit oder keinen bock auf dein
> derzeitiges projekt :-)
Da mein derzeitiges Projekt nichts mit Java zu tun hat, ist das eine
gute kurzweilige Übung in meiner Freizeit, um Java nicht zu verlernen.
Aber wohl auch nicht viel sinnvoller, als deine Seite ohne www
http://harddiskcafe.de/ :-)
bernd hohmann
> Da mein derzeitiges Projekt nichts mit Java zu tun hat, ist das eine
> gute kurzweilige Übung in meiner Freizeit, um Java nicht zu verlernen.
> Aber wohl auch nicht viel sinnvoller, als deine Seite ohne www
> http://harddiskcafe.de/ :-)
da musste ich aber jetzt 2x nachdenken.... haste mal auf den
blinkenden cursor geklickt ?
Frank Buss
> da musste ich aber jetzt 2x nachdenken.... haste mal auf den
> blinkenden cursor geklickt ?
Klar, das hatte ich schon entdeckt. Erinnert mich etwas an den Roman "Cyber
City" (wirklich zu empfehlen):
http://sites.inka.de/sites/darwin/buecher2000/cybercity.html
Kann man nur hoffen, das die Software dann weniger Bugs hat, als heutzutage
üblich, wenn Computer mal ganze Universen simulieren werden können.
Christoph Seidel
> Also wenn schon, dann auch ohne Leerzeichen vor und nach dem
> Gleichheitszeichen. Attributwerte für Text zweckzuentfremden ist aber
> IMHO nicht gut, da das ganze nicht mehr funktioniert, wenn du
> mehrzeilige Strings, Bilder, Binärdaten usw. darstellen willst.
mehrzeilig sollte imo kein prob sein
binär als base64, das ist standard
da wo attribute nicht gehen, mit refs arbeiten
> Außerdem, waren wir nicht so weit, dass der Vorteil einer XML-Version
> die Lesbarkeit auch für Menschen wäre? Das ist bei d v="5" nicht
> wirklich gegeben.
imo sollte das xml durch ein schema beschrieben werden, das kann ja
annotiert werden
die visualisierung durch xml+xsl=html
wollt ja nur sagen: auch xml kann kompakt sein, das allg. übliche:
<superlangername>...</superlangername> muß net sein
Stefan Matthias Aust
>>> Daher wäre mir XML eben sehr recht
>>
> Z.B. denke ich an Visualisierung als Webpage via XLS ... wäre eine
> Möglichkeit.
Ein zu XML semantisch äquivalentes Format könnte man für XLS einfach
zuvor in XML umwandel. Was man so als XML kennt, ist ja nur eine
Syntax. Die Semantik (das XML-Infoset wenn ich den Begriff richtig
erinnere) ist das entscheidende und die sagt gerade mal aus, dass es
eine hierachische Struktur aus Knoten gibt und das man an jedem Knoten
textuelle Attribute festmachen kann und noch ein besonderes "Text"-Attribut.
> Richtig, aber warum ein properitäres Format einsetzen, wenns anders auch
> geht.
Weil das eben viel einfacher zu verstehen, zu benutzen und zu parsen
ist, da es auf das notwendige zusammengestrichen wurde.
> Ich gehe davon aus, dass Du (eben so wie ich) der Meinung bist,
> dass XML vorallem z.Z. ein Hype ist. Ich bin nicht darauf aus, XML in
> meine Anwendung zu bringen, nur um eben auch XML drin zu haben ... aber
> wenns Vorteile bringt, warum nicht.
Die Idee hinter XML bringt vorteile, die sind aber (bis auf wenige
Ausnahmen wie XSLT) nicht auf die eine XML-Syntax beschränkt.
> Dass es sich um direkte Kommunikation handelt ist richtig, allerdings
> ist nicht gesagt, dass die Daten (in Zukunft) nicht auch anderweitig
> verarbeitet werden...
XP-Regel des Tages: Versuche nicht für die Zukunft zu planen, es wird
dir nicht gelingen. Schon aus dieser Erkenntnis heraus solltest du
genau das nehmen, was für deinen konkreten Fall am besten ist und dir
erst morgen die Sorgen von morgen machen.
bye
--
Florian Scharinger
bernd hohmann wrote:
> On Thu, 17 Oct 2002 11:42:13 +0200, Florian Scharinger wrote:
>
>
> >Meinereiner soll Daten regelmässig (z.b. alle 5sek) übers Netzwerk
> >verschicken [...]
>
>
> wenn du es ganz einfach, sicher und erweiterbar haben willst und
> gewährleistet ist, dass die programmstände bei sender und
> empfänger gleich sind, dann machst du
>
> class Message implements Serializable
> public String strText1="";
> public String strText2="";
> public long lngValue1=-1;
> public String toString() {
> return "Message is: "+strText1+....
> }
>
> und verschickst das über einen ObjectOutputStream den du bei
> entsprechender grösse deiner message nochmal in einen
> Deflater/Inflater stream packen kannst (lohnt sich so ab 50kb).
[...]
Das Problem ist, dass die Nachrichten wahrscheinlich auch von nicht
Java-Programmen (C++) lesbar sein sollen, darum ist die Serialisierung
für meinen Fall eher nicht geeignet.
Möglichkeit wäre natürlich, vor dem C++ Programm, einen Java-Wrapper zu
stellen, ich bin mir eben nicht sicher, ob es den Aufwand wert ist, bzw.
ob sich nicht ein Format finden läßt, welches sicher von beiden Seiten
lesbar ist...
mfg Florian.