Can HTTP detect network failure?
I got two class httpServer and httpClient. Client sends request and gets response from server over HTTP. Now if I close or physically detach the server, after a request from a client and before the response sends back to client, how does my client can come to know a network failure?
Does HTTP support any network failure detection mechanism for the clients? I want to detect network failure from my client side in HTTP.
Mohammed Jubaer Arif.
[461 byte] By [
Jubaera] at [2007-10-3 8:16:17]
Mohammed,a SocketException will be trown in your client application, but I suggest a look in this thread for extra details on error handling : http://forum.java.sun.com/thread.jspa?threadID=539297
Hi there thanks.
Yes I tried my client and server. It is giving me an error in the client side, immediately I am stopping the server. But I think it is more for my programming then for HTTP. I am wondering how can HTTP knows about network failure, is it java.net doing it for me? I haven't done any extra programming, very simple request-response client-server.
HTTP is an application layer protocol and I guess this network failure can be tracked in the network and transport layer. Even then if java.net is doing it for me, aren't our usage of java.net remains in application layer. Think about a browser requesting a page and in the middle the network failed, it gives us a error message, to my understanding here browser have some programming logic than HTTP doing it itself.
Sorry, for my inexperienced comments, most of them are my guess. Looking forward to hear your expert view.
Mohammed Jubaer Arif
Yes,
this kind of specific error handling need to be programmed in your application, depending of status reported by HTTP or TCP (java.net.Socket).
Remember that TCP was designed long time ago to provide a feature called "full reconnect".
This "full reconnect" feature means that if a network connection was disconnected the protocol would attempt to find another route for the data.
It causes TCP to be reluctant to inform a user that the connection has been lost.
If you try to send on a lost connection, you will get a exception (SocketException) informing that connection has been terminated.
HTTP Status codes :
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
(Assuming TCP/IP.) If you unplug the server's network connector after a HTTP request has been sent but a reply hasn't, the connection will hang. The client won't notice it.
This is because TCP/IP sends no packets when neither end writes nothing. An unplugged connector looks exactly like a server that is taking a long time to answer: no packets are sent in either direction.
You could build a timeout scheme in the client if really necessary. I have done that using a thread that goes through all open HTTP streams and closes those that have been open longer than a configured time.
There is also TCP/IP keepalive but the timeout is long (something like two hours usually) and it may be impossible to turn it on if you use something like URLConnection.
There is also a read timeout in HttpURLConnection since 1.5.
ejpa at 2007-7-15 3:21:25 >
What was the specific problem?
You said it could be traced down to the transport/network layer, and that it did not appear to be an application layer issue; but what was the specific problem you were seeing?
Is it just more of a question as to error-notification mechanics? In which case, the others have given a nicely presented answer.
Hi there, thanks to all
Ok, here I am revealing the problem again. I just got two very simple java classes. One is listening to a HTTP port and the other one is sending a HTTP request to that listening port. Now, let me put you a situation 揳fter a HTTP request has been sent but a reply hasn't come back from the HTTP server? in this situation the connection broke down, don抰 you think the connection will hang? The client won't notice it. I got this impression from our previous discussion.
But with extensive programming you can trace that the connection failed. But I was expecting HTTP itself will let my client side application know that the connection has failed.
Mohammed Jubaer Arif
The HTTP Specification (RFC 2616) does not have error-detection built-in. That's why it lies on top of a reliable transport protocol - such as TCP.
HTTP basically stops working when the underlying connection stops working (hangs, too many errors for retransmission, etc).
Think of this, if you had a friend across a bridge and you delievered letters to him personally, and one day the bridge breaks and you can't get across - how do you think you are going to tell your friend that the bridge is broken? Guess what? YOU dont.
Thanks Everyone!Mohammed Jubaer Arif
