deSleeper tries it's best to make a complex system simple, but it may help to understand the architecture when you're unsure how to setup your system.

First, you should understand the components that are used for the entire interaction.

Components.png

The three main components are the client, the proxy and the target.
  • Target - The machine that goes to sleep automatically or manually and needs to be reactivated remotely.
  • Client - The machine you're using when you want to wake up the client.
  • Proxy - The machine which listens for requests from clients and uses it's superior network access to get a magic packet to the network card of the target.

Understanding these components helps understand the steps necessary to set them up.

Setup.png

These steps are:
  • Configure the target's network interface. It is not always necessary, but many network cards do not have wake-on-LAN enabled by default. You don't need deSleeper to do this, but help you avoid hunting around in Device Manager deSleeper provides the "Network Card Configuration" tab. If you know how to do this without deSleeper's help you don't need to install deSleeper on the target.
  • Install Proxy Service - Clients usually have obstacles between them and the target. The proxy service needs to be installed on a machine physically located on a network that avoids these obstacles. The safest spot is connected to the same network switch, but depending on your network setup farther away may work as well. There are plenty of variables here so when in doubt closer is better. The "Service Installation" tab is only available if you install the full version. This tab helps configure the proxy service which will run in the background and boot with proxy machine.
  • Install Client - The easiest step, install your client. You can use the full version or the client only version.

Once everything is setup, all that is left to do is send a wake up request.

Request.png

The requests use web-services calls to contact the proxy with the target information. Where this request is sent is the "destination". deSleeper also supports a "local" destination that does not use a proxy, but requires the client and target not to have obstacles in between each other.

Either the proxy, or if "local" the client, then constructs a "magic packet". Essentially a magic packet is a set of bytes in a simple pattern that the network card of the sleeping target can recognize it without the assistance of the CPU. When the network card recognizes a magic packet stamped with it's unique name (known as the MAC address), it sends messages to other components of the machine that turn on the CPU, memory, hard disk, etc, or take them out of super-low power states into operational states.

What can go wrong?
  • If the network card isn't watching for the magic packet it won't wake up the machine.
  • Magic packets are broadcast. Because the machine is off, it's not really possible to direct the request at the target. Networks limit the scope of broadcasts for many reasons. If the machine that broadcasts the magic packet is in a different scope from the target, the broadcast will never reach it.
  • When using the "Host Name" wake up method, it needs to be possible to resolve the Host Name into a MAC address, because the MAC address is a critical part of the magic packet. On most networks it's not possible to do this while a machine is off. For this reason, the proxies maintain a "cache" of host name and MAC address pairs. But to initialize this cache it's necessary to send a wake up request once while the machine is on. Somewhat counter-intuitive to send a wake up request while online, which is why I'm looking into some other solutions, but it works well after the single request. Cache's on a proxy survive shutdowns and restarts, but they may not survive a reinstall of the deSleeper service.

Reference Files: Architecture.vsd

Last edited Feb 17, 2010 at 9:42 PM by nedruod, version 5

Comments

No comments yet.