Question

I’m receiving byte data from a VNC server, using Real VNC this works in my method/function:

byte[] readBytes = new byte[count];
sock.Receive(readBytes);

Using TigerVNC it doesn’t work, but this does:

byte[] readBytes = new byte[count];      

byte[] aByte = new byte[1];

for (int i = 0; i < count; i++)
{
    sock.Receive(aByte);    
    readBytes[i] = aByte[0];
}                            

I stumbled upon it pretty quickly, as when I used breakpoints the original code came in alright from Tight VNC, without breaking only the first two bytes are received. My socket is blocking and has receive size of 1024. I am however running the server and client locally as I have no other way of testing.

The Question is:

Other than using an extra byte of memory with “aByte” and iterating through X bytes. Is there much of a processing difference than just receiving it direct using Socket.Receive? Bearing in mind I’ll possibly be getting MBs of data at some point.

Further more, this is going to be implemented on Blackberry as a Java app, would the same kind of method have implications processing wise in Java Mobile?

cheers, craig

Answer 1

Neither of these methods is particularly good. What you want to do is keep calling Recv until it either reads all the bytes you want or returns an error. Each time, pass it a pointer just after the bytes you’ve received so far and the number of bytes remaining.

Take a look at the Socket.Receive method on this page. The crux is this (simplified):

public static void Receive(Socket socket, byte[] buffer, int size)
{
 int received = 0;
 do
 {
  try
  {
   received += socket.Receive(buffer, received, size - received, SocketFlags.None);
  }
  catch (SocketException ex)
  {
   throw ex;  // any serious error occurr
  }
 } while (received < size);
}

This way you don’t return too soon, but you don’t read the data byte by byte either.