Given below is the general format to be used while writing your reports. Please try and stick to this format, including using the same section/subsection headings as given below where appropriate. The UI features listed under bullet 1.b below are not the main focus of the assignment, so it's okay if you skimp on this, but in this case, we expect you to make up in the other parts of your project (e.g., extensive theoretical/experimental analysis to show that your system gives good performance) The total length of the report (exclusive of the security/privacy writeup) should be less than 10-15 pages. 0. Introduction / Description a. A short paragraph with a 1-2 sentence description of your project, and a short summary (or even a plain list) of the "selling points" of your application. Examples of selling points could be high-throughput, support for highly dynamic group membership, support for dynamic content transfer, heavy user interaction, advanced UI/graphics, etc. During the demo, you'd want to demonstrate a good bunch of these salient points of your app. And in your performance analysis (below), you should quantitatively evaluate and analyze how well your system performs along these metrics of interest. ** Also indicate here if you are using this for CS790 MEng credit or not ** b. Reasonably detailed description of the design and architecture of your system: Feel free to include illustrating figures and screenshots. If you wish, you may provide the meat of the entire report here, and just have very short paragraphs for the other sections in the report (that are basically pointers to this description), but this is entirely up to you. 1. Compliance with the Web 3.0 paradigm. a. Required: i. Player Interactions. In what sense is the content "interactive"? Can we interact with other players in some meaningful sense (see them, hear them, see the results of their actions at the same time we're doing something). An example of something that is not live and interactive would be a music kiosk or a movie download site such as YouTube. ii. Distributed Content. In what sense is the content "distributed" and in what sense does the system comply with the peer-to-peer paradigm? Are players communicating directly, using multicast or similar technology? b. Optional: i. Web-style Browsing. In what sense does the project implement a "web" of something? Does the system provide some sort of a browsing experience, where users "navigate" between a web of content of some sort (such as rooms in a game, documents to edit, chat sessions, virtual video projections etc.) freely, and can access the content available in the system by just "browsing" into it, and without the need to set things up? An example of something that is not a web would be a game where five players have to communicate beforehand, start their processes at the same time, negotiate IP address settings etc. ii. Does the project support modifiable content, where content can be modified and these changes persist (you drop an object in a room and it's there next time you come back etc.). Does it support "Live Content", where content is live (the room "lives", dog barks, birds fly etc., something is happening all the time irrespectively of what the actions that players themselves engage in). iii. "Cool" Content. Content is visually attractive, realistic (3D or nice-looking 2D cool graphics etc.) etc., or otherwise shows that the developers invested some nontrivial amount of time in making it the way it is. 2. Efficient use of the available technology. a. Stress The Tools. Using lots of multicast groups in a smart way, sending data at high throughputs (e.g. streaming audio or video), and other ways of stressing the underlying multicast toolkits, or whatever else is used by the players to communicate, to get the most dynamic and "live" system given the available resources. b. Ingenious Use of Tools (Bonus). Ingenious uses of multicast, or other tools, to implement decentralized, live web 3.0 content in a way that wasn't described in the class, are a definite, big bonus. 3. Correctness (penalties) a. Corrupt state. Can state get corrupted? Can players see inconsistent outcomes etc. (e.g. because of lack of adequate reliability guarantees, race conditions etc.). b. Bottleneck. System doesn't scale in obvious ways (e.g. due to misusing the tools, resulting in a central bottleneck of some kind, such as tunneling large amounts of information or keeping state on a centralized game server etc.). c. Is the system tolerant to users joining and leaving arbitrarily? 4. Optimizations (bonuses) a. More Peer-to-Peer. Ways to reduce reliance upon the server, e.g. upon accessing live content, players obtain its state from other players rather from the server. The same for discovery (Eg: during startup) b. Any non-trivial decisions that you took, beyond straightforward use of the underlying communication layer. Similarly, does your system include any significant components/chunks of code that are not straightforward uses of the underlying tools? In either case, explain the rationale behind your choices: What benefits do you derive / what pitfalls do you avoid by doing these; why is it better than just using the tools unmodified? 5. Discussion a. Understanding Mechanisms. What the different pieces of the architecture assume and ensure, and why etc: i. What reliability is expected of the underlying communication layer, and how does this play with the design? E.g. Is the reliability too weak or unnecessarily strong for the application that you have built, why it's so, what is done to compensate for it, how else it could be designed etc. ii. What part of the system is key to scalability and why, what is done to make it scalable, how much it would scale, and when it would break etc. 6. Writeup on Security / Privacy included? (Required for cs790 MEng projects) Just indicate a yes/no response here; the security/privacy writeup should be in a separate document. 7. Evaluation a. Performance analysis: This preferably should be in line with the chosen salient points in Bullet 0. E.g: Demonstrate high-throughput / dynamic membership / other selling points of your system. b. Obligatory conclusion for each item of data: For each plot/table presented, have at least a 1-2 sentence summary of what the data demonstrates, why we would be interested in looking at it. c. (Bonus) Do (a) and (b) above for multiple dimensions. E.g: Look at throughput as a function of number of users in group, throughput in the presence of users joining and leaving, etc. 8. Documentation a. Is there (somewhere else, not here) some sort of adequate documentation that walks a person through the process of installing the game and getting it to run without having to contact the developers.