CODEWITHSUNDEEP
javasockets
Ingo McLean
Ingo McLean

Reputation: 19

Failure in writing to a Java socket more then once

In my Java application I am using 2 network connections to a webserver. I ask for a range of data for a file from each interface with a GET message and when I get the data, I calc how much time it took and the bps for each link.

This part works fine.

(I haven't closed the sockets yet)

I determine which link is faster then "attempt" to send another HTTP GET request for the rest of the file on the faster link. This is where my problem is, The 2nd cOut.write(GET) doesn't send anything and hence I get no data back.

Do I have to close the socket and re-establish my connection before I can write to it again?

edit

OK to answer some Qs: Yes TCP

The following code (used on the low speed link) is used first to grab the first block of data using the GET request:

GET /test-downloads/10mb.txt HTTP/1.1
HOST: www.cse.usf.edu
Range: bytes=0-999999
Connection: Close

Is the Connection: Close what is doing it? as when I use Keep-Alive I get a 5sec delay and still do not send/receive data on a subsequent write/read.

// This try block has another fo rthe other link but uses [1]
try {
  skSocket[0] = new Socket( ipServer, 80, InetAddress.getByName(ipLowLink), 0 );
  skSocket[0].setTcpNoDelay(true);
  skSocket[0].setKeepAlive(true);
  cOut[0] = new PrintWriter(skSocket[0].getOutputStream(),true);
  cIn[0] = new InputStreamReader(skSocket[0].getInputStream());
    } catch (IOException e) {
        // TODO Auto-generated catch block
        e.printStackTrace();
    }

    /* -----------------------------------
       the following code is what is called 
       once for each link (ie cOut[0], cOut [1])
       then after determining which has the better bps
       (using a GET to grab the rest of the file)
       this code is repeated on the designated link
       ----------------------------------- */

    // Make GET header
    GET.append(o.strGetRange(ipServer, File, startRange, endRange-1));
    // send GET for a specific range of data
    cOut[0].print(GET);
    cOut[0].flush();
    
    try {

        char[] buffer = new char[4*1024];
        int n = 0;
        while (n >= 0) {
            try {
                n = cIn[0].read(buffer, 0, buffer.length);
            } catch (IOException e) {
                e.printStackTrace();
            }
            if (n > 0) {
                raw[0].append(buffer, 0, n); // raw is a stringBuffer
            }
        }
    }
    finally {
        //if (b != null) b.close();
        
}

I use the same code as above for my 2nd link (just shift the start/end range over a block) and after I determine the bps, I request the remaining data on the best link (don't worry about how big the file is, etc, I have all that logic done and not the point of the problem)

Now for my subsequent request for the rest of the data, I use the same code as above minus the socket/in/out creation. But the write doesn't send anything. (I hav done the socket check isClosed(), isConnected(), isBound(), isInputShutdown(), isOutboundShutdown(), and all prove that the socket is still open/useable.

Upvotes: 1

Views: 337

Answers (1)

Crollster
Crollster

Reputation: 2771

According to the HTTP 1.1 spec, section 8:

An HTTP/1.1 client MAY expect a connection to remain open, but would decide to keep it open based on whether the response from a server contains a Connection header with the connection-token close. In case the client does not want to maintain a connection for more than that request, it SHOULD send a Connection header including the connection-token close.

  1. So, you should ensure that you are using HTTP 1.1, and if you are, you should also check that your webserver supports persistent connections (it probably does). However, bear in mind that the spec says SHOULD and not MUST and so this functionality could be considered optional for some servers.

  2. As per the excerpt above, check for a connection header with the connection-close token.

Without a SSCCE, it's going to be difficult to give any concrete recommendations.

Upvotes: 3

Related Questions