-
Notifications
You must be signed in to change notification settings - Fork 20
Lab1Prfc
| Assigned | 3/6/2019 |
| Due | 3/13/2019 |
| Points | 30 |
For this assignment, you need to create a PRFC (Playground RFC) to specify a protocol that provides sessions and reliable delivery.
- Create a PRFC source file in XML that is renderable with
xml2prfc.tcl - Your document must identify a name for the protocol (in years past, we've had PCP, KISS, other fun acronyms)
- Your protocol must provide for session establishment
- Your protocol must guarantee delivery of packets with a session even in the presence of errors and dropped packets
- Your protocol must provide for packets that are delivered in-order within their associated session
- Your protocol must provide for the detection of non-malicious errors (e.g., errors caused by accidents and random chance)
- Your protocol must provide for packets that are either dropped or corrected if errors are detected
- Your protocol must provide for session teardown by either side that is sent reliably (meaning it is guaranteed to be received just like any other data packet). Once teardown is complete no further guarantees are made for either side
Take a look at RFC 793 for TCP (https://tools.ietf.org/html/rfc793). This is your template for your own protocol. Please pay careful attention to how the protocol is specified, including state machines.
You will notice that TCP’s RFC specifies many functionalities of TCP. You do NOT need to deal with multiplexing/demultiplexing (e.g., no ports). That is already handled. Your only job is to make sure that you specify a reliable, session-based protocol.
If you would like, you can also add in security features. The fact that TCP was written without security in mind haunts us to this day. Would you like to make your network more secure? Feel free.
But first, what is a session?
The Playground Wire Protocol is packet oriented. It is designed to get a packet from point A to point B. That is obviously very important and it works reasonably well for protocols that have very few communication exchanges. But as soon as two packets have to be related to each other, the Wire Protocol is ineffective. In other words, if the meaning of one packet is dependent upon a previous packet, the current Playground network just won’t work.
Because Playground’s wire protocol has ports, you can actually create a lot of protocols without an official transport layer, similar to what is possible with UDP.
Suppose we had one of our programming examples with the mathematics server. Although it was a little different, it could be described like this:
CLIENT -> SERVER: What is (3+4)*2?
SERVER -> CLIENT: 14
Each packet in this protocol is meaningless (or at least, cannot be considered “correct”) without the previous one. The final packet obviously, is only meaningful if the first packet is “what is (3+4)*2”
This would probably work somewhat in Playground even without a session, but only really by luck. Any “errors” of any kind would mess up the system. For example, suppose that the client crashed immediately after sending the question, and then immediately restarted. If it received the “14” answer, it would be very confused, but it would have no way of knowing that this packet was from a previous “session.”
What is needed is something like TCP. TCP creates a “session” for every connection. Before sending any data, TCP sends a handshake that indicates the beginning of a session, and then numbers all the bytes being sent. Different sessions have different numberings so it is unlikely that data from two different sessions could get mixed together indistinguishably.
What is reliable delivery? It means that every byte is delivered in-order and error free. If there are too many errors to deliver the data error-free, the connection should get torn down.
There is a utility in the class GitHub called src/prfc/xml2prfc.tcl. This utility can convert a specially formatted xml document into an RFC-like document. An example is included at src/prfc/p_rfc_1.xml1.
To create an HTML version of the test PRFC, run:
tcl xml2prfc.tcl p_rfc_1.xml p_rfc_1.html
To create a txt version, run:
tcl xml2prfc.tcl p_rfc_1.xml p_rfc_1.txt
You will need TCL installed.
Please note that the XML is very fragile. It’s easy to get it screwed up. Please write small-pieces and make sure it still converts before moving on.
You can find other examples here: https://tools.ietf.org/tools/templates/. Look, for example, at https://tools.ietf.org/tools/templates/template-edu-xml2rfc.xml for examples of ascii artwork.
The sample file will create PRFC 1. Please pay special attention to PRFC 1, which describes how you should write a PRFC.
As we discussed in class, do not write bit-oriented packet definitions. Instead use Playground packet types.
Your Lab #1 PRFC will be graded out of 30 points according to the following schedule:
20 Points for addressing all necessary issues. You MUST address the following:
- Purpose/technical background
- Session establishment
- Session termination
- Data transmission, including in environments with errors
- Error handling
- Packet descriptions
- Computational Algorithms (e.g., which type of checksum to use, etc)
- State machines
5 Points for thoroughness. We (the grading staff) will make a judgement as to how well someone could use your PRFC to implement a compliant protocol.
5 Points for grammar, correct punctuation, etc.