Project #11: FiSh - Xinu File Sharing protocol

Submit: Turn in your entire xinu-hw11 directory source files using the turnin command on morbius.mscsnet.mu.edu or one of the other Systems Lab machines. Please run "make clean" in the compile/ subdirectory just before submission to reduce unnecessary space consumption.

Work should be completed in pairs. Be certain to include both names in the comment block at the top of all key source code files, with a TA-BOT:MAILTO comment line including any addresses that should automatically receive results. It would be courteous to confirm with your partner when submitting the assignment.

Preparation

First, make a fresh copy of your work thus far:
   cp -R xinu-hw10 xinu-hw11

Untar the new project files on top of this directory:
   tar xvzf ~brylow/os/Projects/xinu-hw11.tgz

You should now see the new project files in with your old files. Be certain to make clean before compiling for the first time.

The Ethernet Driver

This project tarball equips your Xinu kernel with a block-oriented, asynchronous ethernet driver for the router's built-in BCM4713 network interface. It follows the same standard device abstraction as we have seen in the TTY and disk device drivers.

File Sharing Client

The project tarball includes a starter stub for a fish command in the shell directory file shell/xsh_fish.c. FiSh is short for the simple Xinu File Sharing protocol.

Your fish command should provide three basic operations:

  1. Send a FiSh "Ping" packet -- which requests other FiSh nodes on the same network (the "school") to reply with their node name and MAC address;
  2. Send a FiSh "DirAsk" packet to a particular node in the school, requesting a listing of that remote node's filesystem directory;
  3. Send a FiSh "getFile" packet to a particular node in the school, requesting a file from that node's filesystem.

For the sake of simplicity, this project will not implement any of the standard networking protocols, such as ARP, IP, or other members of the Internet Protocol Suite. (Take COSC 4300 next fall if you would like hands-on experience with that!) As a result, our simple FiSh protocol cannot be used outside of the local area network the routers are connected to directly. The protocol does not protect against lost / corrupted packets, or allow any other network applications to be run on your router.

Our FiSh protocol runs directly on top of the Ethernet, using only Ethernet MAC Addresses and a made-up Ethernet Type, 0x3250.

Suitable constants and structures for the FiSh protocol are included in include/fileshare.h, and will be discussed extensively in lecture and/or lab. Your work for this assignment should be done in the files shell/xsh_fish.c and file/fileSharer.c.

File Sharing Server

The new main program launches both a shell process and a fileSharer process. The FileSharer process is a daemon (background process that provides a long-term service) that handles all packets arriving from the Ethernet device.

FileSharer classifies packets according to their destination (Is it for me? Is it for everybody?) and type (Is it FiSh Protocol?), and discards all packets that are not intended for the FileSharer process on the current node.

The FileSharer daemon implements a simple state machine. It answers FiSh "Ping" requests with a FiSh "Announce" reply. It answers FiSh "DirAsk" requests with a FiSh "DirList" reply enumerating the current node's directory contents. It answers FiSh "GetFile" requests with a FiSh "SendFile" or "NoFile" reply. Because of the simplicity of our protocol and our filesystem, each message can be sent in a single Ethernet packet.

In addition, the FileSharer daemon handles the results of requests initiated by the fish client shell command. (The fish command only writes to the Ethernet device; only the FileSharer daemon both reads and writes.) Thus, FileSharer daemon collects FiSh "Announce" responses from the school in an array where fish can find them. It collects "DirList" responses in a location where fish can list them. It receives responses to fish "GetFile" requests, and creates the requested files when received.

For simplicity, interaction between the fish client and FileSharer daemon within a single node is loosely coupled. One should consider how other interprocess communication primitives, such as a mailbox system, message passing, or signals, could be used to implement a more sophisticated file sharing service.


[back]

[Revised 2020 Nov 17 17:30 DWB]