Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
Networking<br />
in a read.<br />
Is there a thread function I could use? I tried use BufferedReader.ready() to make my read not<br />
blocking<br />
(BufferedReader.ready() returns true only if the the stream is readable otherwise loop so there<br />
is no actual blocking) but my problem with that was that BufferedReader.ready() doesn't throw<br />
an exception if the other side disconnects so I'm left looping infinitely. I'm really stuck here so<br />
if anyone can give me a strategy (I don't need it spelled out to me just general "I used this<br />
function type help) I'd really appreciate it.<br />
Answer 1: I've found the only way to unblock a (Socket) read-blocking thread is to close() the<br />
socket from another thread. That'll throw an IOException in the read() call.<br />
--<br />
Michiel<br />
Answer 2: Another method that seems to work is to set a socket timeout to something<br />
moderately short (like 10 seconds). The blocked read will throw an exception when the<br />
timeout occurs. Then the thread can inspect the state of a variable (set by another thread<br />
calling an appropriate method) to see if it should terminate.<br />
This approach also makes it trivial to implement a longer inactivity timeout if desired and gives<br />
the network thread an opportunity to do some maintenance work if it wants.<br />
--<br />
Peter<br />
Q: I get the impression that only read operations from a Sockets InputStream throw an<br />
Exception if the opposite Socket has closed the socket. Writing to the Socket's outputStream<br />
works fine...<br />
Is there a way to detect if what I write into a Socket's outputstream is actually still being<br />
received by the other side?<br />
Or will I have to check that I actually get a response via the InputStream, and if not, try to open<br />
a new Socket and resend the request again?<br />
Answer: You can try calling flush() after writing the output, but there's no guarantee that you'll<br />
get an immediate exception. The underlying TCP/IP software may go through timeout and<br />
retry logic before giving up.<br />
That's probably why you'll usually find out about a broken socket when waiting to read. You<br />
should rewrite client so that it sends a request and waits for a response. If it doesn't get a<br />
response, it should try to make a new connection and do the request/response thing again.<br />
If it doesn't work the second time, it should give up for the time being. Perhaps it really makes<br />
sense that one has to verify 'by hand' that requests go through.<br />
--<br />
Duane Morse<br />
Q: ... I imagine, I'll have to cut my file into small datagrams.<br />
I just made a little chat program (client and server) and I would like to add the possibility to<br />
transfer files.<br />
The client and the server are communicating with TCP/IP using a socket.<br />
I imagine, I'll have to cut my file into small datagrams. Is it necessary ? Has someone an idea<br />
or a link to source code of such a function ??<br />
Answer: No. If you were using UDP/IP (DatagramSocket and friends) then it would need to be<br />
split up. The point of TCP is to avoid this need. Simple send the entire file in a stream.<br />
file:///F|/350_t/350_tips/networking.htm (4 of 5) [2002-02-27 21:18:49]
Change language