M.I.T. DEPARTMENT OF EECS
|6.033 - Computer System Engineering||X Windows Hands-On Assignment|
Having read the sections of the X Window System paper assigned for Recitation 6, complete the following hands-on assignment. You should do the activities described below, answer (only!) the numbered questions, and hand in your answers at the beginning of class on Tuesday, February 22.
The purpose of this assignment is to give you some hands-on experience playing with the details of the X Window system. In particular, by the end of the assignment, you should have a good understanding of how to use X and how X manages complexity using modularity (through the client-server architecture).
This assignment should take one to two hours at most. Please turn in answers to the questions asked only! Do not submit pages of output from the various commands.
To do this lab, you'll need to use the program xmond. We have
compiled and installed xmond in the
locker on Athena, which can be accessed by typing
6.033 at an
athena% prompt. Athena's
add command sets your environment up so you can run
compiled programs by name out of a locker. (The 6.033 locker is a
/mit/6.033 that is stored on a central
We strongly encourage you to do this assignment physically sitting in front of an Athena workstation. You may run into problems related to X authentication if you try to run remotely.
The design of X has led it to be highly configurable and customizable. To begin understanding some of this, skim the man page for the X window system:
Create an xlogo (command:
athena% man X
xlogo) with a different background and foreground color from the default. Make it 300 by 400 pixels in size and start out in the lower left corner.
Question 1: What arguments did you pass to xlogo?
Now, let's get our hands dirty playing with some of the more technical parts of X. Section 3 of the X Windows paper discusses the network protocol that X clients and servers use to communicate. We'll use xmond to examine the content of a conversation between a simple X client and the X server running on your machine.
Before running this tool, consider how it works. To intercept communication between an X client and an X server the tool acts as a proxy. A proxy acts as a forwarder: it accepts requests from a number of clients (possibly modifying them) and forwards them to a server. A common type of proxy you may have used is a caching Web proxy which accepts Web page requests and attempts to fulfill them from a local store of pages, before fetching the page from a remote server.
Question 2: Describe where an X proxy most logically fits into the box-and-lines diagram shown in Figure 1 in the X Windows paper. Since there are multiple possibile locations, describe why you think the placement you selected is the best solution. List the changes, if any, that such a proxy would require in the client code, server code, and user environment.
Question 3: From the perspective of an X client (like xlogo), is the proxy a server or a client? What about from the perspective of the X server?
We'll need two xterms to make all of this work. An xterm is a terminal emulator for X; it's a place to type commands and see their results. To launch an xterm, type the following at an athena prompt:
athena% xterm &
xtermpart means to run the program named "xterm". Normally, the shell (the program that prints the
athena%prompt and accepts your commands) would wait until the xterm exits before performing your next command. However, the ampersand at the end of your command tells the shell to go ahead and accept new commands without waiting. That is, the shell runs the first command asynchronously, a concept that we've seen in lecture and will see again in a different context in section IV, below.
Start two fresh xterms, which we'll call "left" and "right". In "left", run the following:
athena% xhost +localhost
localhost being added to access control list
athena% add 6.033
athena% xmond -server localhost:0 -port 20 -verbose 4
xhostcommand allows unauthorized clients (such as the proxy) to connect, but only from the same host; normally such connections would be rejected.
xmond command starts up the proxy, which won't
produce any output until it receives an incoming connection. (You
shouldn't expect the command prompt to come back in the xterm until
you quit the
xmond program by typing "quit" followed by
the enter key.)
-verbose 4 flag tells the proxy to print every
message it sees in great detail. You can tune exactly what is printed
by interacting with the proxy. For instance, typing "event_verbose 0"
into "left" while xmond is running will instruct the proxy not
to print information about X events. Type "help" to get a full list
of commands that xmond supports. The
port 20 flag
tells xmond what to name the ("fake") server it sets up. In
this example, xmond is acting as a server for a display identified as
Now we'll generate some events for xmond to print. In "right", type the following:
This command runs an xlogo which connects to xmond instead of to your real X server. After you run xlogo, you should see a trace of the messages it is sending to the X server in "left". Here is a snippet from what that trace might look like:
athena% xlogo -display localhost:20 &
All requests have a sequence number which identifies them and allows the client to match replies with requests. This particular command draws a polygon, and the request contains the coordinates of the polygon. The request was generated by a subroutine named "XFillPolygon". For further information about XFillPolygon and other common X drawing commands, see the XFree86 documentation. Since (0,0) is the top-left corner of the window, by examining the coordinates in the request, we can guess that this command draws the top-right to bottom-left stroke of the X in the logo.............REQUEST: FillPoly sequence number: 0026 request length: 0008 drawable: DWB 06c00004 gc: GXC 06c00003 shape: Convex coordinate-mode: Origin points: (4) x: 91 y: 0 --- x: 88 y: 0 --- x: 9 y: 100 --- x: 12 y: 100 ---
In the second paragraph of page 87 in the X Windows paper, the authors say that they chose to use an asynchronous communication system. That means that, after a request is issued, the client is able to send other requests without waiting for a reply from the server, just as the ampersand to the UNIX shell allowed you to start other commands without waiting for the first one to terminate.
Question 4: Look at the trace from the xlogo startup and find examples of two types of requests -- one that generates a reply from the server and one that does not generate a reply. Choose requests which are not X events (events are marked with the EVENT tag in the trace). What are the types of the two requests you found? (The request type is printed after "REQUEST:" in the trace.)
Question 5: Can you generalize about what sort of commands do not require a reply? Why doesn't the X protocol send all requests synchronously? (Be concise in your answers -- a couple sentences are sufficient.)
It may be helpful to redirect the output of xmon to a file to answer these questions. Try something like:
You can now open
athena% xmond -server localhost:0 -port 20 -verbose 4 > trace.out
trace.outin your favorite text editor. (For example,
Now we'll see how well you understand the request/reply stream. Set up
xmond as before, and instead of running the "stock" xlogo, run our
xlogo-6.033 in the 6.033 locker. You'll
type this into "right":
We've changed this xlogo to draw a hidden text string to the X server; that is, the client will issue the XDrawString call to draw the string, but you won't see any text on the screen. By examining the trace, you should be able to find this string.
athena% add 6.033
athena% xlogo-6.033 -display localhost:20 &
Question 6: What is the string that the modified xlogo draws? (You may not open the binary or run 'strings' or 'grep' or similar commands on the binary to answer this question.) Include the portion of the trace that helped you answer this question (and nothing more).
Question 7: How long did it take you to complete this assignment?
|Go to 6.033 Home Page|