Suggestion: Check connection between Client/HTTP Web Server

Question

0.00/5 (No votes)

See more:

Hi,
i'm trying to write a little app that can continuously check connection between a PC on which it's running on, and and HTTP web server.
So i have a PC Running Windows and a Web Server on the same LAN and i need to check if the PC can reach the web server: i just need to say that the web server is still alive.
The main issue is that i don't know what's the best way to do that. Since i'm on a cabled and small LAN, i don't have issue regarding packet loss but an affordable method is what i'm looking for.
So i thought those solutions

1. Use ICMP. Periodically send a "ECHO REQUEST" and wait for the reply. If i don't get a reply in time, i assume that it was shut down.

2. Use a Socket TCP. I can put a connect(..) and close (...) in a loop. When the socket return an error after the connect, i assume that it was shut down.

3. Use a socket TCP. I can send a message trough the send and wait for the response. If i don't get a message, i assume it was shut down.

In the 1st case, i really fear a situation in which an eventual temporary congestion would cause a packet loss with a consequence assumption that the web server is down. I don't have a clue how to get a control there.
In the 2nd, i don't know if it's sufficient to assume that the server is down nor it's safe and correct to put connect and close in a loop cause i have also to include the socket initialization in the loop.
In the 3rd, i can encounter some limitation due to the specific HTTP web server running on the host (for example i can't get a reply after 18 tryies in 3 seconds).

I need a solution that is reliable (it must not say that the web server is no more reachable, when it's not) and speedy (i want to detect when the web server is disconnected after less than 1/2 seconds). I don't care about lan traffic.
It would be really appreciated if someone can help me.
Thanks for your time.

Posted 25-Sep-11 14:05pm

AlessandroIT

Add a Solution

2 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Mohibur Rashid · Answer 1 · 2011-09-25T14:55:00

Solution 1

Just sent http server a header request,

thorough out the process, you will know two status,
1. If your machine is alive??
2. If your server is alive??

And Also use
http1.1 as protocol version. And also make sure keep-alive paramter, to see the detail go to the link[^]

Posted 25-Sep-11 14:55pm

Mohibur Rashid

Updated 25-Sep-11 16:47pm

v2

Comments

AlessandroIT 26-Sep-11 3:56am

So you think that i should send a HEAD request trough a send message.

send(socket,"Head ..",..)
The send is non-blocking: if the server can't receive the message cause it was shut down, i would never know trough a send.
And if the send is succesfull, how do i understand that the server is alive? Should i parse the entire response trough a receive or just verify that i=receive(....) , i!=0 ?
I'll take a look at the link you posted.
Thanks!

Mohibur Rashid 26-Sep-11 4:38am

IF you send head request after that the server is gone... you would know that the server is gone because next socket operation will fail. and receive the entire head but parse only first line, you will know a lot, and in head request you wont receive any data body

Emilio Garavaglia · Answer 2 · 2011-09-25T21:07:00

The best way is to ask an HTTP get for a test page. This way you are sure that the entire chain actually works.

ICMP echo (aka ping) is not reliable: some networks may filter them, and some server can "not respond" to them because of the wish of their managers. (I believe this is a misunderstood concept of security, but there it is)

A TCP socket to whatever port different then the one used by the HTTP daemon demonstrate that the operating system and the daemon responding to your socket is alive, but the HTTP daemon can be shut-down or crashed and you'll never know. Not to mention that a firewall may filter your socket being something different an unexpected for an HTTP server!

For the last part of your question, sorry but you're asking something an IP network cannot grant: IP is connectioless, TCP is connection oriented, and HTTP is stateless. The may be dozens of routers between you and the server, and if something is changing in the network, the network routing protocols have to find a way to take you to the destination on another path. Depending on how many parties are involved, this process can take seconds (TCP typically waits an acknowledge for 1/2 second than it retries after 1.5, 3, 4.5, 15 seconds bfore reporting a socket failure.) In all this time the server may be perfectly connected, working and listening. Simply the network is changing its shape.
There is no way you can check for somebody else physical connection in an IP network. Simply that doesn't leave at your side.

1/2 of a second is simply too few -for how TCP/IP works- to take whatever decision about a server status, and also, from a client pherpective, the only thing you can assume is that the server is unreachable, not that it is "disconnected". This is an event that only the server itself can know.

Unless (but you didn't mention) both client and server are sitting on a same LAN with no devices performing whatever kind of signal (L1), frame (L2) or packet (L3) relaying. (That means: the LAN itself is just a physical wire between the client and the server)