How to read network stream data in Java (Protocol packets)

Question

Am working on decoding a protocol used by a certain gps device to communicate. Right now, am analyzing the first data packet that it sends. I am able to read it, but am thinking am not reading it properly.

Here is what i got so far:

    public static String toHex(byte[] bytes) {
    BigInteger bi = new BigInteger(1, bytes);
    return String.format("%0" + (bytes.length << 1) + "X", bi);
}

private void ProcessInitialPacket(){
            int port = 1954;
    System.out.println("Listening on port :"+port);
    byte[] data =  new byte[17];
    byte[] ackPacket = new byte[2];
    byte[] dataPacket= new byte[15];
    try {
        ServerSocket sSocket = new ServerSocket(port);
        Socket cSocket = sSocket.accept();          
        DataInputStream dataIN = new DataInputStream(cSocket.getInputStream());
        int packetSize=dataIN.read(data,0,data.length);         
        System.arraycopy(data, 0, ackPacket, 0, 2);
        System.arraycopy(data,2,dataPacket,0,15);

        System.out.println("Total packet size: "+ packetSize);
        System.out.println("ACK PACKET : "+ toHex(ackPacket));
        System.out.println("DATA PACKET: "+ toHex(dataPacket));
        System.out.println("FULL PACKET: "+ toHex(data));
    } catch (IOException e) { 
        e.printStackTrace();
    }
}

the output:

-PARSER()--

-INITSESSION-- Listening on port :1954

Total packet size: 17

ACK PACKET : 000F

DATA PACKET: 333532383438303236323631393534

FULL PACKET: 000F333532383438303236323631393534

------CLOSESESSION------------

Now, my problem:

what is happening here is that the device sends a [0x00][0x0F]xxxxxxxxxxxxxxx where the xxxxxxx is its imei (the data packet). My problem is that there are way too many 3´s on the data packet, so the real valid output is

352848026261954

which you obtain by removing 3´s. my question is: can this behavior come from my code or its part of the protocol? i can correct this programmatically but am wanting to know it there is a way that code can cause these extra 3s.

I'd certainly write some unit tests for that function - it smells fishy, and working with byte[] in Java takes a lot of attention for detail. Or replace with one of the many functions available on the Net (a gazillion answers here: http://stackoverflow.com/questions/332079/in-java-how-do-i-convert-a-byte-array-to-a-string-of-hex-digits-while-keeping-le) — cdegroot, Jul 12 '11 at 10:49

score 3 · Accepted Answer · answered Jul 12 '11 at 10:50

You are looking at the hex of the ascii values which needs to be decoded as numbers. The character '0' as a decimal is 48 or as hex 0x30, up to '9' is 57 as a decimal or 0x39 as hex.

So a sequence of bytes

33 35 32 38 34 38 30 32 36 32 36 31 39 35 34

is

"352848026261954"

as ASCII characters.

I would change your code like this

dataIN.readFully(data); // always read 17 bytes, not less
String text = new String(data, 0, 2, 13); // decodes 8-bit bytes as a String
long number = Long.parseLong(text);

user207421 · Answer 2 · 2011-07-12T10:59:07.523

2

This is ASCII numeric encoding. 0 is being transmitted as '0', which is 0x30. 1 is being transmitted as 0x31. Etc. So your understanding of the data format is incorrect.

edited Jul 12 '11 at 10:59

answered Jul 12 '11 at 10:48

user207421

305,947
44
307
483

My understanding of the data being transmitted is correct. my problem is that i was reading a hex string and not converting it to a number. – sergio Jul 12 '11 at 11:07
@sergio so your understanding of the protocol was *incorrect.* You were expecting a number and you were getting a hex string. Otherwise why the post? – user207421 Jul 12 '11 at 11:15

How to read network stream data in Java (Protocol packets)

2 Answers2