Multiple Byte Arrays Down One Socket

I have an application where I wish to take 4 byte arrays and push it down one socket in one continuous stream. Then the other end will take it and decode it into four byte arrays again. Anybody have a solution for this? The byte arrays are in a ring buffer so i would have to be writing data pretty fast to it.

What if a byte array is empty or all have a value of 0? Is there any way I can preserve bandwidth there? Is there any way I can compress that data using features from the API?

Solution? Am I asking the question to where it is easy to understand?

[576 byte] By [DJHotIcea] at [2007-11-27 6:58:59]
# 1
Most generally speaking, it is an issue of application protocol design. Do as you like it.There can be several choices but the fastest one would use a set 'order' for the principle of the protocol, rather than some marking on data.
hiwaa at 2007-7-12 18:49:32 > top of Java-index,Core,Core APIs...
# 2
hey i think a concept called Serialization would b helpful...
manishmulani@nitka at 2007-7-12 18:49:32 > top of Java-index,Core,Core APIs...
# 3
http://www.exampledepot.com/egs/java.io/SerializeObj.html
manishmulani@nitka at 2007-7-12 18:49:32 > top of Java-index,Core,Core APIs...
# 4

No on the compression. Make a file with four 0s in it and run WinZip or something similar on it. Didn't get what was expected?

WinZip took the string "0000" and compressed to 118 bytes. Most of those bytes are checksums and header about the compressed file. Zip probably just stored the 0000 directly because by the time it compressed it, it would have take more than 4 bytes.

The problem is that very few compression schemes work without metadta. LZW and the FAX format come to mind, but even these will only save you a byte, maybe.

For the protocol itself are both sides Java? If not, then I'd just write the bytes to the socket. Because you are using bytes only then you don't have to worry about the "Endianess" of the other machine.

On the receiving end, you will just read four bytes. You will need to decide what to do if you only get 3 bytes. You will also need to figure out how long you should listen for data before you decide that the sender is broken.

One other thing to think about. Using a simple ethernet connection between two machines: There is a 66 byte overhead. 26 for the ethernet, 20 for IP and 20 for TCP. So for every 70 bytes you send you only get 4 bytes of data. Only 5% of what goes down the wire is useful.

awyorka at 2007-7-12 18:49:32 > top of Java-index,Core,Core APIs...
# 5
I need something that would work well with dial up possibly...Also any idea on a byte i could use as a seperator? I need a unique combination that is kinda hard because the information I'm gathering can be pretty much be anything as it is audio input.
DJHotIcea at 2007-7-12 18:49:32 > top of Java-index,Core,Core APIs...
# 6

You can't use a byte as a separator because there is no byte value that will not occur in the data. You need an application protocol to encapsulate each message. It could be something as simple as transmitting the length of the following data before the data. Or a serialized object. The possibilities are endless.

ejpa at 2007-7-12 18:49:32 > top of Java-index,Core,Core APIs...