This content has been marked as final. Show 5 replies
(a) Get rid of the br.ready() test.
(b) Are you reading lines at the other end? because you're not sending lines. readLine() removes the line separator. If the other end is reading lines, it will never get a line separator, so it will never exit from readLine() unless you close the socket.
(c) is 'out' buffered? If so, you need to flush it.
I got the problem solves.
a. I kept the .ready() test. seems that it is not affecting much.
b. i still dont quite get the line separator part, though i fixed the problem by doing a .read(char cbuf, int offset, int len) . From my past assignment experiences, getlines in C and readLines and nextLines in java often creates a null-terminator problem, yet i am not what is the exact mechanism behind it.
c. Nope. i kept it unbuffered and parse it myself; so stay away from the flush problem.
b. i still dont quite get the line separator partIt's simple. readLine() reads until it gets a line terminator, throws it away, and returns. So the readLine() in your client returns the line without the line terminator. write() doesn't add one. So a readLine() at the other end will block forever.
From my past assignment experiences, getlines in C and readLines and nextLines in java often creates a null-terminator problemNo they don't. There is no null-terminator problem in Java.
yet i am not what is the exact mechanism behind it.That's because it doesn't exist in Java.
if i do a
String msg = oldmsg + "\n"; //is "\n" a line separator? in any case i'll assume it is for this scenario
out.write(msg.getBytes() ); should not block the other side right ?
Edited by: J-Ideas on Sep 16, 2010 8:20 PM