Terms of Bonus Assignment

Read the following sections carefully to ensure that you know what is to be done and what is to be handed in. If the details aren't addressed successfully you will lose marks. Please refer to the coding style guidelines to provide direction regarding the format of the code you write. You are expected to work independently on this assignment (please see academic misconduct in computing for clarification if necessary).

Consider any "basic" program that uses sockets (such as assignment 3). Note that you need to have good knowledge of the behaviour and functionality of the core function calls (as you're designing something that behaves just like them): socket, bind, listen, accept, connect, select, close, send (or write) and recv (or read). You should make sure you have a very clear understanding of what all these functions do.

The Problem

Your task is to implement the basic operations on sockets listed below, (and only those operations), i.e. socket, bind, listen connect, accept, select, close, send (write), receive (read), using operations on files as a prerequisite (assume that wherever this code would be run, the same file system is visible consistently to all machines on which you might run it). The semantics of your versions of these operations should be close enough to their original semantics for the example to execute smoothly in the new environment. Note that any similarly constrained BSD-style socket code should work equally as well with this library. Assume the library would be written in the C programming language.

Desgin Guidelines

• Any suitablely restricted code (again, A3 for example) should work in a way indistinguishable from its present behaviour when using your library rather than the system calls normally available.

• Of course, you may assume that the domain of your solution is restricted to the local NFS (network file system) domain. Your sockets do not have to be visible across the Internet.

• Busy waiting is not permitted.

• Your solution should not require any special initialization (e.g. creating certain files before execution) to be performed manually before your tool becomes usable. Note that any initialization of this sort can be done automatically, e.g. when socket is invoked for the first time.

Deliverables

• Documentation:
  • Documentation should include:
  • Statement of the problem solved
  • Detailed design of your system. You must be clearly presenting all relevant details in your system to make it unambiguously clear how all the various components fit together, and how the system functions correctly. It can not be overstated how important the clarity of your design is. Make use of diagrams, figures, whatever it takes so that a technical person is capable of understanding and verifying what is happening. Long, meandering, unstructured paragraphs in which you spew train-of-thought does not convey this level of detail.
  • Decisions/assumptions/justifications: state any assumptions you made in solving the problem and known limitations of your implementation; justify the design decisions you made in the previous section (i.e. why a particular approach and not another?).
  • Documentation must be provided in PDF format (text is unacceptable unless you really are good with drawing/presenting information in ASCII---be warned), and only that format will be accepted. Do not submit Word documents or any other random things you feel like. The file should be named ABonus_docs.pdf.
• Electronic submission:
  • The above document submitted through the Moodle system as described in the submission guidelines for the course. Please gzip or zip the file if it is very large.