Develop Reference

Spring Integration - Which Deserializer to use for an endless stream of bytes with only a start-byte (being part of the message)

We are trying to read enOcean data from TCP.
The protocol description for enOcean ESP3-Messages says:
As soon as a Sync.-Byte (value 0x55) is identified, the subsequent 4 byte-Header is compared with the corresponding CRC8H value.
If the result is a match the Sync.-Byte is correct. Consequently, the ESP3 packet is detected properly and the subsequent data will be passed.
If the Header does not match the CRC8H, the value 0x55 does not correspond to a Sync.-Byte. The next 0x55 within the data stream is picked and the verification is repeated.
Until now we used a device (client) that automatically closes the connection to our server after the end of a number of messages coming within a very small timeframe (some milliseconds). Therefore we were able to use a simple ByteArrayRawSerializer. Whenever the connection was closed we got the byte array, read the data, found all the sync-Bytes and were able to interpret the messages.
Now there is a new device that is holding the connection for a very long time (several minutes), so we somehow need another way to read the data from the stream. Because there is no End-of-Message-Byte and the SyncByte 0x55 is part of the message and a ByteArrayLengthHeaderSerializer doesn't suit us either we wonder what we could use:
Is there any Deserializer usable for our scenario? Is it possible to writer our own Deserializer (in this specific scenario)? Or is there another (simpler) way we should follow? Maybe use an Interceptor?

You would need to write a custom deserializer.

Protocol for platform independent socket communication

I'm trying to understand how platform independent socket communication works, because I would like to share socket data between a Java server and some native Unix and Windows clients. Sockets are platform independent by design, but the data representation is machine-related, hence it is advantageous if the TCP data abstracts the real data format, because a data format that is supported on one system doesn't have to be necessarily supported on another.
For example if I want to send an unsigned int value from a C++ client program to a Java server I must tell the server that this number should be interpreted as a negative integer. How does this kind of abstraction work? With my limited knowledge I would just send a number as text and then append some kind of unique character sequence that tells the receiver what kind of data he received, but I don't know if this is a viable approach.
To be a bit more concrete: I would like to send messages that contain the following content:
At the beginning of the message some kind of short signal or command
so that the receiver exactly knows what to do with the data that will follow.
Then some textual content of arbitrary length.
Followed by a number, which can be also text, but should be
interpreted separately.
At the end maybe a mark that tells the server that the message ends
here.
TCP processes the data in byte chunks. Does this mean when I write an UTF-8 encoded char in one byte that this char is interpreted in the same way on different machines if the client machines take Java's big endian byte order into account? Thanks for any input and help.

Sockets are independent but not the data transmitted in (Types length, byte order, String encoding, ...)
Look at Thrift, Protobuf or Avro if you want to send binary data with cross-languages and cross-platform functionnalities

Hebrew data from RPG program to Java program incorrectly ordered

I'm sending hebrew data from an RPG program to a Java program and some of the data is coming in not as expected. The RPG program is running on an iSeries machine with CCSID 65535. The java is accessed through remote method invocation.
Most of the hebrew is received by the Java program in logical order. I then process it with Java's Bidi class to get it into visual order as I'm eventually writing it to a PDF. Almost all of the data is OK except for a few lines that are equations.Assume capital H's are hebrew data. This is how the line should look: 300 X 250 X 500 :HHHHI'm receiving the line as this: HHHH: 500 250 X 300 XThe 500 is not in the order I would expect and the Bidi class does not handle it properly. There are a few lines such as these and are the only lines that the Bidi class does not work with. I would assume the line to come in as: HHHH: 300 X 250 X 500 as I believe that would be the logical order. It seems to keep the 500 in the RTL segment and then flip to LTR once it hits the X. Does anyone have any ideas as to why this would be? Thanks for your help.
EDIT: The java is actually invoked through the JNI and not RMI.

So I ended up finding out what was going on here and am answering my own question in case any one else ever runs into a similar issue. The Hebrew was being stored on the iSeries in code page 424. This is a Hebrew code page so all was well with the storing on the iSeries. We had some print drivers on the iSeries that were handling the Hebrew data correctly so I knew the issue had to be either on the transfer between the iSeries and Java or when we create the String of data in Java.It turns out that the iSeries was storing the Hebrew in print order so it was already in the order that I needed it to be to write it to the PDF. When we were transferring it to the Java program we were using an RPG character byte array. This character byte array will convert to Unicode when it is sent to the Java method. This Unicode conversion would attempt to process the bidi data that was already in the correct order and was moving data out of order. The fix was to switch to an RPG integer byte array which won't do this conversion. Then when I receive the byte array in Java I get the job's CCSID from an AS400 object and create a new String with it.The job's CCSID gets returned as a character set. So on our US based system this will return Cp037 and I can use that in a new String(byte[] source, String charsetName) constructor and it will convert the byte array which is in an EBCDIC code page to Java's encoding. On a Hebrew based system this will return Cp424 which I can do the same thing with to convert it.

Appending a collection of new bytes

I have a server that sends bytes back to a client app, when the client app receives a finished response from the server i want to gather the bytes before the finish response comes back to the client. How do i append theses bytes back together again.
So when the bytes are sent to the server these bytes are split up into segments of say 100 bytes and when the server sends the bytes back to the client i want to to gather these segments back into its normal form again.
I have had a look at Concatenating to arrays but is there a simple way?

You could create a ByteArrayOutputStream, then write() the arrays to it, and finally use toByteArray().

Guava's Bytes class provides a Bytes.concat method, though it's more useful when you have a fixed number of arrays you want to concatenate than if you're gathering a variable number of arrays to concatenate. ByteArrayOutputStream is probably what you want here, though, based on your description, because it doesn't require you to keep each individual array you receive around in order to concatenate them... you can just add them to the output stream.

Java reading from comport

Problem: Trying to read from some electronic scales using the comport via Java
I am trying to read from a com port using Java. So far I have been successfull in creating a small application that uses the Java SerialPort and InputStream classes to read from the comport.
The application uses a SerialPortEventListener to listen to event sent via the comport of the scale to the computer. So far I have had some success by using an InputStream inside the event listener to read some bytes from the comport, however the output does not make any sense and I keep getting messages in the form of:
[B#8813f2
or
[B#1d58aae
To clarify I am receiving these messages on screen when I interact with the keypad of the scale. I just need some help on interpreting the output correctly. Am I using the correct classes to read and write to the comport?

You have read the data into a byte[], and then attempted to dump it by using System.out.println(data) where data is declared byte[] data. That, unfortunately will just print the array's internal representation, which is, uselessly, '[' followed by the hex hash code.
Instead, you want to dump the contents of the array. Using
System.out.println(Arrays.toString(data))
is the simplest way which should work for you.
Otherwise, you need to iterate the array, and print each byte, or transform the byte array to a String using, for example, new String(data) (which will use the platform default encoding).

Those look like the result of printing a byte array object as a raw object reference. So your call has some sort of confused call to System.out.something or System.err.something, most likely.

The object you have there is apparently a byte array. I take it you're taking the object and printing it to the console.
See: http://download.oracle.com/javase/1.5.0/docs/api/java/lang/Class.html#getName()
and: http://download.oracle.com/javase/1.5.0/docs/api/java/lang/Object.html#toString()