Reducing the energy consumption of IT equipment is of growing interest for operational, economic, and environmental reasons. The existing client/server model that uses TCP connections tightly couples application state to connection state. Thus, when a client machine transitions to a sleep state to reduce its energy footprint, the TCP connection drops and the application state is lost on the server. Because of this tight coupling, an idle client machine must remain fully awake to avoid losing its TCP connection to the server and any application state associated with that connection. That is, the client machine must remain in this energy inefficient state or lose any outstanding work (state) in the server. As a result, users often permanently disable power management in client machines.
To address this, we have created a "green telnet" that lets clients transition to a low-power, sleep state to save energy and not lose their telnet session (and state) in the server. We have modified telnetd to recognize when a client machine goes to sleep, gracefully handling the loss of the TCP connection, and then buffering data for the sleeping client. When the telnet client wakes up, a new TCP connection is established and the data buffered in the server is delivered to the client. Our new "gtelnetd" daemon is a modification of the Minix 3 telnetd daemon (www.minix3.org) and is as distribution agnostic as possible by relying on fork() and minimal IPC primitives. To enable the client machine to go to sleep without losing its session, we wedge three processes between the network connection and the telnetd application. These three processes coordinate data transfer, data queuing, and sleep/wake state transitions in a manner that is transparent to the telnet session. We also make some changes to the telnet client and introduce several sleep-related control messages.
Making the Client/Server Model Green
To make the client/server model green, we must allow for the client to go to sleep and thus lose its TCP connection to the server, but still maintain application state in the server. The first step in this process is to define the protocol with which the client and server will communicate power state changes. We have defined three control messages through which the client and server communicate information regarding power state change:
- gtWSLE, which the client sends to the server to indicate that it wants to go to sleep. The payload for this control message is a time indicating how long the client intends to be asleep (0 indicates an unknown sleep period).
- gtWWAK is issued by the client when it wants to wake up. The payload for this message is a byte count used to recover from any data loss that might have occurred.
- gtRECO is sent by the server to let the client know which port number it should reconnect to for the next sleep/wake cycle.
Figure 1 shows the flow of control messages when a client goes to sleep (TCP ACKs are not shown). Upon receiving notification from the host power-management system, the client sends a gtWSLE message to the server. While the client is asleep the server uses an intermediate queue to buffer data destined for the client. When the client wakes back up, it reconnects to the server and sends a gtWWAK message. The server responds by sending the client the next reconnect port via a gtRECO message and any data necessary for synchronization. To delineate control messages from normal data messages, a 2-byte flag field is inserted into data packets sent between a green telnet client and server as in Figure 2.
While the client sleeps, any running applications in the server continue to write data as normal; however, the data is not immediately sent to the client. Instead, we place the data in an intermediate queue and wait until the client reconnects. When the client transitions to a fully awake state and reestablishes a connection to the server (to its previously determined reconnect port), the server flushes any queued data back out to the client.
The reconnect, send data, and receive data processes compose the wedge we placed between the server application and the network connection. Figure 3 is an application-level block diagram of the reconnect process and its interactions with the send data and receive data processes. When the client is asleep, the reconnect process waits for a new connection from the client. When the client opens a new connection, we transition to "client is awake" state. The reconnect process accepts the new connection, sends the port number that the client should reconnect to for the next sleep/wake cycle, and spawns two processes—one to send data to the client and one to receive data from the client. The send and receive data processes execute in parallel, writing to and reading from the client independently. When the client transitions to a sleep state, the send and receive data processes cease executing and the reconnect process waits for the client to wake up and connect again. Because the server application itself never writes or reads directly to a socket, the sleep/awake transitions occur transparently, uncoupling the state of the application from the state of the connection.
