Home/ Questions/Q 203287
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T17:21:55+00:00

I am writting a .Net/C# client to a Java Server on Solaris. The Java

  • 0

I am writting a .Net/C# client to a Java Server on Solaris.

The Java server is writting Raw byte data in a Gziped format which I need to extract, but I am having trouble to read the data in the right buffer sizes. I read the message not-deterministicly incomplete or complete and can not read the second message in any case.
I am reading the bytes using the NetworkStream class with the DataAvailable property.

My guess is that it could be related to a little/big endian problem.
Do I need to use a special conversion to change the data from big into little Endian? Do I need to read the necessary bytes using the gzip header?

I used to use the same server with an uncompressed protocol before and had no problem using a StreamReader with the ReadLine function before, but that protocol was purely text based.

Edit: Unfortunately I have no choice as the remote server and protocol is given. Is the endiness part of the GZip format or do I only need to convert the header accordingly? The uncompressed data are pure UTF8-encoded strings with line breaks as delimiters.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The GZIP format is not complex. It is available in all its glory in a simple, accessible specification document, IETF RFC 1952.

    The GZIP format specifies the bit-order for bytes. It is not tunable with a flag for endianness. The producer of a GZIP stream is responsible for conforming to the spec in that regard, and a consumer of a GZIP stream, likewise.

    If I were debugging this, I would look at the bytes on either end of the wire and verify that the bytes going in are the same as the bytes coming out. That’s enough to put aside the endian issues.

    If you don’t have success transmitting a GZIP bytestream, try transmitting test data – 16 bytes of 0xFF, followed by 16 bytes of 0xAA, etc etc. And then, verify that this is the data coming out the other end.

    I’m sorry, I don’t know what you mean by I read the message not-deterministicly incomplete or complete and can not read the second message in any case. Second message? What second message? The endianness shouldn’t affect the amount of data you receive.

    It feels to me that you don’t have confidence that you are successfully transmitting data. I would suggest that you verify that before working on endian issues and GZIP format issues.

    • 0