Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼


Green Telnet

Jeremy is a student in the Department of Computer Science and Engineering at the University of South Florida. Ken is a Professor in the Department of Computer Science and Engineering at the University of South Florida.

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.

Figure 1: Power state change notification.

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.

Figure 2: gtelnet packet showing new gt field.

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.

Figure 3: Server application-level process interaction.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.