Writing monitoring program VC++

[mojtaba_danai]

Hi

Hope that some one can help with the following. I wish to write a
Visual C++ program, which monitors 3-4 other services (process/programs
also written in VC++).
The program shall monitor, if the other processes are alive and to see,
if they are sending heartbeat messages. I wish to do this for exampel
via socket programming.

Can any one tell me, the structure og guideline for this?

My email is: mo***********@yahoo.com

Thanks in advance.

Best regards
Mojtaba

[benben]

mo***********@yahoo.com wrote:

Hi

Hope that some one can help with the following. I wish to write a
Visual C++ program, which monitors 3-4 other services (process/programs
also written in VC++).
The program shall monitor, if the other processes are alive and to see,
if they are sending heartbeat messages. I wish to do this for exampel
via socket programming.

Can any one tell me, the structure og guideline for this?

My email is: mo***********@yahoo.com

Thanks in advance.

Best regards
Mojtaba

The easiest way is to ask again in a windows-specific newsgroup.

Ben

[David]

On Tue, 13 Jun 2006 00:38:14 UTC, "mo***********@yahoo.com" <mo***********@yahoo.com>
wrote:

Hi

Hope that some one can help with the following. I wish to write a
Visual C++ program, which monitors 3-4 other services (process/programs
also written in VC++).
The program shall monitor, if the other processes are alive and to see,
if they are sending heartbeat messages. I wish to do this for exampel
via socket programming.

Can any one tell me, the structure og guideline for this?
It doesn't sound like anything is VC++ specific. TCP/IP or UDP/IP
are certainly options that work well for other projects. I'm not
sure what your question is though. Would your application just
intrface with the services as they are today or is the socket
protocol for this something that you are considering to add?
My email is: mo***********@yahoo.com

Thanks in advance.

Best regards
Mojtaba

[mojtaba_danai]

Hi again

Yes, I am considering socket solution. The services are
processes/programs (not windows services), and they send messages
(heartbeat), so the new monitoring program has to check whether they
are sent and otherwise alarm.
Thanks in advance.

Mojtaba

David wrote:

On Tue, 13 Jun 2006 00:38:14 UTC, "mo***********@yahoo.com" <mo***********@yahoo.com>
wrote:

Hi

Hope that some one can help with the following. I wish to write a
Visual C++ program, which monitors 3-4 other services (process/programs
also written in VC++).
The program shall monitor, if the other processes are alive and to see,
if they are sending heartbeat messages. I wish to do this for exampel
via socket programming.

Can any one tell me, the structure og guideline for this?

It doesn't sound like anything is VC++ specific. TCP/IP or UDP/IP
are certainly options that work well for other projects. I'm not
sure what your question is though. Would your application just
intrface with the services as they are today or is the socket
protocol for this something that you are considering to add?

My email is: mo***********@yahoo.com

Thanks in advance.

Best regards
Mojtaba

[David]

Hello Mojtba,

On Tue, 13 Jun 2006 22:30:24 UTC, "mo***********@yahoo.com" <mo***********@yahoo.com>
wrote:

Hi again

Yes, I am considering socket solution. The services are
processes/programs (not windows services), and they send messages
(heartbeat), so the new monitoring program has to check whether they
are sent and otherwise alarm.
Thanks in advance.
It doesn't really matter how the processes/programs are implemented
or where they reside. That is some of the beauty of using TCP/IP.
All you need is some central monitoring location/application that
the processes/programs know to contact. Conversely you may choose
to have your monitor register with the processes/programs for
notifications or even a mixture of both. Most of my products have
chosen to use a mixed approach and once a bond has been created
between a downstream device and an upstream device they continue
to expect the conversation to recover if at all possible, and
report when nodes fall out of service. I use a mixture of alarm
modes. Some communication failures are reported almost immediately
when the loss affects the integrety of the network. There are also
some low level "I'm alive, nothing to report" communications that
occur once a day or so that don't use an always up connection;
those alarm when a device has not been heard from in a while.

You can use whatever alarm strategy is appropriate to your needs.

I'm not sure if we've touched on your original inquiry.

Good luck,

David
Mojtaba

David wrote:

On Tue, 13 Jun 2006 00:38:14 UTC, "mo***********@yahoo.com" <mo***********@yahoo.com>
wrote:

Hi

Hope that some one can help with the following. I wish to write a
Visual C++ program, which monitors 3-4 other services (process/programs
also written in VC++).
The program shall monitor, if the other processes are alive and to see,
if they are sending heartbeat messages. I wish to do this for exampel
via socket programming.

Can any one tell me, the structure og guideline for this?

It doesn't sound like anything is VC++ specific. TCP/IP or UDP/IP
are certainly options that work well for other projects. I'm not
sure what your question is though. Would your application just
intrface with the services as they are today or is the socket
protocol for this something that you are considering to add?

My email is: mo***********@yahoo.com

Thanks in advance.

Best regards
Mojtaba

[mojtaba_danai]

Hi David

Many thanks for your response.
If I wish to use the registration method, how can it be implemented. I
mean can you give some idea of designing the monitoring module, may be
alos one without registration.

I need some structure to start this.

Thanks

Regards
Mojtaba

David wrote:

Hello Mojtba,

On Tue, 13 Jun 2006 22:30:24 UTC, "mo***********@yahoo.com" <mo***********@yahoo.com>
wrote:

Hi again

Yes, I am considering socket solution. The services are
processes/programs (not windows services), and they send messages
(heartbeat), so the new monitoring program has to check whether they
are sent and otherwise alarm.
Thanks in advance.

It doesn't really matter how the processes/programs are implemented
or where they reside. That is some of the beauty of using TCP/IP.
All you need is some central monitoring location/application that
the processes/programs know to contact. Conversely you may choose
to have your monitor register with the processes/programs for
notifications or even a mixture of both. Most of my products have
chosen to use a mixed approach and once a bond has been created
between a downstream device and an upstream device they continue
to expect the conversation to recover if at all possible, and
report when nodes fall out of service. I use a mixture of alarm
modes. Some communication failures are reported almost immediately
when the loss affects the integrety of the network. There are also
some low level "I'm alive, nothing to report" communications that
occur once a day or so that don't use an always up connection;
those alarm when a device has not been heard from in a while.

You can use whatever alarm strategy is appropriate to your needs.

I'm not sure if we've touched on your original inquiry.

Good luck,

David

Mojtaba

David wrote:

On Tue, 13 Jun 2006 00:38:14 UTC, "mo***********@yahoo.com" <mo***********@yahoo.com>
wrote:

> Hi
>
> Hope that some one can help with the following. I wish to write a
> Visual C++ program, which monitors 3-4 other services (process/programs
> also written in VC++).
> The program shall monitor, if the other processes are alive and to see,
> if they are sending heartbeat messages. I wish to do this for exampel
> via socket programming.
>
> Can any one tell me, the structure og guideline for this?

It doesn't sound like anything is VC++ specific. TCP/IP or UDP/IP
are certainly options that work well for other projects. I'm not
sure what your question is though. Would your application just
intrface with the services as they are today or is the socket
protocol for this something that you are considering to add?

> My email is: mo***********@yahoo.com
>
> Thanks in advance.
>
> Best regards
> Mojtaba

[David]

Hello Mojtaba,

On Wed, 14 Jun 2006 01:37:27 UTC, "mo***********@yahoo.com" <mo***********@yahoo.com>
wrote:

Hi David

Many thanks for your response.
If I wish to use the registration method, how can it be implemented. I
mean can you give some idea of designing the monitoring module, may be
alos one without registration.
It might be best to start simple and work your way up. The communication
concpts are pretty much the same. The more advanced versions can be more
like peer networks (todays name for the ancient idea of having both ends
of a communication protocol be able to (re)start a conversation with the
other end).

I'd start by deciding on a simple client-server or peer-peer relationship.
You need to define the basic rules for which components initiate the
conversations, what they have to communicate, how to properly disconnect
them, and how to recognize an abnormal situation.

First you'll need to decide what your communication endpoints are like.
In simplest terms, this might be the IP Address or Domain Name for an
endpoint, and the well known port that enables your endpoints to start
talking. I'm presuming that you are familiar with how a pair of TCP
applications would establish a conversation. If not, perhaps you could
read a few of the early RFCs (request for comment documents) that define
many of the protocols supported in the internet. SMTP (simple mail
transport protocol) is a good example. The client establishes
conversations with the server. Clients are normally user applications
and servers are part of a vast mail server network.

Most of my products exist as a single entity on a machine. Thus the
IP Address or Domain Name, plus the well known port or protocol name
are all that is needed by each endpoint to know how to handle setting
up communications. Some of my products use simple text protocols like
SMTP and others use a well defined binary message structure.

You can choose your monitoring application to be either the client
or server end. When you configure the monitoring application with
the list of all devices to monitor and have it initiate the
conversations, it is called the client. When the endpoint devices
contact the monitor, the monitor is usually called a server.

Say that you enable all your endpoint devices with some code to
support one or perhaps more inbound conversations. That is they
are each servers. However, once a connection has been established
the protocol states that once each end has identified itself, the
server will send out some sort of status packet.

The monitor application then needs a persistant list of all
IP Addresses and port numbers of endpoint devices to establish
conversations with and monitor. The loss of any connection
may be worth reporting or perhaps just when the desired
conversation can't be reestablished. You have to understand
that in many networks, TCP conversations, especially long term
ones, can go in and out of service and still be considered
normal. Similarly, don't try to have a device report in every
few seconds and expect the data to arrive on time. This will
usually be okay, but what happens if a burst of ftp, http,
or other traffic clogs the network for more than a few seconds?
Will your monitor suddenly start reporting false lost connections?
Likewise if the status of devices is cummulative you may need
to verify reception of traffic and have a slightly more complicated
protocol. For instance, in a credit card processing protocol it
would be rather bad to double bill a card because of normal
communication retries in the network. You just need to decide
what is the correct behavior for your needs.

Does this help? It might be helpful to create a model of your
products. A simple paper drawing can be very useful. I've
also seen 3x5 cards on a wall with rubber bands as the
connections. Once you have determined how they establish
communications, you can specify what they need top say to each
other. Simple protocols are usually something that can be
written out or done by hand. More complicated protcols may
need a fairly extensive description of the conversation.

Have fun,

David
I need some structure to start this.

Thanks

Regards
Mojtaba

[mojtaba_danai]

Hi David

Thanks again for your good explanation.
Do you know, any sample code I can look at for this scenario? I mean
for the monitor can identify the other programs (servers) and receive
the status packet?

Thanks again and sorry for bothering you.

regards
Mojtaba
David wrote:

Hello Mojtaba,

On Wed, 14 Jun 2006 01:37:27 UTC, "mo***********@yahoo.com" <mo***********@yahoo.com>
wrote:

Hi David

Many thanks for your response.
If I wish to use the registration method, how can it be implemented. I
mean can you give some idea of designing the monitoring module, may be
alos one without registration.

It might be best to start simple and work your way up. The communication
concpts are pretty much the same. The more advanced versions can be more
like peer networks (todays name for the ancient idea of having both ends
of a communication protocol be able to (re)start a conversation with the
other end).

I'd start by deciding on a simple client-server or peer-peer relationship.
You need to define the basic rules for which components initiate the
conversations, what they have to communicate, how to properly disconnect
them, and how to recognize an abnormal situation.

First you'll need to decide what your communication endpoints are like.
In simplest terms, this might be the IP Address or Domain Name for an
endpoint, and the well known port that enables your endpoints to start
talking. I'm presuming that you are familiar with how a pair of TCP
applications would establish a conversation. If not, perhaps you could
read a few of the early RFCs (request for comment documents) that define
many of the protocols supported in the internet. SMTP (simple mail
transport protocol) is a good example. The client establishes
conversations with the server. Clients are normally user applications
and servers are part of a vast mail server network.

Most of my products exist as a single entity on a machine. Thus the
IP Address or Domain Name, plus the well known port or protocol name
are all that is needed by each endpoint to know how to handle setting
up communications. Some of my products use simple text protocols like
SMTP and others use a well defined binary message structure.

You can choose your monitoring application to be either the client
or server end. When you configure the monitoring application with
the list of all devices to monitor and have it initiate the
conversations, it is called the client. When the endpoint devices
contact the monitor, the monitor is usually called a server.

Say that you enable all your endpoint devices with some code to
support one or perhaps more inbound conversations. That is they
are each servers. However, once a connection has been established
the protocol states that once each end has identified itself, the
server will send out some sort of status packet.

The monitor application then needs a persistant list of all
IP Addresses and port numbers of endpoint devices to establish
conversations with and monitor. The loss of any connection
may be worth reporting or perhaps just when the desired
conversation can't be reestablished. You have to understand
that in many networks, TCP conversations, especially long term
ones, can go in and out of service and still be considered
normal. Similarly, don't try to have a device report in every
few seconds and expect the data to arrive on time. This will
usually be okay, but what happens if a burst of ftp, http,
or other traffic clogs the network for more than a few seconds?
Will your monitor suddenly start reporting false lost connections?
Likewise if the status of devices is cummulative you may need
to verify reception of traffic and have a slightly more complicated
protocol. For instance, in a credit card processing protocol it
would be rather bad to double bill a card because of normal
communication retries in the network. You just need to decide
what is the correct behavior for your needs.

Does this help? It might be helpful to create a model of your
products. A simple paper drawing can be very useful. I've
also seen 3x5 cards on a wall with rubber bands as the
connections. Once you have determined how they establish
communications, you can specify what they need top say to each
other. Simple protocols are usually something that can be
written out or done by hand. More complicated protcols may
need a fairly extensive description of the conversation.

Have fun,

David

I need some structure to start this.

Thanks

Regards
Mojtaba