Hello Mojtaba,
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
