«

Hello

I have code a bit like this:

BufferedReader bis = new BufferedReader(new
InputStreamReader(tserverSocket.getInputStream())) ;

// Here I write some data - getting a response - some lines of text returned

boolean more = true;
while(more)
{
String line = bis.readLine();
if (line == null)
more = false;
else
System.out.println(line);
}

But code never gets out of while loop.

I assumed when there was no more input it would return null, so more would
be set to false and it would exit loop.

I want to test for a carriage return. (I know text is in ASCII format, and
I know end of each line has a carriange return and line feed.

So I tried doing this:

if (line.indexOf("\n") != -1)
{
break;
}

But it didn't seem to find \n . How should I test for a carriage return?

Angus

Angus,

BufferedReader does return null when there is more data to read.
However, when dealing with a socket (based on the "tserverSocket"
variable name), its possible that if the connection is still active
that the empty string might be what is being returned. The
BufferedReader.readLine() method automatically strips off the carriage
return so trying to match based on that will never be true.

For example, if the stream sends "one\ntwo\nthree\n" The first
invocation of readLine() would return "one", etc.

I think I need a little more information about the tserverSocket to
assist more on this.


kavaj

Angus wrote:
> Hello
>
> I have code a bit like this:
>
> BufferedReader bis = new BufferedReader(new
> InputStreamReader(tserverSocket.getInputStream())) ;
>
> // Here I write some data - getting a response - some lines of text returned
>
> boolean more = true;
> while(more)
> {
> String line = bis.readLine();
> if (line == null)
> more = false;
> else
> System.out.println(line);
> }
>
> But code never gets out of while loop.
>
> I assumed when there was no more input it would return null, so more would
> be set to false and it would exit loop.
>
> I want to test for a carriage return. (I know text is in ASCII format, and
> I know end of each line has a carriange return and line feed.
>
> So I tried doing this:
>
> if (line.indexOf("\n") != -1)
> {
> break;
> }
>
> But it didn't seem to find \n . How should I test for a carriage return?
>
> Angus

Angus wrote:
> boolean more = true;
> while(more)
> {
> String line = bis.readLine();
> if (line == null)
> more = false;
> else
> System.out.println(line);
> }
>
> But code never gets out of while loop.
>
> I assumed when there was no more input it would return null, so more would
> be set to false and it would exit loop.

If you want to read one line then use:

String line = bis.readLine();


If you want to read multiple lines then your code
should work even though:

String line;
while((line = bis.readLine()) != null) {
....
}

is the most common way of doing it.

Note that readLine first return null (EOF) when the socket is
closed in the other end.

Arne

On Sat, 21 Oct 2006 16:14:21 +0100, Angus wrote:
> // Here I write some data - getting a response - some lines of text
> // returned
>
> boolean more = true;
> while(more)
> {
> String line = bis.readLine();
> if (line == null)
> more = false;
> else
> System.out.println(line);
> }
>
> But code never gets out of while loop.

That's a complicated way of writing a simple loop. This is the idiom:

String line;
while ((line = bis.readLine()) != null) {
System.out.println(line);
}

> I assumed when there was no more input it would return null, so more
> would be set to false and it would exit loop.

It will, but "no more input" means "end of file". readLine() returns
null and the loop will exit when you reach EOF, i.e. when the remote
*closes* the connection. You won't reach EOF as long as the remote
keeps the connection open.

> I want to test for a carriage return. (I know text is in ASCII
> format, and I know end of each line has a carriange return and line
> feed.

readLine() has already tested for newlines and removed them. Each line
it returns is exactly one whole line.

/gordon

--
[ don't email me support questions or followups ]
g o r d o n + n e w s @ b a l d e r 1 3 . s e

Ah OK.

So what I really want to know is how do I know when server has finished
sending me data?

Eg my socket server sends out 1 to many lines of output. How do I know when
server has finished sending data? Is it possible?

Or does my server need to somehow send some data which indicates sending has
finished?

I have the source code for the server too so I can edit the the way the
server outputs data if necessary.

Angus

"Gordon Beaton" <> wrote in message
news:453a41e0$0$8091$...
> On Sat, 21 Oct 2006 16:14:21 +0100, Angus wrote:
> > // Here I write some data - getting a response - some lines of text
> > // returned
> >
> > boolean more = true;
> > while(more)
> > {
> > String line = bis.readLine();
> > if (line == null)
> > more = false;
> > else
> > System.out.println(line);
> > }
> >
> > But code never gets out of while loop.
>
> That's a complicated way of writing a simple loop. This is the idiom:
>
> String line;
> while ((line = bis.readLine()) != null) {
> System.out.println(line);
> }
>
> > I assumed when there was no more input it would return null, so more
> > would be set to false and it would exit loop.
>
> It will, but "no more input" means "end of file". readLine() returns
> null and the loop will exit when you reach EOF, i.e. when the remote
> *closes* the connection. You won't reach EOF as long as the remote
> keeps the connection open.
>
> > I want to test for a carriage return. (I know text is in ASCII
> > format, and I know end of each line has a carriange return and line
> > feed.
>
> readLine() has already tested for newlines and removed them. Each line
> it returns is exactly one whole line.
>
> /gordon
>
> --
> [ don't email me support questions or followups ]
> g o r d o n + n e w s @ b a l d e r 1 3 . s e

On Sat, 21 Oct 2006 17:30:53 +0100, Angus wrote:
> So what I really want to know is how do I know when server has
> finished sending me data?
>
> Eg my socket server sends out 1 to many lines of output. How do I
> know when server has finished sending data? Is it possible?
>
> Or does my server need to somehow send some data which indicates
> sending has finished?

Yes it's possible, but the solution depends on what happens later.

If you don't need to keep the connection open, then the server can
just close it and readLine() will return null, indicating EOF.

If you need to need continue communicating with the server, then the
server should send information the client can use to determine where
the end of the response is. One way is to precede the response with
the number of lines to expect so the client can count them. Another is
to send an extra, empty line ("") after the response (assuming that
can't occur within the response itself), or to mark the final line of
the response differently from the others in some way.

/gordon

--
[ don't email me support questions or followups ]
g o r d o n + n e w s @ b a l d e r 1 3 . s e

"Angus" <> wrote or quoted in
Message-ID: <ehdhvu$hhf$1$>:

> Ah OK.
>
> So what I really want to know is how do I know when server has finished
> sending me data?
>
> Eg my socket server sends out 1 to many lines of output. How do I know when
> server has finished sending data? Is it possible?
>
> Or does my server need to somehow send some data which indicates sending has
> finished?
>

As I know as,
'null' do not necessarily indicate that server has finished
sending data. 'null' may be returned when unexpected
network error occurs (ex: unexpected connection close).

Therefore, communication protocol must have an ending
indicator.

For example,
With NNTP, a single period (".") on a line indicates the
end of sending data.

With HTTP, an empty line("") indicates it. (Or "Content-Length").

With a server that sends only one line to a client always,
"\r\n" will indicate it.

I think that you have to code a server that send out it.

Gordon Beaton wrote:
> If you don't need to keep the connection open, then the server can
> just close it and readLine() will return null, indicating EOF.
>
With all due respect, I think that the connection should always be
opened and closed by the client: if the server closes the connection you
have no way of telling if the network broke, the server crashed or if it
was an intentional "end of dialog" closure.

> the server should send information the client can use to determine where
> the end of the response is. One way is to precede the response with
> the number of lines to expect so the client can count them. Another is
> to send an extra, empty line ("") after the response (assuming that
> can't occur within the response itself), or to mark the final line of
> the response differently from the others in some way.
>
A better way is to precede each message with its length, which should be
either a binary byte or (better) a fixed length character string, e.g.,

0012Message data

This way the receiver starts with a fixed length read to get the message
data length, translates it into an int and then reads that many bytes to
get the message. If either read gets the wrong number of bytes you know
there's a problem and you can take corrective action.

If both client and server send this type of message both can use the
same error checking and message decoding code with the addition that, if
the server receives a zero length message when its expecting a message
length it knows that the client has closed the connection.

I usually build messages this way, but assemble them from comma
separated fields. If the client always sends messages consisting of a
command and an associated value a message might look like:

0024,STORE,Text to be stored

While the reply from the server might look like

0004,OK,

or

0023,ERROR,The file is full

This format has the double advantage that its easy to decode and is
human-readable when it appears in debugging messages, etc.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |

wrote:
>
> BufferedReader does return null when there is more data to read.
> However, when dealing with a socket (based on the "tserverSocket"
> variable name), its possible that if the connection is still active
> that the empty string might be what is being returned.

This makes no sense. A null will be returned when the other end closes
its socket. Anything else returned, including an empty string, is
returned because the other end wrote it, and for no other reason.

Martin Gregorie wrote:
> With all due respect, I think that the connection should always be
> opened and closed by the client: if the server closes the connection you
> have no way of telling if the network broke, the server crashed or if it
> was an intentional "end of dialog" closure.

Except that an orderly close returns a null via readLine(), or -1 via
read(), or an EOFException via any other method, whereas a disorderly
close throws an IOException, or a SocketException, or possibly just
blocks forever.