Page 1 of 1
How many users are accessing my .EXE?
Posted: Fri Mar 28, 2008 1:37 pm
by patrickmast
Hi,
Is there a way to know how many users are accessing "app.exe" in a peer to peer network?
So, app.exe is installed on the C drive of the server. The clients are starting the app.exe from their networkdrive that's connected to the C drive on the server.
On a Terminal Services Server I use this:
Code: Select all
FUNCTION GetExeUsers( cExe )
LOCAL oWmi, oList, oProc
LOCAL cUser, cDomain
LOCAL aList := {}
oWmi := WmiService()
IF !Empty(oWmi)
oList := oWmi:ExecQuery( "select * from Win32_Process where Name = '" + cExe + "'" )
FOR EACH oProc IN oList
IF ( oProc:GetOwner( @cUser, @cDomain ) ) == 0
cUser = cDomain + "\" + cUser
IF AScan( aList, cUser ) == 0
AAdd( aList, cUser )
ENDIF
ENDIF
NEXT
ENDIF
RETURN aList
But this does not work for a Peer to Peer network.
Thanks!
Patrick
Posted: Fri Mar 28, 2008 3:31 pm
by demont frank
Patrick
When the users are present in a dbf , each user record can be locked. Lock's can be count with sx_islocked (from prezmiek , xharbour forum)
Code: Select all
function Sx_IsLocked( nRecNo , lMode)
**************************************
// lMode .T. , lock from own computer
// lMode .F. , lock from other computer
// must be called with @
LOCAL lReturn := .T.
lMode := .T.
if ! ( dbInfo( DBI_ISFLOCK ) .or. dbRecordInfo( DBRI_LOCKED, nRecNo ) )
lMode := .F.
if valType( nRecNo ) != "N"
nRecNo := recNo()
endif
if dbRLock( nRecNo )
dbRUnLock( nRecNo )
lReturn := .F.
endif
endif
return lReturn
Posted: Sat Mar 29, 2008 12:50 am
by Roger Seiler
I do this two ways redundantly. First, I use Protection PLUS which has a range of secure functions for controlling access to an app on a network. Second, I have each user automatically add/activate a record to a user.dbf file when they load the app. So I just count the number of active records (those not marked with an * in a deletion field) to see how many are on. As each user signs off and the the app's exit procedure is processed, a record is automatically deactivated by blanking various data fields and an * is put in the deletion marker field. Records marked for deletion in this way are periodically cleaned out. In this case, records need not be user-specific (not tied to a particular person).
However, in our implementation of the user.dbf file, users sign on to the app with a password that links to another file to grab the user's ID code and name. The ID is put into an indexed field in the user.dbf file, the name into a name field, so that in this usage, each record here is user-specific while the user is signed on. The system operator can look at a list of names of people signed on, and can send a message to any individual or to everyone (perhaps to tell them all to sign off). Each record has a memo field, which is where the message goes. Whenever the user moves around inside the app (takes a menu option or clicks a toolbar button), the program automatically checks to see if the user.dbf memo field for that user has a message in it, and if so displays it.
In a .mem file, we keep track of whether a daily automatic startup routine has been done. If this indicates that user launching the program is the first to sign on for the day, then certain startup maintenance is automatically done, including cleaning out any erroneously "open" records in user.dbf that were left "open" because the app GPF'd.
(For those who don't know the original definition of GPF, it is "Go Pray Faithfully.")
I hope this helps, Patrick.
- Roger
Posted: Sat Mar 29, 2008 7:54 am
by Otto
What is the advantage/disadvantage of starting the app.exe from their networkdrive?
Regards,
Otto
Posted: Sat Mar 29, 2008 10:22 am
by patrickmast
Otto wrote:What is the advantage/disadvantage of starting the app.exe from their networkdrive?
Sorry, I don't understan your question. There are only few ways to have multiple users run one EXE right?
1. Peer to peer: An application is installed on the server and the network-station connects to the server and starts the EXE form the connected network-drive. The application uses the memory and cpu of the network-station. Advantage is you don't need to use a top class server. Downside is that the workstation also needs to be capable of running your app.
2. Terminal Services: An application is installed on the server and the network-station connects to it via a Terminal Services session on the server. The application uses the memory and cpu of the server. Advantage is that the nerworkstation can be a simple small computer. No power needed. Downside is the cost of the Terminal Services licences.
Maybe this answer is totaly not what you expected, but as I said, I did not understan your question, so I guessed
Patrick
Posted: Sat Mar 29, 2008 10:25 am
by patrickmast
Roger Seiler wrote:I do this two ways redundantly. First, I use Protection PLUS which has a range of secure functions for controlling access to an app on a network.
Thans for the info Roger.
But as you can see in my initial post, using a function that "just" lists the users accessing a certain EXE would be simple. In Terminal Services it works, but I try to find something simular for Peer to Peer networks. If we can have such a function, all of this extra functionality is not needed. But thanks anyway for the ideas. maybe I'm gonna need them eventually
Patrick
Posted: Sat Mar 29, 2008 11:54 am
by nageswaragunupudi
Mr Patrick,
> But this does not work for a Peer to Peer network.
Do you mean this is not working when client work-stations in a domain are executing an exe located on the central server in a LAN environment? ( I do not mean Terminal Server as remote client ).
I think theoretically this should work. Or that is my understanding so far.
I need to get this checked up. I think the exe has to be executed on the Server, not from a client.
This function is querying from the local machine's processes. WmiService() function connects to the local service of the workstation and so we are examining the processes open on the client workstation. We need to query the list of processes running on the server. There are two ways. If we have the rights, we should remotely address the wmi services of the server. ( WmiService function has to be changed)
Other is to execute the function on the Server itself.
In the case of terminal server, we are executing the function "on the server" only, though we are sitting far away. In this case the funtion queries the processes open on the server. But I assume it should show both the users using the exe as a terminal clients and also who are using as normal clients conntected through Lan/Wan
This function and wmiservice() was originally created and meant for administrators, assuming that they would anyway run this on the Server itself or execute as remote client using remote services.
Posted: Sat Mar 29, 2008 2:20 pm
by James Bott
NageswaraRao,
>Do you mean this is not working when client work-stations in a domain are executing an exe located on the central server in a LAN environment?
I think he means on a network without a server.
James
Posted: Sat Mar 29, 2008 4:16 pm
by nageswaragunupudi
Now I guess I am able to figure out what is happening. This function queries the list of services running on the computer on which this program is running. In case of peer to peer connection, the queried exe is listed in the processes of the client but not in the processes of the server.
This explains why this does not give the expected results. Also why it works in terminal server mode. Obviously then it lists only the users directly executing the exe directly on the server ( if any ) and the remote clients of the terminal server.
> I think he means on a network without a server.
This should be the problem with or without server.
Probably a better solution would be to find who opened the exe file on the server. This should be possible, but we need to know how.
Posted: Sat Mar 29, 2008 4:57 pm
by Otto
Thank you Patrick.
I always run my app.exe on the workstation and use the server only as a fileserver for the Databases. As I have no experience running a exe from a disk which is located on a server I asked.
Regards,
Otto
Posted: Sun Mar 30, 2008 7:47 am
by patrickmast
Otto wrote:I always run my app.exe on the workstation and use the server only as a fileserver for the Databases. As I have no experience running a exe from a disk which is located on a server I asked.
Hey Otto,
On very slow networks we do the same. The downside of running your app from the workstation is more work when you upgrade your app. Every workstation needs to be updated. While, if you run your app from the server, only the server needs to be upgraded. Less work!
Patrick
Posted: Sun Mar 30, 2008 10:28 am
by Roger Seiler
Most of my network installations are peer-to-peer and the "semaphore" type methodology I described earlier works fine for peer-to-peer.
Also, in all of my peer-to-peer situations, the app .exe is located ONLY on the server, but is actually run on each workstation - not the server. The data, however, is only on the server. All the user has on his/her workstation is a desktop shortcut aimed at the server, and an .ini file in the local windows dir to keep track of which printer and which display preferences have been selected for that workstation. Everything else is on the server, so updating the software or database design is easy - done only on the server.
So, when the workstation user launches the app by clicking on the desktop shortcut, the .exe and any data needed is sucked across the network into the workstations's memory from the server; all processing is done in the workstation's memory/processor; and all data updates/additions are pumped back to the server. This works fine on peer-to-peer for up to about 10 concurrent users. If need to accomodate more than 10 concurrent users, then need to upgrade to client-server implementation like ADS, otherwise performance degrades significantly.
But for either peer-to-peer or client-server, the semaphore approach for tracking users online works like a charm.
- Roger
Posted: Sun Mar 30, 2008 11:51 am
by Otto
Hello Patrick, hello Roger,
thanks fort he info.
I will try tomorrow when I am in the office to run the app.exe from the server drive.
I always checked for the local HD number to b sure no one starts the exe from a mapped drive because
I was not sure I there are problems if more users execute from one exe.
Good to know that you can run a exe from the server without problems.
As Patrick said there is less work to maintain one exe only.
Regards,
Otto
Posted: Thu Apr 10, 2008 5:05 pm
by reinaldocrespo
Patrick;
Did you find a solution?
I'm interested.
The only way I can think of is by having some kind of service on the "server" that will answer requests from the workstations querying for the number of users using the given .exe. These two .exes (the service on the server and the .exe running on the workstation) could communicate via tcp/ip or windows messaging (that would probably require threads).
But it is still a somewhat complicated solution. I wonder if windows offers a way to report what .exe are being executed on a remote networked pc.
Reinaldo.
Posted: Thu Apr 10, 2008 6:58 pm
by nageswaragunupudi
Theoretically this should definitely be possible. If as administrator we are working on the server, we can see who are all the users using any file. If that can be done, there should be some api for it. It is just that we are yet to find what it is.