Protocol Design A new kind of resource, the ‘wocky' has been developed and users all over the world are keen to get involved in the action. Users can access remote wockies, and make local copies to update. Updates should be distributed to other copies of the wocky. Each node may store zero or more wockies. First of all, you need to design a location-independent naming scheme. From the characterization of protocols in the lecture of IPC decide which combination of attributes you need, that is text- or binary-based, etc. Design the requests and responses to and from wockies. Assume that wockies are created locally. To delete a wocky, several nodes might have to be contacted. Some commands sent to wockies are gyre, gimble, mimsy. Some queries – burble and whiffle - can be issued to find out some information about the wocky's current state. Some parameters that can be used for these commands and query are mome, galumph, slithy, vorpal. You should decide on some data types – integer, string, boolean. You need to consider Salzer and Reed’s End-to-End argument – how much of the reliability factor can you leave to transport protocols and how much must be handled at the application layer. Wockies are software artefacts and are subject to change. Your protocol must be designed to be future-proofed so that new messages can be added and existing message formats can be changed. Now you need to cover the three aspects of protocol design: Syntax – the format of the messages
Semantics – what do the fields in the message mean and error handling if that can’t be fulfilled
Timing – coordination between sender and receiver covering timeout situations. For syntax, such formalisms as EBNF could be used, although not required. For semantics, we could use formalisms such as denotational and axiomatic semantics, however, they would require a whole course to explain. The clue is in axiomatic. You can informally describe the axioms – the assumptions that are made for a correct system. For example a type given to a field is an axiom. “This field must be a string”. A tighter axiom would be “This field must be an ASCII string” - that is rather than EBCDIC or other character encoding. If you do not have this character type restriction, you would have to dynamically type the string with another field “string_type” which tells the receiver to interpret it as ASCII, EBCDIC, or UTF. This is what semantics is about – how the receiver interprets the message. For protocols, we also need timing – that is, how long do we wait until we can assume messages have been lost. You can express these with the timing diagrams we introduced in the IPC lecture. While this exercise is abstract in nature, you should use it to explore the techniques used in designing large-scale practical systems.