A little byte[] problem

Question

Hi,
I'm facing an unusual problem with creating an array of byte arrays, ie byte[][].
Below is my test code to create this array and read it back. For some reason this is not working. I'll definitely use some knowledge here. Thanks
import java.io.*;
public class Test {
   static byte[][] testbyte = new byte[10][3];
   public static void main(String[] args) {
           ByteArrayOutputStream bout = new ByteArrayOutputStream();
           DataOutputStream dout = new DataOutputStream(bout);
           try {
             for(int m=0;m<3;m++){
               for (int i = 0; i < 10; i++) {
                 dout.writeInt(i*m);
               testbyte[m]=bout.toByteArray();
          for(int index=0;index<3;index++){
            ByteArrayInputStream bin = new  ByteArrayInputStream(testbyte[index]);
            DataInputStream din = new DataInputStream(bin);
            int m = 0;
            while (m < 10) {
               System.out.println(din.readInt());
                m++;
       catch (IOException ex) {
       System.out.println(ex);
}

Answer 1

Actually I send one row of data at a time - thatis
ony 8bytes * 4 = 32 bytes. If you are only send 4 doubles at a time, do you
need to keep all the previous values.
Sending 32 bytes every 10 ms should not be a
problem.
To do this I use DatagramPacket with an offset onthe byte array which
increments by 32 and a length of 32 bytes. If the byte array only contained the data you need to
send this would much simpler.
Note, toByteArray() creates a new byteArray copy of
the data in the ByteArrayOutputStream so it could be
copying around alot of data you don't need.I call toByteArray() only once. After the array is created I do something like DatagramPacket packet = new DatagramPacket(myByteArray,offset,length,address,port)
I'll try tcp as well though I anticipate the speedwill be much lower.
If you keep the socket connection open, then the
speed will be the same, except it will also be much
more reliable. Only the connection latency is slower.
However on a LAN this should less than 0.3 ms once
off.I'll definitely try this. Thanks for the headsup on the reason for the tcp latency. I though each send-receive transaction had to be ack'ed.