Question

First off, if you helped me solve my problem with reading an undefined length HTTP response, I'd like to thank you. I took your advice and switched from HTTP responses to raw Java sockets. But I'm having a little problem with this too.

The nature of a push server is to push things to the client as they are recieved (in my case the system uses a file labeled with the device id.) The problem is that with the KnockKnock example on the Java Tutorials, their code:

while ((inputLine = in.readLine()) != null) {...   

Waits for the client to send something before sending something itself. So I decided to use:

while (true) {
    if ((inputLine=in.readLine())==null) inputLine="";
    ...

If any of the input interpereters get this empty string, then they won't do anything.

My Question essentially is which one is better and, if it's the first one, how can I keep checking the file to send out what is required without spawning a thread?

Was it helpful?

Solution

The first one implements the protocol imagined for the KnockKnock example: a client sends "KnockKnock", and the server answers.

The second one doesn't make much sense. If the client has a an output stream open with the server, and the server calls readLine(), it means that it's waiting for a line to come from the client. And the call will block until the client sends a line, or closes the socket.

It seems you don't expect any input from the client. In this case, well, don't open an input stream at all, and don't call readLine() on the input stream (obviously). Send what you need to send to the client directly, as soon as you want to send it.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top