[Spread-users] Spread in distributed URL monitor application

[Kashif Shaikh]

Ok, now you are running monitor clients on the desktops. I assume you have
only a single network path to the Internet. If your primary network
connection dies, there is little you can do to mark a URL as dead.
Secondly, how many monitor clients are you going to deploy? Everytime there
is a URL "state change", you have to announce it. Everyone then processes
the results, and then multicast more messages across the group to
ack/confirm/etc. A simpler method:

- have a central server managing the list of URLs and their corresponding
state
- monitor clients connect to server periodically notifying server of URL
health status
- so if a client can access a URL, it will notify server the URL is Healthy
- and if it cannot access URL, it will do nothing
- the server sets a 10-minute timeout on each URL state. If 10 minutes are
up, and the URL isn't hasn't been updated with a "Healthy" status, the
server sends an email out.
- the point is, there must be atleast one monitor client out on the Internet
you can access the URL. If no one can, then the URL is expired on the
server, and the server sends out an email.

Pros: Clients do healthy checking and send/recv messages to/from server.
Server handles logic of expired URLs.
Cons: Server is a bottleneck if you have a lot of URLs and lots of clients,
and an SPOF. Unless you implement > 2 servers via spread keeping the states
in sync.


Kashif



> -----Original Message-----
> From: spread-users-bounces at lists.spread.org
> [mailto:spread-users-bounces at lists.spread.org]On Behalf Of Mike M
> Sent: Wednesday, March 02, 2005 10:42 PM
> To: jgreen at spreadconcepts.com; spread-users at lists.spread.org
> Subject: Re: [Spread-users] Spread in distributed URL monitor application
>
>
> On Wed, 2 Mar 2005 11:56:26 -0500, Jacob Green
> <jgreen at spreadconcepts.com> wrote:
> > Monitoring "App 1" detects a dead URL, announces it to a Spread Group X.
> > Other monitoring apps are listening to Group X, and once they
> receive the
> > dead URL message from App 1, each attempts to connect to the
> URL.  They each
> > announce their results back to the private group of App1.  Once
> App 1 has
> > collected enough results from the other apps (say it take 3
> confirmations to
> > declare a URL dead), it will then send out the e-mail you spoke of.
> >
> > Many other options, examples, etc are quite possible.
> Including handling
> > the case were connectivity between monitoring apps is down.
> >
> > Jacob
>
> This is exactly the program flow I had in mind.  Any ideas how to get
> it started? :)
>
> Seriously though, I think the spread toolkit might just be the trick
> for the messaging subsystem for my monitoring app.  If you know if any
> perl sample code I can get my hands on, that would be great - I
> haven't had much luck finding scripts using spread on the Internet.
>
> Also, is spread suitable for use over high-latency WAN/Internet links?
>  Since the monitors will mostly be running on desktop linux boxes
> connected to cable/DSL connections, are there any caveats to this sort
> of implementation?
>
> Thanks for your input!
>
> Mike
>
> _______________________________________________
> Spread-users mailing list
> Spread-users at lists.spread.org
> http://lists.spread.org/mailman/listinfo/spread-users
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.300 / Virus Database: 266.5.0 - Release Date: 2/25/2005
>