|
|
|
|
|
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.
Timeline
- Out: January 7th (monday)
- In: January 25th (friday)
- Submission guidelines will be posted soon on this page.
Preliminaries
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:
- 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.
- 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.
- 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 Home 
