aspose file tools*
The moose likes Sockets and Internet Protocols and the fly likes Catching Socket Exceptions Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Sockets and Internet Protocols
Bookmark "Catching Socket Exceptions" Watch "Catching Socket Exceptions" New topic
Author

Catching Socket Exceptions

John Rushington
Greenhorn

Joined: Jul 01, 2002
Posts: 9
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 ]
Donal Lynch
Greenhorn

Joined: May 02, 2002
Posts: 15
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?
Amit Saini
Greenhorn

Joined: Oct 17, 2000
Posts: 5
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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Catching Socket Exceptions