InputStream .read()

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • hsriat
    Recognized Expert Top Contributor
    • Jan 2008
    • 1653

    InputStream .read()

    Code:
        public String receive() {
            InputStream is;
            try {
                is = socket.getInputStream();
            } catch (IOException e) {
                e.printStackTrace();
                return null;
            }
            String result = new String();
            int c;
            while (true) {
                try {
                    c = is.read(); //problem
                    if (c == -1) {
                        return result;
                    }
                }
                catch (IOException e) {
                    return result;
                }
                //System.out.print((char)c);
                result += (char)c;
            }
        }
    The purpose of the code is to read bytes from the TCP socket.
    is.read() is supposed to give IOException when the stream ends. But its not throwing exception, instead the program keeps running and has to be stopped.

    Anybody able to locate the mistake in the code?

    I think mainly the problem is with reading end of the stream.

    Thanks :)
  • JosAH
    Recognized Expert MVP
    • Mar 2007
    • 11453

    #2
    If the other side of your socket doesn't explicitly close its Stream, your side of the socket will never receive an end of file condition, i.e. it simply waits for more bytes to arrive over the wire.

    kind regards,

    Jos

    Comment

    • hsriat
      Recognized Expert Top Contributor
      • Jan 2008
      • 1653

      #3
      Thanks for the reply Jos. Is there any why, any timer or something that I can use to break the loop after say 10 seconds even if it does not return eof condition?

      Comment

      • JosAH
        Recognized Expert MVP
        • Mar 2007
        • 11453

        #4
        Originally posted by hsriat
        Thanks for the reply Jos. Is there any why, any timer or something that I can use to break the loop after say 10 seconds even if it does not return eof condition?
        You have to use the 'nio' package for that because an InputStream.rea d() call blocks until the bytes are read. Why don't you make your server side send the number of bytes before it sends them over the wire? That way your client side knows how many bytes to expect in total.

        kind regards,

        Jos

        Comment

        • hsriat
          Recognized Expert Top Contributor
          • Jan 2008
          • 1653

          #5
          Thanks for the reply Jos.
          Actually, there's no server on the other end. Its a hardware device with ethernet port which intracts through a set of AT commands. It replys back, but does not give eof. So after info is recieved, read() function gets blocked.
          I used socket.setSoTim eout, and it works, but this is not how I want it to be implimented.

          Can you please through some light how to use nio package?

          Comment

          • JosAH
            Recognized Expert MVP
            • Mar 2007
            • 11453

            #6
            Originally posted by hsriat
            Thanks for the reply Jos.
            Actually, there's no server on the other end. Its a hardware device with ethernet port which intracts through a set of AT commands. It replys back, but does not give eof. So after info is recieved, read() function gets blocked.
            I used socket.setSoTim eout, and it works, but this is not how I want it to be implimented.

            Can you please through some light how to use nio package?
            Well, there's a link to the API docs in the first article of this forum section. Some of the documentation has links to the tutorials but why don't you parse the input content and figure out when the device has sent what it had to send?

            kind regards,

            Jos

            Comment

            • hsriat
              Recognized Expert Top Contributor
              • Jan 2008
              • 1653

              #7
              Thanks for the reply Jos. I think I would have to use socket.setsotim out as a solution. Will keep thinking for some other alternative too.

              Regards

              Comment

              Working...