byte to integer conversion - client server programming

byte to integer conversion - client server programming

• guitarist

  Despite your earlier comments about network order not helping it sure sounds like you are being bitten by a byte order problem somehow.

  The Intel architecture (and Windows running on that architecture) is little-endian meaning the least significant byte is stored first. The Java virtual machine is big-endian meaning the most significant byte is stored first (even when the JVM is running on Intel).

  You can read about endianness here: http://en.wikipedia.org/wiki/Endian

  Compare the output of these two pieces of code

  Int32 foo = 21; byte[] ba = BitConverter.GetBytes(foo); Console.WriteLine("0x{0:X2} 0x{1:X2} 0x{2:X2} 0x{3:X2}", ba[0], ba[1], ba[2], ba[3]); // output is 0x15 0x00 0x00 0x00

  int foo =21; ByteBufer b = ByteBuffer.allocate(4); b.putInt (foo); byte[] ba = b.array(); // print contents of ba in hex // output is 0x00 0x00 0x00 0x15

  As you can see, C# and Java store the bytes of their integers in different order. If you take the bytes of one, and then try to turn them back into an integer in the other you'll get different results.

  For example, the C# value 21 (= 0x15000000) = the Java value 352321536.

  
  

• Guillermina Feliciano

  SOLVED...!!!!

   

  MANY MANY MANY THANkS.....

   heres my solution...

  when i read it....

   

  Byte[] oneByte = new Byte[1];

  Byte[] bytes = new Byte[4];

  for(int i =0; i<4 ;i++){

  while (stream.DataAvailable == false)

  {

  try

  {

  Thread.Sleep(5);

  }

  catch(Exception){}

  }

  stream.Read(oneByte,0,oneByte.Length);

  bytes[ i] = oneByte[0];

  }

   

   

  
  
  

• Rahil Bukhari

  I think i understand your problem, you are assuming that you are sending messages back in forth every time you call send on a socket which is not quite what happens you need to assume that the data is in a stream which means that it doesn't start and stop every time you call the send function. All of the bytes you are sending, the interger and the buffer get put together and arrive in order still put together. so your messages are indistinguishable and all you have is a lot of bytes. do something like this:
  int messageSize;
  loop{ //until termination condition read
  messageSize= ipaddress.netwroktohostorder(firstFourBytes)
  //add message size bytes to ouput is that many are available
  //if not output them and wait for the rest then read the next integer
  //and keep doing this
  .
  .
  ..
  
  btw you should really be doing this asynchronously, maybe I'll make an example tomrrow if you don't have a deadline on this.
  
  
  

• TheGeoff

  You're right :) sleeping a thread is not the right way to go, and once your client and server are not on the same machine or network it is not going to work like it has been. Instead you should be sending some kind of preamble with your messages so you always know the start of a new message. In that preamble you should include the size of the next buffer's worth of the file that way the reciever knows that the next x bytes are part of this message.
  so it will look like this
  [preamble][length][ length amount of bytes][preamble][length] [length amount of bytes ]....
  TCP is error correcting so you can probably drop the preamble if you like, but if you use UDP you will need. If you use it, you will also have to make sure that it doesn't appear in your buffer...
  and if you use UDP your also going to have to put the position of these bytes in the message because you can recieve packets out of order...
  
  hope this gives you the general idea :)
  
  ~Justin_H
  
  
  

• remisp

  Sounds like you've forgoten to put the int in network order and then change back to host order.
  
  System.Net.IPAddress.HostToNetworkOrder( IntegerToSend) // no idea where this is in java libraries (but it is somewhere)
  
  int recieved= System.Net.IPAddress.NetworkToHostOrder(intRecieved);
  
  
  

• Junaid

  I have check both the client and server....the client is always sending out the correct number..
  and as for the server, sometimes it manages to get the correct value, while sometimes it doesn't...
  
  
  
  
  

• bushranger

  I guess i know where is the prob, but not very sure about it.
  
  I mentioned this problem only happen 'sometimes'. And it happens more frequent when I use a larger buffer, and less when smaller buffer. And I also mentioned i use a loop to read some files. here's my explaination,
  
  In the client...
  the buffer is being filled up, and being send to the channel, then the next loop will perform the same thing again, WITHOUT any delay, until the whole file has been read.
  
  And in my server...
  I will keep reading the channel buffer in a loop until I read a termination condition.
  
  The problem is that the server will finish reading the first transmission, and with no delay, it loops to read the next buffer transmitted. At this point,  MAYBE the client has not yet ready finish sending the next buffer, and thus I am reading some faulty byte....
  My solution is that I let the server sleep for a few milisecond(50) before it reads the nect buffer....and it works so far ....without bad data being read...
  
  It sounds weird to me, 'coz i have not much experience in client server programming. But can some one tell me if my assumption on this is correct
  
  
  
  
  

• Christian J&amp;#248;rgensen

  Thanks...that will be very helpful.....
  ya..thats about what I am doing and facing....
  
  
  
  loop{ //until termination condition read
  messageSize= ipaddress.netwroktohostorder(firstFourBytes)
  //add message size bytes to ouput if that many are available
  //if not output them and wait for the rest then read the next integer
  //and keep doing this
  
  How do I know "if that many are available " ..
  
  Thanks.....hopefully answer to this question will be the last answer I need.....
  
  
  
  

• Brutes

  Will definitely go try this idea...
  
  thanks....
  

   

  Hmm...seems like that's not the case....

  
  
  

• harish1981

  Thanks for the suggestion.
  
  Actually that's what I am doing....client will send 4 bytes of int first telling server the size of next buffer to be arrived.....and server will read 4 bytes first, then get ready with a buffer with the size of that int....
  
  But just like I mentioned, this problem only occurs when I enter a loop that sends and receive files....
  
  And after days of flipping through these forums, I believe the answer reply on this post (http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=64480&SiteID=1) is explaining what I am facing....
  
  So, i believe this is a server problem, that I have to find a way to read only when the buffer is completely arrived. Question is, how can I make sure about that other than using sleep
  
  I tried to use
  NetworkStream stream;
  
  loop{ //until termination condition read
  while(stream.DataAvailable == false)
  {
  Thread.Sleep(5);
  }
  .
  .
  .
  ..
  // Start reading 4 bytes of integer here
  // then read the bytes with length of the integer
  .
  .
  .
  .
  }
  But Didn't work...
  
  btw, what is UDP ....:)
  
  
  

• Xuefeng Cao

  
  Basically I am actually sending a large file from client to server. And I use a buffer to send the file. So I use a buffer of lets say 1024 bytes to send the file in a loop until the file is sent. In the loop, I also send an integer value with 4 Bytes.
  
  I noticed that when I set the buffer size for sending file in a larger value, the 4 bytes integer is more likely to be received as unreasonable large number, sometimes negetive value. And when I set it to a smaller value(e.g 128 bytes), the 4 bytes integer is less likely to being interpreted as bad numbers.....
  
  Any one knows why
  
  
  

• Dave Wu

  And if my assumption is correct, may i know how can I speed up the transmission, 'coz you can imagine when I am sending a 300MB files....and with my Thread.sleep(50) function....and with buffer size of 1024......wow....
  
  
  
• byte to integer conversion - client server programming