• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 470
  • Last Modified:

Having problem decoding UDP data packet from c++ program, which has mixed data types

My program connects to a c++ server, which is sending out a packet in the form of
class udpPacket
{
  double value1;
  double value2;
  double value3;
  double value4;
  double value5;
  double value6;
  char namesBuf [12][32];//12 , 32 character long names
}
The namesBuf is initialized to all zeros and then subsequently filled with variable length names
during program execution, the data ultimately looks something like this
namesBuf[0][0] = M
namesBuf[0][1] = O
namesBuf[0][2]= N
namesBuf[0][3] = D
namesBuf[0][4] = A
namesBuf[0][5] = Y
namesBuf[0][6] =
namesBuf[0][7] =
...
...
...
namesBUf[0][31]=
namesBuf[1][0] = T
namesBuf[1][1] = U
namesBuf[1][2] = E
namesBuf[1][3] = S
namesBuf[1][4] = D
namesBuf[1][5] = A
namesBuf[1][6] = Y
namesBuf[1][7] =
namesBuf[1][8] =
namesBuf[1][9] =
...
...
...
So there are names and end of string values filling the char array

In my java program I read the 6 doubles just fine and the values are correct, but
when I go to read the character portion of the data, i'm unable to decode that properly.
I think the fact that the data was initialized to all zero's before the names are copied
into the buffer is making the data reading difficult, because the zero's signify end of string,
when really there are more strings in the buffer

I'm reading the data like this
ByteArrayInputStream bis = new ByteArrayInputStream(receivePacket.getData());
DataInputStream dis = new DataInputStream(bis);
double firstDouble = dis.readDouble();
double secondDouble = dis.readDouble();
double thirdDouble = dis.readDouble();
double fourthDouble = dis.readDouble();
double fifthDouble = dis.readDouble();
double sixthDouble = dis.readDouble();
//those read fine
public byte [] inBuf;
for(int i=0;i<12;i++)//there can be up to 12, 32 character long names
{
  inBuf = new byte[32];
  dis.read(inBuf);
  String name = new String(inBuf,"UTF-8");
}

I get a garbled mess from the above method for the the inBuf data,
I tried readFully(inBuf); but that just throws an IO exception when gettting to the first zero value field in the buffer

Is there a good way to extract the names from the buffer,  if I could read 32 bytes at a time, ignoring
zero values, that should work, but I don't know how.

I also tried to read a string at a time without any success, throws EOF exception
for(int i=0;i<12;i++)
{
  String name = dis.readUTF();
  dis.skipBytes(32 - name.length());//go to start of next string in buffer
}
0
mitchguy
Asked:
mitchguy
  • 4
  • 4
  • 2
1 Solution
 
CEHJCommented:
You need to know exactly how the strings were written - what's the format?
0
 
mitchguyAuthor Commented:
they are written into the c++ class structure
class udpPacket
{
  double value1;
  double value2;
  double value3;
  double value4;
  double value5;
  double value6;
  char namesBuf [12][32];//12 , 32 character long names
}

Like this
for(int i=0;i<12;i++)
{
  strcpy(namesBuf[i],nameList[i]);
}

nameList is a corba string that I copy into my char buffer
I don't know the length of the strings, other than they will be less than 32 characters
0
 
CEHJCommented:
So they're null-terminated?
0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
mitchguyAuthor Commented:
yes they are null terminated and the entire udpPacket is sent on the c++ side
so there is 432 bytes total
I'm able to read everything with a  c++  test client program, so I know the data is there,
I just cant read it in the right format, with the java program ,The doubles are altered for endianness, but I did not byteswap the char buf, because I thought that endianness only applied to numbers,
however I did try it once on the char array just for kicks, but no help as It shouldn't have been

I tried initializing the c++ namesBuf [ ] to whitespace instead of zeros before copying the
names in, but that had no effect either
0
 
CEHJCommented:
Try reading as bytes up to the null and then create a string from the array as UTF-8 encoded
0
 
objectsCommented:
> String name = new String(inBuf,"UTF-8");

are the characters utf encoded? try it without specifying the encoing

and inspect the value of the buffer to check you are getting expected byte values.

for (int i=0; i<inBuf.length)
{
    System.out.println(inBuf[i]);
}
0
 
CEHJCommented:
Read the lot (all strings) into a buffer (let it be 'byte[] bytes') and please post the output of

System.out.println(new sun.misc.HexDumpEncoder().encode(bytes));
0
 
mitchguyAuthor Commented:
I found the error, I had all of the decoding code in a function, which I passed the Datagram
packet into and had been so focused on the code in the function that I missed step 1. The buffer used
to create the packet before the function call, the buffer was only size 48, the size of the doubles, not
the doubles and the char array, I needed it to be size 432. I will use your code
System.out.println(new sun.misc.HexDumpEncoder().encode(bytes)); in the future I'm sure,
so I will accept that for the solution.
0
 
objectsCommented:
how was that different to what I had already suggested, whether it is hex or decimal would still highlight the problems?

obejcts> and inspect the value of the buffer to check you are getting expected byte values.
0
 
mitchguyAuthor Commented:
>>objects
My problem as I discovered wasn't uncovered by inspecting the buffer, it was an error
I made in specifying the size of the buffer. I had already used your method on my own before ever posting the question.
Thanks for your participation, I know you have provided excellent solutions for my problems in the past, however
in this case I feel CEHJ should receive the credit.
0

Featured Post

Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

  • 4
  • 4
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now