Java TCP Client-send blocked?

I am writing a java TCP client that talks to a C server. I have to alternate sends and receives between the two. Here is my code.

1. The server sends the length of the binary msg(len) to client(java)
2. Client sends an "ok" string
3. Server sen开发者_如何学编程ds the binary and client allocates a byte array of 'len' bytes to recieve it.
4. It again sends back an "ok".

step 1. works. I get "len" value. However the Client gets "send blocked" and the server waits to receive data.

Can anybody take a look.

In the try block I have defined:

            Socket echoSocket = new Socket("192.168.178.20",2400);
            OutputStream os = echoSocket.getOutputStream();       
            InputStream ins = echoSocket.getInputStream();
            BufferedReader br = new BufferedReader(new InputStreamReader(ins));

            String fromPU = null;


            if( (fromPU = br.readLine()) !=  null){
            System.out.println("Pu returns  as="+fromPU);  

            len = Integer.parseInt(fromPU.trim());
            System.out.println("value of len from PU="+len);

            byte[] str = "Ok\n".getBytes();
            os.write(str, 0, str.length);
            os.flush();

            byte[] buffer = new byte[len];
            int bytes;
            StringBuilder curMsg = new StringBuilder();
            bytes =ins.read(buffer);
            System.out.println("bytes="+bytes); 
            curMsg.append(new String(buffer, 0, bytes));            
            System.out.println("ciphertext="+curMsg); 
                    os.write(str, 0, str.length);
            os.flush();
            }

UPDATED:

Here is my code. At the moment, there is no recv or send blocking on either sides. However, both with Buffered Reader and DataInput Stream reader, I am unable to send the ok msg. At the server end, I get a large number of bytes instead of the 2 bytes for ok.

            Socket echoSocket = new Socket("192.168.178.20",2400);
            OutputStream os = echoSocket.getOutputStream();   
            InputStream ins = echoSocket.getInputStream();
            BufferedReader br = new BufferedReader(new InputStreamReader(ins));
            DataInputStream dis = new DataInputStream(ins);
            DataOutputStream dos = new DataOutputStream(os);
            if( (fromPU = dis.readLine()) !=  null){
            //if( (fromPU = br.readLine()) !=  null){
            System.out.println("PU Server returns length as="+fromPU);      
            len = Integer.parseInt(fromPU.trim());
            byte[] str = "Ok".getBytes();
            System.out.println("str.length="+str.length);
            dos.writeInt(str.length);
            if (str.length > 0) {
                    dos.write(str, 0, str.length);
                 System.out.println("sent ok");
            }
            byte[] buffer = new byte[len];
            int bytes;
            StringBuilder curMsg = new StringBuilder();
            bytes =ins.read(buffer);
            System.out.println("bytes="+bytes); 
                curMsg.append(new String(buffer, 0, bytes));            
                System.out.println("binarytext="+curMsg); 

            dos.writeInt(str.length);
            if (str.length > 0) {
                    dos.write(str, 0, str.length);
                 System.out.println("sent ok");
            }

Using a BufferedReader around a stream and then trying to read binary data from the stream is a bad idea. I wouldn't be surprised if the server has actually sent all the data in one go, and the BufferedReader has read the binary data as well as the line that it's returned.

Are you in control of the protocol? If so, I suggest you change it to send the length of data as binary (e.g. a fixed 4 bytes) so that you don't need to work out how to switch between text and binary (which is basically a pain).

If you can't do that, you'll probably need to just read a byte at a time to start with until you see the byte representing \n, then convert what you've read into text, parse it, and then read the rest as a chunk. That's slightly inefficient (reading a byte at a time instead of reading a buffer at a time) but I'd imagine the amount of data being read at that point is pretty small.

Several thoughts:

        len = Integer.parseInt(fromPU.trim());

You should check the given size against a maximum that makes some sense. Your server is unlikely to send a two gigabyte message to the client. (Maybe it will, but there might be a better design. :) You don't typically want to allocate however much memory a remote client asks you to allocate. That's a recipe for easy remote denial of service attacks.

        BufferedReader br = new BufferedReader(new InputStreamReader(ins));
        /* ... */
        bytes =ins.read(buffer);

Maybe your BufferedReader has sucked in too much data? (Does the server wait for the Ok before continuing?) Are you sure that you're allowed to read from the underlying InputStreamReader object after attaching a BufferedReader object?

Note that TCP is free to deliver your data in ten byte chunks over the next two weeks :) -- because encapsulation, differing hardware, and so forth makes it very difficult to tell the size of packets that will eventually be used between two peers, most applications that are looking for a specific amount of data will instead populate their buffers using code somewhat like this (stolen from Advanced Programming in the Unix Environment, an excellent book; pity the code is in C and your code is in Java, but the principle is the same):

ssize_t             /* Read "n" bytes from a descriptor  */
readn(int fd, void *ptr, size_t n)
{
    size_t      nleft;
    ssize_t     nread;

    nleft = n;
    while (nleft > 0) {
        if ((nread = read(fd, ptr, nleft)) < 0) {
            if (nleft == n)
                return(-1); /* error, return -1 */
            else
                break;      /* error, return amount read so far */
        } else if (nread == 0) {
            break;          /* EOF */
        }
        nleft -= nread;
        ptr   += nread;
    }
    return(n - nleft);      /* return >= 0 */
}

The point to take away is that filling your buffer might take one, ten, or one hundred calls to read(), and your code must be resilient against slight changes in network capabilities.