Here we have a slightly different use for the periodic timeout messages. The messages are purely for the internal use of the server and generally have nothing to do with the client at all.
For example, some hardware might require that the server poll it periodically, as might be the case with a network connection—the server should see if the connection is still “up,” regardless of any instructions from clients.
Another case could occur if the hardware has some kind of “inactivity shutdown” timer. For example, since keeping a piece of hardware powered up for long periods of time may waste power, if no one has used that hardware for, say, 10 seconds, the hardware could be powered down. Again, this has nothing to do with the client (except that a client request will cancel this inactivity powerdown)—it's just something that the server has to be able to provide for its hardware.
Code-wise, this would be very similar to the example above, except that instead of having a list of clients that are waiting, you'd have only one timeout variable. Whenever a timer event arrives, this variable would be decremented; if zero, it would cause the hardware to shut down (or whatever other activity you wish to perform at that point). If it's still greater than zero, nothing would happen.
The only “twist” in the design would be that whenever a message comes in from a client that uses the hardware, you'd have to reset that timeout variable back to its full value—having someone use that resource resets the “countdown.” Conversely, the hardware may take a certain “warm-up” time in order to recover from being powered down. In this case, once the hardware has been powered down, you would have to set a different timer once a request arrived from a client. The purpose of this timer would be to delay the client's request from going to the hardware until the hardware has been powered up again.