[ACCEPTED]-What does 'end of stream' mean when working with sockets-network-programming

Yes, you're right - using available() like this is 34 unreliable. Personally I very rarely use 33 available(). If you want to read until you reach the 32 end of the stream (as per the question title), keep 31 calling read() until it returns -1. That's the 30 easy bit. The hard bit is if you don't want 29 the end of the stream, but the end of "what 28 the server wants to send you at the moment."

As 27 the others have said, if you need to have 26 a conversation over a socket, you must make 25 the protocol explain where the data finishes. Personally 24 I prefer the "length prefix" solution to 23 the "end of message token" solution where 22 it's possible - it generally makes the reading 21 code a lot simpler. However, it can make 20 the writing code harder, as you need to work out 19 the length before you send anything. This 18 is a pain if you could be sending a lot 17 of data.

Of course, you can mix and match 16 solutions - in particular, if your protocol 15 deals with both text and binary data, I 14 would strongly recommend length-prefixing strings 13 rather than null-terminating them (or anything 12 similar). Decoding string data tends to 11 be a lot easier if you can pass the decoder 10 a complete array of bytes and just get a 9 string back - you don't need to worry about 8 reading to half way through a character, for 7 example. You could use this as part of your 6 protocol but still have overall "records" (or 5 whatever you're transmitting) with an "end 4 of data" record to let the reader process 3 the data and respond.

Of course, all of this 2 protocol design stuff is moot if you're 1 not in control of the protocol :(

I think this is the task more of a protocol, assuming 12 that you are the man who writes both the 11 transmitting and receiving sides of application. For 10 example you could implement some simple 9 logic protocol and divide you data into 8 packets. Then divide packets into two parts: the 7 head and the body. And then to say that 6 your head consists of a predefined starting 5 sequence and contains number of bytes in 4 the body. Of forget about starting sequence 3 and simpy transfer number of bytes in the 2 bofy as a first byte of the packet. Then 1 you've could solve you problem.

As some ppl already said you can't avoid 4 some kind of protocol for communication. It 3 should look like this for example:

On the 2 server side you have:

 void sendMSG(PrintWriter out){
    try {
        //just for example..
        Process p = Runtime.getRuntime().exec("cmd /c dir C:");
        BufferedReader br = new BufferedReader(new InputStreamReader(
            p.getInputStream()));

        //and then send all this crap to the client
        String s = "";
        while ((s = br.readLine()) != null) {
          out.println("MSG");
          out.println(s);
        }
      } catch (Exception e) {
        System.out.println("Command incorrect!");
      }
      out.println("END");
}
//You are not supposed to close the stream or the socket, because you might want to send smth else later..

On the client side 1 you have:

void recieveMSG(BufferedReader in) {
    try {
      while (in.readLine().equals("MSG")) {
        System.out.println(in.readLine());
      }
    } catch (IOException e) {
      System.out.println("Connection closed!");
    }
  }

as Nikita said this is more of task of protocol. Either 5 you can go by header and body approach or 4 you can send a special character or symbol 3 for end of stream to break processing loop. Something 2 like if you send say '[[END]]' on socket 1 to denote end of stream.