2009-05-12 12 views
0

Ich schreibe einen .Net/C# -Client zu einem Java-Server auf Solaris..Net Client vs Java Server mit Rohdaten

Der Java-Server schreibt Rohbytedaten in einem Gziped-Format, das ich extrahieren muss, aber ich habe Probleme, die Daten in den richtigen Puffergrößen zu lesen. Ich lese die Nachricht nicht deterministisch unvollständig oder vollständig und kann die zweite Nachricht auf keinen Fall lesen. Ich lese die Bytes mithilfe der NetworkStream-Klasse mit der DataAvailable-Eigenschaft.

Meine Vermutung ist, dass es zu einem kleinen/großen Endian-Problem in Verbindung gebracht werden könnte. Muss ich eine spezielle Konvertierung verwenden, um die Daten von Big in Little Endian zu ändern? Muss ich die notwendigen Bytes mit dem gzip-Header lesen?

Früher habe ich den gleichen Server mit einem unkomprimierten Protokoll verwendet und hatte kein Problem mit einem StreamReader mit der Funktion ReadLine zuvor, aber dieses Protokoll war rein textbasiert.

Edit: Leider habe ich keine Wahl, da der Remote-Server und das Protokoll angegeben ist. Ist der Endiness-Teil des GZip-Formats oder muss ich nur den Header entsprechend konvertieren? Die unkomprimierten Daten sind reine UTF8-codierte Strings mit Zeilenumbrüchen als Delimiter.

Antwort

2

Das GZIP-Format ist nicht komplex. Es ist in seiner ganzen Pracht in a simple, accessible specification document, IETF RFC 1952 verfügbar.

Das GZIP-Format gibt die Bit-Reihenfolge für Bytes an. Es ist nicht mit einer Flagge für Endianess einstellbar. Der Hersteller eines GZIP-Streams ist dafür verantwortlich, die Spezifikation in dieser Hinsicht zu erfüllen, und ebenso ein Verbraucher eines GZIP-Streams.

Wenn ich dies debuggen würde, würde ich die Bytes an beiden Enden der Leitung betrachten und verifizieren, dass die eingehenden Bytes die gleichen sind wie die Bytes, die herauskommen. Das ist genug, um die Endian-Probleme beiseite zu legen.

Wenn Sie keinen GZIP-Bytestream erfolgreich übertragen können, versuchen Sie, Testdaten zu senden - 16 Bytes von 0xFF, gefolgt von 16 Bytes von 0xAA usw. usw. Und dann vergewissern Sie sich, dass dies die Daten am anderen Ende sind .

Es tut mir leid, ich weiß nicht, was Sie unter Ich lese die Nachricht nicht deterministisch unvollständig oder vollständig und kann die zweite Nachricht auf keinen Fall lesen. Zweite Nachricht? Welche zweite Nachricht? Die Endianess sollte nicht die Menge der Daten beeinflussen, die Sie erhalten.

Es fühlt sich für mich an, dass Sie nicht darauf vertrauen, dass Sie erfolgreich Daten übertragen. Ich würde vorschlagen, dass Sie dies überprüfen, bevor Sie an Endian-Problemen und GZIP-Formatproblemen arbeiten.

+0

Mein Problem ist, dass der Server völlig außerhalb meiner Kontrolle ist. So ist es mir so schwer. Ich denke, ich habe ein Problem in der Netzwerkschicht, aber ich verstehe nicht, wo es herkommt. – weismat

+0

Ich arbeitete mit dem Server unkomprimiert - daher weiß ich, dass die Netzwerkgrundlagen des Sendens korrekt sind - nur der empfangende Teil ist das Problem. Unkomprimiert Ich benutzte nur StreamReader mit ReadLine und das funktionierte gut ... mein Ende der Kommunikation ist immer noch unkomprimiert, aber ich benötige eine Herausforderung basierte Authentifizierung am Anfang, die bereits fehlschlägt. – weismat