{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fswiss\fcharset0 Arial;}} {\*\generator Msftedit 5.41.15.1507;}\viewkind4\uc1\pard\f0\fs20 *************************************************\par SPECIFICATION EVALUATION\par Team: David Wolinsky, Jarret O'Shea, Ritwik Kumar\par *************************************************\par \par Ritu: (2 out of 5)\par 1. Name collision among servers is not handled.\par 2. In case of server failure, a resurrected server needs to perform neighbor discovery again but it is not indicated that this will be done.\par 3. while searching for a new node, a server which finds the node directly communicates with the searching node which is not allowed.\par 4. No mechanism to eliminates duplicate search request that are generated due to network topology.\par 5. Neighbors being alive is not checked.\par \par Rohin: (2 out of 5)\par 1. The confirmation phase of handling server name collision seems redundant.\par 2. During handling server name collision phase, any server can potentially talk to any other server in the network and thus violates the topology of the network.\par 3. why is list of neighbors exchanged during server discovery phase.\par 4. As the random number essentially decides the topology of the network, regenerating it every few second gives a shot at changing the topology of the network which should not be acceptable.\par 5. In server to server communication, search results are essentially being flooded to all the neighbors and this may lead to some packets floating in the network for ever.\par 6. neighbor list never distributed to clients.\par 7. case when server crashes and resurrects in not handled.\par \par Perez: (3 out of 5)\par 1. Server discovery is not discovered well.\par 2. During server recovery phase servers sends out chat room seed as authentication string but what about those clients which were not present in any room at the time the server died.\par \par Tapasvi: (3 out of 5)\par 1. At the time when a new server comes up, it is assumed that it can communicate with every other server which does not respect topology of the network\par 2. Neighbors being alive is not checked.\par \par Nitin: (1 out of 5)\par 1. It seems that this team has tried to fill up pages with relatively useless information. starting with 3 page introduction to UDP and then about 4 pages of repetition from project 1 and 2 write ups.\par 2. This submission seems to have NO original work. They propose DVMRP, an already existing protocol as solution to this problem and include no information specific to this project.\par \par Roncek: (2 out of 5)\par 1. Doesn't discuss how messages traverse the network\par 2. How server peers are setup is incomplete - lacks any real information, because it can cause an issue of servers joining and not being able to become peers\par 3. Doesn't discuss how nodes join the server, since clients no longer have to be in a chat room to connect to a server\par \par Bhavyan: (2 out of 5)\par 1. Doesn't discuss how to randomly choose neighbors\par 2. All servers communicate with each other\par 3. Lot's of messaging format missing\par 4. Doesn't deal with duplicate messages on multicast\par 5. Doesn't discuss how nodes join the server, since clients no longer have to be in a chat room to connect to a server\par \par Boada: (2 ouf of 5)\par 1. Difficult to read\par 2. Doesn't discuss search for peer mechanism\par 3. Doesn't discuss how nodes join the server, since clients no longer have to be in a chat room to connect to a server\par 4. Doesn't deal with duplicate messages on multicast\par \par Brian: (1 out of 5)\par 1. Look at it, there's nothing there\par \par Dube: (4 out of 5)\par 1. Overall nice, but as Piyush stated in class, when doing a search, the servers must traverse the same path they came from, no skipping communication steps\par 2. Bulked up the document by repeating project 1 and 2, makes for difficult reading\par \par Dugan: (3 out of 5)\par 1. like how the commands are broken out\par 2. how does this address the requirement that servers be able to find some servers, but not others?\par 3. I am unclear as to how to differentiate between messages that have the same parameters, such as "Server Connect" and "Server Hello" or, is the name of the command supposed to be included at the beginning of the message/packet\par 4. Server User/Agent list update: this seems like a lot of message passing for not a lot of benefit. Why do servers need to have user lists from every one of their neighbors? Allowing a server to recover its users after a crash could be done by adding another parameter to a user list, the home server.\par 5. Server/User Agent Query Ack: how does a server know whom to pass the message to? What is to stop the message from being passed infinitely?\par 6. there's no mention of a way to determine if a user on the network was "not found", i.e. that user doesn't exist\par \par Hwang: (4 out of 5)\par 1. clear diagrams\par 2. what happens if there is a name collision during server discovery?\par 3. how does a surrogate server know which users to give back after their original server has gone down?\par 4. there's no mention of a way to determine if a user on the network was "not found", i.e. that user doesn't exist\par \par Jindal: (4 out of 5)\par 1. structure of a server is unnecessary since that can be implemented arbitrarily, as long as it has certain functions\par 2. how does the directory service determine neighbors?\par 3. diagrams clear and understandable\par 4. like the idea of a directory service, but why does it need to send back usable multicast IPs?\par 5. there's no mention of a way to determine if a user on the network was "not found", i.e. that user doesn't exist\par 6. good explanations\par \par Pearson: (5 out of 5)\par 1. should not be able to get responses from ALL servers in the system\par 2. list of commands easy to read\par 3. there's no mention of a way to determine if a user on the network was "not found", i.e. that user doesn't exist\par \par Vaishnav: (5 out of 5)\par 1. tree structure might allow the find message to know when it has reached the end of the network, and thus a "not found" could be sent\par \par Reza: (5 out of 5)\par 1. there's no mention of a way to determine if a user on the network was "not found", i.e. that user doesn't exist\par 2. change the name of the command "connnoack"\par }