Dr. Dobb's Journal - November 2008 - (Page 36)

Core Technology Figure 4: gtelnetd in action. intermediate queue and writes it to the client’s socket. The send_data() function is in Listing Two. Lines 18 and 19 ensure that the client is still awake and awaits notification of the server application placing data in the queue. The condition on the loop breaks when the client_wants_ sleep flag is set to True via the signal handler that catches a notification from recv_data() of the client transitioning to a sleep state. Next, starting on line 22 we loop through the intermediate queue, sending each message placed into the queue by the server application to the client. Lines 25 through 29 mark the replay buffer used to sync any data that had its transmission interrupted by the client going to sleep. Lines 30 through 44 simply close the queue if the client goes to sleep prior to transmission of all data in the queue, while lines 46 through 48 close the queue upon successful transmission of all its data. Changes to the Telnet Client The telnet client has two major changes. Similar to the server, the client has a rolling byte count that keeps track of how many bytes of data it has received from the server. More importantly, however, the telnet client also has a thread that receives notification from the host operating system when the (client) machine changes power state. For 36 Dr. Dobb’s Journal l www.ddj.com l November 2008 the client to notify the server of changes in power state, the client must receive these changes from the host operating system. We have provided two possible implementations for this. The first implementation works on Ubuntu Linux and utilizes a script that is invoked by the host operating system’s sleep and wake power management scripts. The script simply connects to each running client and passes the state change on. Our second implementation utilizes the power management API of Mac OS X. In this case, the client receives power state change notification directly from the operating system. Once the client has been made aware of a change in power state, it simply passes the notification up to the server with a gtWSLE or gtWWAK message. When the client wakes up, it reconnects to the server and performs a two-step information exchange before normal communication resumes. As in Figure 1, the client first receives the next reconnect port number from the server. The client then sends the server its byte count, which the server uses to calculate any data discrepancies. The client then resumes normal operation. If the server determines that any data has to be resent to the client, the client receives it via normal communication channels. That is, while the data may have originally been sent by the server prior to the client going to sleep, if the client missed this http://www.birdstep.com/database http://www.ddj.com

Table of Contents Feed for the Digital Edition of Dr. Dobb's Journal - November 2008

Dr. Dobb's Journal - November 2008 Contents Friday Night Fish Fry Alia Vox Developer Diaries Developer's Notebook Saving Open Source Conversations iPhone Building Your Own Web Server Green Telnet What's New In Boost Threads? Testing Service Oriented Architectures Test Case Generation, UML, and Eclipse Unit Testing Web Services C3 Programming The Agile Edge Swaine's Flames Effective Concurrency

Dr. Dobb's Journal - November 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.