Lately I came across a requirement for an ability to remotely turn on computers in our company. Couple of team members (including me...) tend to work from home sometimes so they leave their PCs running when they leave the office so the next day they could access it over Remote Desktop. Do you spot a problem already? To be honest I did not realise this was a problem either ... until an electricity bill came in. The workstation PCs are running nonstop (no one really bothers to switch them off, what if they did not go to the office tomorrow ...), which obviously has very negative impact on the electricity consumption in our office.

So it was clear we need to do something about it. One can switch off a PC using Remote Desktop very easily (you can do it directly from Start menu), but having ability to switch off a computer remotely is useless unless you can then remotely switch on the computer again. And that is where Wake on LAN finds its place.

"Magic Packet"

Wake On LAN (sometimes referred as WOL or WoL) is a marketing term used for ability to bring computer out of Stand-By mode by sending it a special packet, called "Magic Packet".

When you shutdown Windows, all modern ATX-power based PCs do not switch off completely. Instead they enter a Stand-By mode, which means RAM, CPU and hard drives are switched off, but motherboard itself and a network card are still powered. To determine if your network card supports WOL, shut down your PC and check the Link LED on the network card - if it is still active, your network card is still powered and should support Wake on LAN.

Even though a PC is shut down, the network card is listening on the data layer (usually Ethernet) level and scans incoming packets for special character sequence. If it detects the sequence, it will turn on the PC. This sequence, called Magic Packet, has following structure:

Read more »

If you develop client applications, very often you come across an operation which is taking long to complete. Basically, you have 2 options; You can either do nothing about it, let the application "freeze" and let user wait for end of the operation. The problem is that the user doesn't know what is happening so he will become frustrated ("Damn, this app is really slow...") and may even eventually kill the application from the task manager, thanks to the "feature" of Windows which will mark the window as "Not Responding" and will offer the user an option to end the process.

That is why asynchronous processing (aka. processing in background) comes in place. The idea is that you display a dialogue to the user that informs him/her that there is something going on and that it may take some time to complete; or you can even let the user work with the application and literally do all the processing in the background.

Read more »