CSC 145/290 Final Project: The "Spyring" Protocol For this assignment, you should imagine yourselves as spys who must pass information along a ring. Each "agent" will be given an identifying number: 0: Maureen Kelly Bohdan W. Yi Liu 1: Vamsee Maria Ying Zi Hao Leon Miu 2: Thomas Re Allen Koski A. Ghaffar Andy 3: J. DeJose G. Salerno F. Rosario P. Dolinski 4: L. Jackobson Randeep Butalia Yi-Fei Chi K. Duncan 5: The Evil Professor The basic idea is to form a circle (wrapping around to 0). Each agent will have a unique "contact" as well as a "contactee". For example, agent 4's contact is agent 0, and is contacted by agent 3. If agent 3 wants to send a message to agent 1, it must go through 4 , 5 and 0. Got it? There are three principal components for this assignment: COMPONENT 0: RING ESTABLISHMENT PROTOCOL: For discovering where your "contact" is, we are going to use the local multicast group 224.0.0.145, port 53000, on the 147.4.180.0 subnet. You don't have to worry about relaying the multicast to different subnets, therefore, you MUST use one of the computers on the 147.4.180.0 subnet (husun3 plus all the "ultra" machines) - at least during the final demonstration. Once you choose a machine and a port (you can choose any non-reserved port). You need to send a message to the multicast group informing other active agents that you are now also active, and what your ip address and port numbers are. You will get as reply similar information as to where to find your contact. You need to try to first find your designated contact. If you get no replay after 2 seconds, you should try to use the next agent in the ring as your contact. For example, if you're agent i you will first send a packet looking for agent i+1%4. But if you don't get a reply from i+1%4 in 2 seconds, you will repeat the process, this time looking for agent i+2%4 as your contact. MAKE SURE YOU READ THIS CAREFULLY: port 53000 on the 224.0.0.145 multicast group is reserved for the purpose of ring establishment ONLY! You will use ANOTHER port (any port you like) for actually sending/receiving data between the agents. The multicast packet format for ring establishment is as follows: byte 0 : first (most significant) bit == 0 if it's a request, 1 if it's a reply bits 1-7: source agent id (id of agent who sent this packet) if packet is request, this would be your agent id. if packet is reply, this should be id of someone's contact byte 1: destination agent id (id of agent message is intended for) if packet is request, this byte should be the agent id of someone's designated contact. if packet is reply, this byte should match the agent id of the contactee. bytes 2-7: if packet is request, these bytes should be your ip followed by port in network byte ordering. if packet is reply, this should be the ip and port of someone's contact. Your program must not only send out this packet, but also must be listening for packets that are sent to the multicast address. You must be sensitive to two kinds of such packets: 1. a packet that is trying to find you as its contact. For example, if you're agent 2 you could get a request packet from agent 1 (or agent 0 if 1 is not up). You should respond with appropriate info. 2. a request packet from an agent that just became active, and whose agent id goes between your id and the id of your *current contact*. For example, let's say you're agent 2, and when you came on, agent 3 was not up, so you use agent 4 as your contact. But now agent 3 becomes active, and issues a request to find its contact. You should realize from this that you should now use agent 3 as your contact (you don't have to reply in this situation). MAKE SURE YOU UNDERSTAND: you must be sensitive not only to multicast packets that has your id as the destination id, but also request packets from agents that just came on line, and whom you should use as your new contact. COMPONENT 1: RING COMMUNICATION PROTOCOL You need to be able to pass information around the ring to other agents. Make sure you understand the purpose of the above section, otherwise you won't know where to find your contact. Here is the format of the packet that you will send: byte 0: source (your) agent id byte 1: destination agent id byte 2: Hop Count (see below). byte 3: message length in bytes (max 255). bytes 4- : message content. When you receive a packet with destination id that is not your id, that means you must forward it to your contact. You must also to the following: before forwarding the packet: Decrement the Hop Count by 1. If Hop Count becomes 0 after decrementing, then discard the packet. When you send out a packet, you should set the Hop Count to 5. The purpose of the Hop Count is to prevent a packet from circulating forever. It also indicate if your message did indeed go through other agents. Check if the source id matches your id. If they do, it means that a packet you sent came back without being picked up. In this case, you should reset Hop Count and resend the message AFTER A WHILE. If you get a message that was indeed meant for you, then you should save the content of the packet to a file, and record in the file from where you got it from. You can just create a single file and keep appending new messages to it. In addition, you should also report and record packets that you have been forwarding (just store the source and destination id's and the hop count). This will allow us to see if the ring is really working the way it's supposed to. COMPONENT 2: INTEGRATION AND USER INTERFACE You should have one program. The two components above should probably be written using separate processes and threads. If threads need to store information (such as changing the contact), you should be sensitive to the critical section problem. You may also use select if you can work out all the details. I recommend threads. You should print out messages when you receive them (in addition to saving message to file). You should (perhaps in another window), prompt the user to enter messages to send over the network. Dates: Thursday 12/6: There will be a short QUIZ concerning the specification of the assignment. Everyone in your group should study this document thuroughly and understand the protocols you need to implement. Tuesday 12/11: Last day of class: you should have the first component completed, and be well into the second component. I will be checking your progress. Before the final due date, I will schedule an extra help session at least once. The final due date for the assignment will be during the schedule time for the final exam. You will be asked to run your program and demonstrate that it works. Each agent will be given a byte sequence to send around to all other agents. When all the sequences are XOR'ed together, a coherent message will appear. --------------------- Clarifications: When you send a packet requesting information about your contact, the packet is sent to the multicast group. But the reply is sent directly back to you, NOT to the multicast group. For example, you will probably send the packet with something like sendto(fd,buffer,size,0,(struct sockaddr*)&mcastaddr,sizeof(mcastaddr); Where mcastaddr holds the ip and port of the multicast group. A host listening on the multicast ip:port gets this request with something like recvfrom(fd2,buffer2,size2,0,(struct sockaddr*)&senderinfo,&length) That is, the *source* ip and port you sent the request from will be captured in the senderinfo structure. The host can therefore use this structure to respond to you directly (through the same socket). There is no need to also send the reply to the multicast group. Please note that I will be agent #5 (so there will be 6 total agents) and that I will be using husun3. Do not use husun3. Use one of the Ultra machines. Use netstat to make sure that port 53000 is not being used by another agent before starting. ---------------- The following scenario can occur: agent 2 sends out probes for its contact (3, 4, 5, etc ...). at the same time agent 1 comes up and probes for 2 agent 2 might not be able to respond to 1 at this point, for it may not begin listening to incomming multicast messages until a later point. This is ok. Ideally your program should deal with this situation, but I will not require it. Depending on the structure of your program, it may or may not be trivial to take care of this case. Reduce the wait time between probes down to 1 or 2 seconds as opposed to 15 seconds. You may also periodically rebraodcast (to the multicast group) information as to where you are, so as to both: a: confirm that your contact is still alive, and b: tell new people where you are, in case there are anomalies such as the scenario described above. ------ Misc. hints: finger @ultra5, for example, will let you know who's currently logged onto ultra 5.