Need Help Determing Solution 4

[txmed]

Hello. I am working on a two-part program.

Part 1:
One part of my application tracks programs launched by a user. When a program is launched, the app stores information regarding the program in memory. When the user is finished (logs off), the app will store all program information into a database.

Part2:
The second part of the app serves as a 'admin' monitor (runs on a separate machine than the other part). This application needs to be able to list all of the program information being stored by the other computers.

Problem:
Using Part 2, how can I access the information stored in Part 1? Can remoting help me out here? What about sockets?

Thanks!

(txmed)

 

[macleod1021]

>>> the app will store all program information into a database


Unless there's something else that you're not mentioning, you've already solved your problem. If you're storing it an a database, just have your admin program query the database. If you need more of a real-time monitor, then consider updating the database more often. Personally, if you're needing to track the program information reliably then I'd suggest sending updates to the database more frequently. Your current situation would result in problems if the user just turns their computer off without logging off.

 

[txmed]

macleod1021,

I'm actually storing all of the information into the database when the user logs out, not at a set interval. I decided to do this because I wanted to minimize traffic to the server. But unfortunately, this does not allow me to retrieve the data while the user is still logged in.

That's why I was looking for another means of retrieving the data in real time. I keep hearing about "remoting". Would this be able to solve my problem?

(txmed)

 

[woogoo]

What about sending the information to the 'server' component of your app (part 2) when the user starts and stops an application. Then have this component do the updates to the database. This would then give you a more realistic 'real time' to the application usage trends.

Since you have to get the data across the network at some point this to me at least would be the most elegant solution.

The amount of traffic this would generate would be minimal and nothing more than noise on the network as not everyone has the same working practices.

This approach also has the benefit of preventing a user from trying to hide their application use, as you at least have the startup information.

If the user then simply turns off the power you would know, as there would be no matching closing entry in the database and you could then explain to the user not to do it.

Doing it at the close of the day would result in a total loss, which would lead to the question "Why did they turn the power off?"

With a bit of additional code you could track a user when they log in and have your client component (part 1) display a message asking them not simply turn off the power.

 

[txmed]

Thanks for your reponse woogoo.

"What about sending the information to the 'server' component of your app (part 2) when the user starts and stops an application. Then have this component do the updates to the database. This would then give you a more realistic 'real time' to the application usage trends."

I was actually trying to get away from sending the data to the server component until the very end (less traffic flow). However, it's becoming apparent to me that maybe this should be done. If I do this, then my admin app (part 2) could simply requery the database at a set interval (like macleod1021 suggested).

As of right now, my work-around for the user shutting the power off is a that at a set interval I'm writing the information to a backup file on the machine. This way, if the user does turn off the power, the next time my app is launched, it will find this file, read/parse the information and upload it into the server.

(txmed)

 

[ThatRickGuy]

How much data are we talking about that traffic would really be a concern? Unless you are processing database embedded objects (images, binaries, etc...) it likely won't be a large amount of transfer. Updating a database with the Username, application, and time stamp is going to be a tiny load, unless your users are on a 300 baud modem, it likely won't be noticable.

On a side note, it sounds like you are writing some sort of monitor program so that you can see what applications your customers are running. Be careful on this project, most users don't enjoy being monitored.

-Rick

VB.Net Forum forum796 forum855 ASP.NET Forum
I believe in killer coding ninja monkeys.

 

[ca8msm]

Be careful on this project, most users don't enjoy being monitored.

Yep, I have a service that kills the process that our system admins use to do exactly the same thing


____________________________________________________________

Need help finding an answer?

Try the Search Facility or read FAQ222-2244 on how to get better results.

 

[woogoo]

Ok I found another 10c so I'm putting it in. Don't you think you are over engineering this a little bit. You're now adding additional code (file writing, reading etc.) that really isn't required.

I too fall victim to this problem of over engineering (just read my post about comboboxes!). In my humble opinion the 'best' option is to talk in real time to the server component and have it update the database. That way you remove this code requirement from the client component as well and you have data to hand to produce relevant and valid reports on.

All that you need to pass over the socket to the client is the user's name and application name as you can get the date and time from the server. This would undoubtedly fit an a single packet on the network.

Hope that helps.

 

[ThatRickGuy]

We had a system at my school that would use a remoting type solution. Simple fix was to set up a Java app to open a socket on the same port then kill the monitor process. The monitor would restart itself, but would bomb because it couldn't open a socket because the port was already in use.

-Rick

VB.Net Forum forum796 forum855 ASP.NET Forum
I believe in killer coding ninja monkeys.

 

[txmed]

Thank you to everyone responding. Here are my answers/comments:

ThatRickGuy: "How much data are we talking about that traffic would really be a concern?"

txmed: It's not so much of how much data will be transferred, but how far the server component may be from the client. My boss wants this app to be used in a WAN, where the server has the possibility of being pretty far away. I'm coding with the concern of connectivity issues.


ThatRickGuy: "Be careful on this project, most users don't enjoy being monitored."

txmed: Yes, we are expecting some negative input from the users. Unfortunately, the powers that be want this, no matter who gets upset.


Woogoo: "In my humble opinion the 'best' option is to talk in real time to the server component and have it update the database. That way you remove this code requirement from the client component as well and you have data to hand to produce relevant and valid reports on."

txmed: Yes, the more I think about this, the more I'm liking this solution. Even though the traffic flow to the server will be increased, more so than I originally wanted, the 'headaches' that could come out of using sockets would be far worse.


ThatRickGuy: "We had a system at my school that would use a remoting type solution. Simple fix was to set up a Java app to open a socket on the same port then kill the monitor process. The monitor would restart itself, but would bomb because it couldn't open a socket because the port was already in use."

txmed: Thanks for the tip. I'll definately keep this in mind for the future.

(By the way, I gave everyone who responded a star).

(txmed)

 

[ThatRickGuy]

It's not so much of how much data will be transferred, but how far the server component may be from the client. My boss wants this app to be used in a WAN, where the server has the possibility of being pretty far away. I'm coding with the concern of connectivity issues.

You may want to look into a web service in that case. The nice thing about a web service is that it's pretty stable even over long slow connections. Set up a web service on a WAN accessable web server and add a reference in your project to the web service. That way, the web service connects to the database and the client only has to upload a few string variables. Super light weight communication. The other nice thing is that unless users want to block port 80 they aren't going to have much luck blocking the communication. They could redirect the web site in their host files if they don't access the server for anything else and you don't use an IP for the host.

Also, I would recommend running the client as a service, that will make it a little less visable to most users. You could also set up a second service that does nothing but ensure that this service is running. so that even if this service crashes or is closed by the user, it should restart.

-Rick

VB.Net Forum forum796 forum855 ASP.NET Forum
I believe in killer coding ninja monkeys.

 

[txmed]

ThatRickGuy, thanks for the suggestion about the web service. I will look into this as a viable solution.

I had already thought of a second application that would run in the background to ensure the first component is running. However, I did not think of creating this as a service. I will definately change this into a service rather than a standard windows app.

Thanks!

(txmed)