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.
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
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