CSE logo University of Washington Computer Science & Engineering
 CSE 461: Computer Communication and Networks (WInter 2008)
  CSE Home   About Us    Search    Contact Info 

Course home
 Using course email
 Email archive
 Lectures and readings
 Section and tutorials
 Midterms and exams
Lab information
 Getting lab accounts
 Unix tutorials

Phase 1: Sockets

The goal of the first assignment is to become familiar with the N800 as a development platform, and to understand one of the most basic constructs in network programming: sockets.


  • Out: January 7th (monday)
  • In: January 25th (friday)
  • Submission guidelines will be posted soon on this page.


The N800 runs linux, and so writing applications for the N800 is essentially the same as for any other linux box. However, being a handheld device, the N800 is not endowed with a beefy processor. This means that a CPU intensive task (like compiling your code) would be rather slow on the N800. The solution to this is to use cross-compiling: the code is compiled using a special compiler on your regular desktop machine, but the binary produced can be run on the N800. Your first task is to familiarize yourself with the maemo-sdk cross compiling toolkit, and the steps involved in getting a simple program (say 'Hello World!') to run on the N800. For getting started, do the following:
  • install xterm, openssh, wireless-tools on your nokia n800
  • login into your n800 and issue commands to manipulate network devices (such as list accessible access points, put wireless device in various modes, etc.)
  • install cross-compiler development environment on a desktop (using a vm), compile a simple program, copy it on to the n800 and run it.
A companion page will provide more details on how to get started.

What To Develop

The eventual goal of this project is to enable the following form of user activity: Users walk around with their N800s. They can use a GUI to determine nearby N800s that are accessible through wireless connectivity. Users can obtain directory listings of files that their neighbors are willing to share. (Files could be, for instance, music songs with descriptive titles.) Users can then select and download specific files, which then become part of the local repository and are in turn shared with other nearby users.

You will work in groups of two for this project (and for subsequent parts of it) to develop a peer-to-peer application that enables the above behavior. Your team's code needs to be inter-operable with that of the other teams, and we propose to achieve this by "standardizing" the protocol used to communicate between the devices. (The code can be different, but if the protocol is the same, then the different versions can inter-operate.)

In this project page, we will specify the inter-node communication protocol and also provide guidance on a preferred implementation strategy. We also encourage you to develop most of the code on desktop Linux PCs before migrating to the N800s. The N800s, while great devices, are a bit cumbersome for the development process -- you will have to cross-compile the code on desktops before copying them over to the N800s, identify buggy behavior, correct the bugs and repeat the whole process over. Clearly, it would be easier to have the complete working code on the desktops before migrating to the devices.

In phase 1 of the project, each node has to: 1) discover its neighbors and 2) support commands to provide directory listings and communicate specific files. You can break up the work into the following components:
  1. Setup: Put your wireless adapter in ad-hoc mode, and set it to a local IP address. (// specify the essid and IP addresses). This is not required for testing the code on desktop PCs, but only when you port the code to the N800s. Commands for doing this will be provided.
  2. Server: Run a server that performs the following tasks:

    • Periodic Beacon Messages. Your node must periodically broadcast packets indicating its presence. Use the UDP protocol and include the following information in the packets. (Refer to the sample code on how to create UDP ports, broadcast UDP messages, and receive UDP messages.)

      • My identifier
      • My MAC address
      • My IP address
      • Port to contact me on

      As a tip, you will need to use timers to implement continuous, low-rate background activity. Be very careful with automated mechanisms, especially when using broadcast! They should operate on the timescale of at least tens of seconds.
    • Process commands from other nodes. The server should also listen on the contact port (which is included in your broadcast message) for incoming commands. More specifically, it accepts TCP connections from clients and responds to two commands:

      • Directory Listing: The server returns the names of 'shared' files. The shared files are those that are present in a specific directory. You can populate the files in the directory either by copying files into it or by using the client (described below) to download files from nearby nodes.
      • Get File : The server sends the requested file if it is available in the local store.

  3. Client:Write a client program that performs the following tasks:

    • Neighbor Discovery. Passively listen for broadcast beacon messages from nearby nodes. Keep track of which neighbors are currently within range. Note that neighbors will disappear as well as appear. You will want to print out the current list of neighbors so you can see who they are, perhaps only printing when there is a change.
    • User interface. Accept commands from the user to enable the following tasks. a) Connect to a nearby node and obtain the directory listing of files shared by the node. b) Download a particular file from a nearby node. In both cases, the client would connect to the appropriate server using a TCP connection, obtain the necessary information and either display the directory listing or store the fetched file in the local store. We will provide a GUI template that you can use to develop a graphical interface to the client on the N800s. For initial development and debugging purposes, you can rig up a simple text-based interface for the desktop version.

Packet Formats

The packet format for the Broadcast UDP message is as follows:
  • Identifier: 4-byte int. (Useful to isolate your code from that out of other teams during initial development. Specify your own identifier.)
  • MAC: 12-byte string with the Hex representation
  • IP: 4-byte int
  • Port: 4-byte int

For the client-server part, the message format is as follows:
  • The first byte of the request is the size of the request in bytes, including this one. The second byte is the opcode, and the remaining bytes will provide additional information about the request.
  • If the opcode is 0x01, the server responds with the list of shared files, separated by '\n', and terminated by closing the connection.
  • If the opcode is 0x02, then the rest of the message is the name of the requested file. In the server's response, the first 4 bytes contain the size of the file in bytes, or -1 if the file is invalid. The remaining bytes correspond to the contents of the file.

Note: All the integers in the packets have to be in network byte order to ensure portability and compatibility.

Sample code

There is an excellent tutorial for socket programming here.

In addition, we have provided a number of code snippets to get you started:
  • Code for broadcasting and receiving UDP packets.
  • Code for a client and server communicating using TCP sockets.
  • Code for a multi-process server, one that forks of a separate process to handle each incoming TCP connection.
  • Code for using threads in C; one thread updates a shared variable, while another thread waits for it to complete and then reads the value.
  • Tarball for GUI and Makefile.
  • Tarball for Sample Solution.

CSE logo Computer Science & Engineering
University of Washington
Box 352350
Seattle, WA  98195-2350
(206) 543-1695 voice, (206) 543-2969 FAX