ozzy

We have a utility running on all our network PC's. It generates a text file, but I have to manually connect to each workstation using it's UNC path to monitor the output of the file.

What I'd like to do is create a utility which can be installed as a service on each client (NT4). This utility will poll the text file every "x" number of minutes and listen on a available IP port.

I then want to create another management utility that will poll each of the clients (using it's IP address and the port number) querying what the value of the text file is.

What's the easiest way of achieving this? and what programming language do you suggest? VB?

Stefan

Michael Robinson

We have something similar here at work and how it works is we right into the loggin script which then grabs the designated file (pc specs in our case) and passes them to a central point.

stevencotton

It's surely a 20 minute job, either use webservers or some SOAP app.

Steve.

ozzy

Michael,

The workstations run an analysis tool. I need to poll the files every minute or so and not just when the user logs in. It doesn't need to be a live feed, but every 5-10 minutes would probably be sufficient.

The text file as a simple value showing how far the analysis has progressed. I need to monitor groups of workstations and how each group analysis is doing. I can then provide summary reports to the management.

The reason I need to use IP is that some workstations belong to completely seperate NT domains (with no trust relationships). Using UNC is VERY slow as it needs to authenticate when checking paths. A few will fail simply because the central workstation needs to have username/passwords entered manually.

I've been looking at ways around this for a few weeks and I think IP ports is the way to go.

Stefan

ozzy

Steve,

If it's only a 20min job, then please explain yourself

Stefan

David_Wallis

what about creating a null session share on the machine... (anybody can access these, without a trust relationship) or get the client machines to poll the server... that would be easier would it not?

or create an account on the server and do a net use \\server\share /user:domain\user

David

stevencotton

Sure Set up webservers on each box you need to communicate with, some kind of other service (like cron on UNIX) to poll the webservers every X minutes and get the status of the file. You can transfer files, read/process whatever, all via HTTP. Or you can substitute webservers with some SOAP services to achieve the same effect. I'll write it for you if you like, but I'll charge you and it'll be in Perl

Steve.

ozzy

Steve,

I only want to put a very small app on the workstations, so don't fancy sticking a webserver on each of them. Something nice and simlpe is all I'm after.

David,

UNC is far too slow, even using the NET USE commands with user authentication. I have some analysis reporting software nd it's using the UNC paths just now. Trouble is, it hangs for a couple of minutes whilst it validates the path. And to poll this every 5mins is a pain in the @rse.

Stefan

stevencotton

No problem, one little process waiting for a connection on a port of your choice is all you need.

Steve.

SWRTWannabe

I would say that services are best written using C / C++ (I am a C/C++ programmer, so I may be biased). A colleague did write a service in VB, but as far as I remember, it was a bit of a fudge.

What you are aiming to do sounds quite feasible, and if you need someone to write it, I'm available a reasonable rate

David_Wallis

vb.net can create services easily and they can be multi threaded and dont have to be single appartment..

What about ftping the files then.

David

stevencotton

There's no point using FTP since a local copy of the files isn't required, and with HTTP you can request the file straight into a variable instead of copying it over, reading a file, and deleting it. You can write it in any language you like - it makes zero difference - unless you take maintainability, speed of development, and the fact that a C++ application that just sends a small text file smells of massive overkill (like implementing a webserver to do the job If you plan on integrating it later into something bigger then take that into consideration too, because that'll affect your language choice.

Steve.

ozzy

FTP'ing is a possibility, but I'd rather leave the originals on the workstations. Once the analysis is complete, it does report the stats back to the central PC already, but I'd like the ability to monitor it in almost real-time (well, my interpretaion of the phrase).

I though it'd be cool to write some utils; might rekindle my programming days @ college.

Stefan

stevencotton

It will be "real time", in that each time a request is made, you'll get completely up-to-date information valid at the time of processing.

Steve.

ozzy

Steve,

So for a complete novice like me, what products would I need to do this i.e. what get installed on the client & central workstation and what code would you suggest I use?

It's a pet-project, so something up-to-date would be ideal. So, don't go suggesting COBOL We've enough of those programmers here already

Stefan

stevencotton

I'd do it in Perl personally (I can also program in C, but Perl is perfect for this kind of job), so get yourself ActiveState Perl (www.activestate.com). You have a few options of course, it stinks of SOAP but you could do it with HTTP:aemon and LWP. If you're going to jump into this head first you might have a steep learning curve, but you'll learn a lot in the process.

You need a daemon (service) on each machine you want to query, it sits there listening on a port waiting for a connection. When one comes in it gets the requests and dumps the file down the open socket, the client disconnects and the daemon just sits there again waiting.

Your client can either run all the time (as another daemon/service) or you can just have it execute every X minutes, via a cron-like service which I'm sure there is one on Win32. It just makes a connection to each machine you want to query, grabs the data from each, stores it in a variable locally, and processes it. Simple as that.

The Perl code for the servers are about .. 20-odd lines give or take, but you'll need to install a couple of modules (SOAP::Lite has many, many dependencies whereas the HTTP:: modules will require a lot less), but the code to make an HTTP request is one line. Then you just do whatever you want to do with the data.

Steve.

God damn the UBB horse manure. The "Big smiley" should be "HTTP:: Daemon" without the space!


[Edited by stevencotton - 5/31/2002 1:38:47 PM]

IWatkins

Another option (assuming I understand the problem):

Install a small service on each 'client'. This service will read the file every X mins and extract the relevant bits. It then POSTs the info. to a ISAPI DLL hosted on a central webserver. The ISAPI DLL collates all the responses and creats a web page of details from all the 'clients'. You can look at this web page, whenever, as often as you like.

You would need something like IIS (webserver) on a central machine, the ISAPI DLL and then the service you would install on every 'client'.

This would make it extensible in the future, but may be slightly overkill / difficult if you are not familiar with quickly setting up IIS. The service and the ISAPI DLL would be very easy, and of course would be written in Delphi

Cheers

Ian

ozzy

Steve,

Yeah the UBB code can be annoying. Knew want you meant though.

Your suggestions looks ideal and sound like just what I'm after.

I'm away to have a play

Oh, I've got a TV feed to my desktop PC, so I'm watching the France-Senegal games as I type

Stefan

stevencotton

Except that's completely backwards, since you want the client requesting rather than the machines sending the data, you can't get data-on-demand that way. There's no reason why the client reqesting the data can't serve it's results up via HTTP, and you avoid the utter exploitable mess that is IIS

Steve.

ozzy

Thanks Ian.

I'll look into that too.

Stefan

David_Wallis

I suggested ftp, incase you didnt really want to do any programming...

David

ozzy

So your not a IIS fan then Steve?

ozzy

That's OK David.

I'm using the manual way just now and really would like to automate the whole process. I had a search around for some utilities that could have done this, but couldn't find any.

Looks like doing some code is the only way to get it done. I quiet enjoyed it in the past, so I'm more than happy to tinker

Stefan

IWatkins

Steve,
Nowt wrong with IIS, as long as you don't rely on it

Ozzy,
Another possible solution, see http://www.scoobynet.co.uk/bbs/threa...=100362&Page=2

Basically, write a service to check the file every X minutes. Write the value out using OutputDebugString and monitor it centrally with DebugView.

Cheers

Ian

stevencotton

Hehe, I don't know why anyone bothers with IIS if it's just a webserver they're after, you have to be mad if you deploy it. Perhaps there was a need for it in the past, but Apache 2.0 is a native port and far superior in every way. Unless you just use IIS as some component of a larger Microsoft installation of course, in which case you're forced to because you don't have any other choice

If you want to learn something buzzwordy look at SOAP, because this is exactly the kind of thing it's designed for and managers love buzzwords. I like solutions that are platform independent, scalable and maintainable, so you could chuck all this on any machine you have, as long as there's a Perl interpreter (available for almost every OS) and a TCP/IP stack you're sorted.

Steve.

Molds

Create an ODBC data source for the file you are interested in.
Write yourself an ASP web page that uses the data source, then pick out the bits you want to display .