private void gross_read (){ ... System.out.println("Connect to ip:" +ip+" port:"+port); s = new Socket (ip, port); // читаем ответ buf = new byte[128*2048]; r = s.getInputStream().read(buf); String data = new String(buf, 0, r); // в коде это строка 61 System.out.println("Принято от сервера сообщение"); ... } public void run(){ while (flag){ try{ gross_read(); ... }catch(...){ ... } } 

The server sends data without ceasing. The client gets everything beautifully displayed. But if the stream in which the socket is listening is interrupted, and again I try to receive data from the server, I always get that the stream is empty. Throws away the exemptone like this:

Exception in thread "Thread-6" java.lang.StringIndexOutOfBoundsException: String index out of range: -1 at java.lang.String.checkBounds(Unknown Source) at java.lang.String.<init>(Unknown Source) at vogon_ves.GrossVis.gross_read(GrossVis.java:61) at vogon_ves.GrossVis.run(GrossVis.java:134)

What is wrong with me?


Thank you for the answers. but still the problem is relevant for me. The bottom line is graying. A server is a device, a scale. In the documentation for them, I found that they send the message to the specified port with the weight value at the specified port number xxxxx. What is the value I need to get all the time, it was clear that the dynamics of the appearance of weight on the platform. That's why I re-create a connection to the server. So I need to constantly receive messages. And this situation develops, if I do not receive a message for a short period of time, about two minutes, I can not always read the stream. And if the interval between receiving messages seconds 20 then everything is fine. about the buffer, I was initially confused by the error of going beyond the array, so I did it for more. then I found a tutorial that I read that meton gives me for ekshepshon, and I understood that it was not about the size of the buffer, but I did not reduce it back.

  • -1 in the incoming stream means that the data transfer has ended. or nonexistent because no one recorded anything there. your code makes an infinite number of connections to the server (maybe you wanted to do only one?) and is trying to consider a limited amount of data equal to the buffer size. usually, read reads are done in a cycle (example with character-by-character read): int a; while (-1! = (ch = s.getInputStream (). read ())) {...} if it is still correct logic, 128 * 2048 byte is the amount of data you need, then there may be a problem with the server implementation - jmu
  • s.close (); But it probably will not save. I think the logic is wrong. - avp

2 answers 2

It's not entirely clear what you ask.

You mean, why an exception? You yourself said that the flow is empty. Therefore, InputStream.read() returns -1 - this is an invalid index to index the array. In JavaDoc, the String constructor (byte [], int, int) indicates that it throws an IndexOutOfBoundsException if the indices are incorrect (more precisely, StringIndexOutOfBoundsException , but this is a subclass, so technically true).

  • so the interesting thing is, the stream cannot be empty, as the device always sends messages. And for some reason, the client has a stream empty? .. what can it be connected with? - Sashke
  • So that the device does not send messages. Or you are not reading from there. - cy6erGn0m

You have it all wrong. The buffer is unreasonably large, and the result of reading from the socket is not checked. There is also no checking for fragmentation. Theoretically, a read can at any moment break off the lock and return you 0. But this does not mean that something has been read. And your code will work as if reading happened. And yes, the index -1 is obtained because r = -1 if the connection is closed.

  • Docks for the InputStream.read() method (for versions that return the number of bytes read) state that 0 will return only if the size of the array is 0. If a read error occurs (except for the end of the stream), an exception should be thrown; otherwise, the method is blocked until at least one byte is read. Did you have other situations? - yozh
  • It is known that the read method will eventually call the native read method. And he, in turn, can read zero bytes in some cases that are not an error. In addition, zero reading is a special case of incomplete reading, which is exactly possible. - cy6erGn0m