DWUTKA at marlow.com
DWUTKA at marlow.com
Wed Aug 17 15:18:28 CDT 2005
Okay, JC asked about using UDP in reverse. Since I don't know how experienced ya'all are with winsocks and TCP/IP communications, I decided to whip something up. http://www.marlow.com/RemoteShutdown.zip Here's how this works. Inside that zip you'll find an Access 2000 database with one form and an AutoExec macro (sorry, not writing complete startup code just for a sample). The AutoExec opens frmUDPServer 'hidden'. That form just sits there, and does absolutely nothing, until UDP comms come into port 9999. When the comms come in, there are three options, it will either directly shutdown (docmd.Quit), it will display itself and give the user 10 seconds to cancel the shutdown (that is why this uses a timer, the timer event only starts running during the 'prompted shutdown'), or it will display a message (msgbox). Also, inside the zip, you'll fine testclient.exe (along with the VB source code for that .exe). When you run that, you'll find that a textbox, listbox, and three command buttons. The three buttons do what they say. Click Shutdown Clients, and ALL Access sessions on your network, that have frmUDPServer running in the background will close. Click 'Ask To Shutdown', and ALL Access sessions with frmUDPServer running in the background will now display frmUDPServer, and give the user 10 seconds to cancel the shutdown. Click 'Send Message To Clients', and a msgbox will appear on all of the same machines with the text of what is in the 'Data To Send' labeled textbox. A few special items to note. Pressing Any of the three buttons, while running an Access .mdb with frmUDPServer on the same machine will result in a 'Cannot use this if a server is running locally!' message, and nothing will happen. It's a limitation of UDP comms, but that DOES NOT limit this application. (You don't NEED to shut down a LOCAL machine's application REMOTELY! Eh? LOL). So if you want to test this, you will need two machines, one to run the .mdb, and one to run the .exe. Next note, this uses the winsock .ocx. As I mentioned in a reply to JC earlier, this could all be done with API's if so desired, but honestly, I just don't have time to write this all out with API calls. Next note, almost forgot the listbox. When frmUDPServer gets a message from the network, it sends back it's computer name. So the listbox will populate with all of the machines running frmUDPServer that have received a message from the .exe through the network. A note about subnets/lans/NICs. If frmUDPServer is running on a machine that has multiple NICs, it is going to receive a message for each NIC it has. This isn't a concern for the shutdown, and the prompted shutdown (though the prompted shutdown will delay a little longer, because the first hit will start it, and the second, third, fourth, etc hits will reset the time on it....so the countdown won't really countdown until all of the hits come in. (Unless your network is literally crawling, this will all take less then a second....). Sending messages, however, will popup on their machine for each NIC they have (and on the listbox, you'll see that computername show up for each message 'received'. Last note, BE CAREFUL. This is a SAMPLE project, and I personally wouldn't use it in a live system as is. (That is why I sent the VB source). frmUDPServer has absolutely no safeguards in place. It receives a particular string, it stops Access. I personally would recommend a little tighter 'confirmation'. For sample purposes, I'm simply sending out a simple string 'ShutdownNow' (I think). I would make that a little more complex, so that you don't provide an easy method for a hacker to go around shutting down your applications. Enjoy! Drew