In a program, I send some data over a TCP socket (java.net.Socket) to a server, the server does some processing, and then sends a reply back to the client. I know that if I read or write to the socket (on the server's end) after I have lost connection to the client, or vice versa, I will have some socket exception thrown. But what if I lose connection to the client while I am doing the processing on the server. Is an exception thrown right away, or when I attempt to write back to the socket (is the socket on the server side polling the client continuously, or does it only communicate with it when I write to the stream connected to it)? Thanks, John [ July 15, 2002: Message edited by: John Rushington ]
That idea is familiar to me from putting a servlet into an infinite loop and getting annoyed because pressing the stop button in the browser doesn't stop the servlet executing. I think it's because I have a mental picture of server side code being executed by some sort of remote extension of the client thread, whereby if the client thread dies, the server side code immediately stops executing. You won't get the socket exception until you try to write to the closed socket. The system won't tell you that there might be a problem with a socket by interrupting you with a socket exception while you're doing something else. That's not because of anything to do with sockets or TCP, it's because Java exceptions are almost always related to the thing you're doing right now: they're normally not like asynchronous notifications or interrupts. Also, I'm wondering if you're guaranteed to get a socket exception... If you write bytes to a socket output stream and you don't get an exception, does that mean that (i) the bytes have been received and acknowledged by the remote host? (ii) the bytes have been sent out by the TCP implementation of the local operating system?(iii) the bytes have been buffered by the TCP implementation of the local operating system? (iii) the bytes have been buffered by java.net objects in the VM?
Hi , My comments are incorporated: >Also, I'm wondering if you're guaranteed to get a >socket exception... If you write bytes to a socket >output stream and you don't get an exception, does >that mean that (i) the bytes have been received and >acknowledged by the remote host? (ii) the bytes have >been sent out by the TCP implementation of the local >operating system?(iii) the bytes have been buffered >by the TCP implementation of the local operating >system? (iii) the bytes have been buffered by >java.net objects in the VM?
Once u write on a socket, the buffer u had given is written into the kernel buffer and the write call returns immediately. The application will never come to know wheter the data was recvd by the peer. Hence if write doesnt give u any exception then u cannot assume that Ur dat has been recvd and ack by the peer. Thus U r correct when u say > (iii) the bytes have been buffered by the TCP > implementation of the local operating >system?
Now when exactly can write give u a exception I) note the order of operation 1. U connect, connection was successful 2. u write something - get no exception....start doing some work..meanwhile our remote host gets crashed. 3. u write again - no exception..do something again The Operation sys TCP implementaion is trying hard to send data and recv ack from the remote host and it will continue till it timesout or recvs a RST message from the peer. its only now when u try to write the second time, u will receive an exception. Thus if the connection was established and it was working and something happened in between... it is quite possible that the second write tells u abt the broken pipe but is not gauranteed.
Evil is afoot. But this tiny ad is just an ad:
Devious Experiments for a Truly Passive Greenhouse!