I don't know about the first problem, but I think your second problem is due to this:
} while (byteIn != -1 && is.ready());
If the sender is not quick enough sending data, the receiver may call is.ready()
before the next packet has been sent. This will cause is.ready()
to return false
which will cause the loop to stop.
The minimal fix is to change that line to:
} while (byteIn != -1);
EDIT
But really, you need to rewrite the method along the lines of @simonlord's answer. It is a really bad idea to read an unbuffered stream one byte at a time. You end up doing a system call for each read
call, which is horribly inefficient.
EDIT 2
The reason that removing is.ready()
caused delays is because you were not paying proper attention to the HTTP protocol. The problem was the HttpClient code was keeping the request side of the TCP connection open to allow the connection to be reused. The simple (but sub-optimal) solution would have been to configure HttpClient to close the request side of the connection. Your code would have then seen the EOF straight away. What you actually did was another solution.
Frankly you should not even be trying to implement the server-side HTTP protocol unless you are prepared to understand the entire HTTP specification in depth and implement it faithfully. The chances are that an existing implementation will be faster and more reliable than anything that you can knock together. The problem with implementing a subset of the spec is that your server may need to talk to a real browser that uses parts of the spec that you haven't bothered to implement / test.