Flow Charts & Psuedo Code Priority-based Distributed Floor Control Protocol for Collaborative Applications Cadet Tao-hsiang Chang, Dr. Shankar Banik Department of Mathematics and Computer Science The Citadel, The Military College of South Carolina Goals of the Protocal -First In First Out in high priority -First In First Out in low priority -Distributed Floor Control Flow Charts & Psuedo Code Request Bus Data Bus Receive Request Packet -- if(req_pack.p_used==1){ RQ_1++; if(req_pack.used==1) RQ_0++; } else if(p_msg_to_send==1){ req_pack.p_used=1; DQ_1=RQ_1; RQ_1=0; } else if(req_pack.used==1) RQ_0++; else if(msg_to_send==1){ req_pack.used=1; DQ_0=RQ_0; RQ_0=0; } -- Pass Request packet Receive Wake Up Packet -- if(wu_pack.used==1); else if(DQ_1!=0) DQ_1--; else if(p_msg_to_send==1){ wu_pack.used=1; p_msg_to_send=0; } else if(RQ_1!=0) RQ_1--; else if(DQ_0!=0) DQ_0--; else if(msg_to_send==1){ msg_to_send=0; else if(RQ_0!=0) RQ_0--; Pass Wake Up Packet Abstract Computer supported collaborative applications (video-conferencing, online games, distributed database replications) are popular among Internet users. One important issue in these applications is floor control. Some applications require that the priority of a user should be taken into account while assigning the floor. This implies that the user with higher priority will get the floor before the user with lower priority when both the users have requested for the floor. The rule First In First Out (FIFO) will be maintained if the users have the same priority. Moreover, this coordination should be done without any centralized controller. We propose a priority based distributed floor control protocol for collaborative applications. The Distributed Queue Dual Bus (DQDB) is used as the base of our protocol. We have implemented the protocol using Berkeley Socket Distribution (BSD) Application Programming Interface (API) and tested the protocol on the PlanetLab network. Results & Observation Five node used in the experiment: A: Boston University B: University of Maryland C: Japan Advanced Institute of Science and Technology (JAIST) D: Texas AM University E: National Taiwan University, Department of Information Management Five nodes are used in the experiment. The protocol is tested for different request generation rate at each node with different priority ratio. Average Waiting Time is used as the performance metric. From the results, it is observed that the overall average waiting time increases when the ratio of high priority and low priority floor requests increases. Examples of Protocol Execution Request Order: B0→A1 →D1 →C0 →E1 Expected Order: A1 →D1 →E1 →B0 →C0 (Notion: XY => X has requested a flow with priority Y) (RQ_1,DQ_1,RQ_0,DQ_0) A B C D E 1st Request Packet (0,0,0,0) (0,0,1,0) 2nd Request Packet (1,0,0,0) (1,0,1,0) 3rd Request Packet (0,1,1,0) (2,0,1,0) 4th Request Packet (1,0,0,1) (0,1,2,0) (2,0,2,0) 5th Request Packet (0,2,2,0) 1st Wake Up Packet (0,0,0,1) (0,0,2,0) 2nd Wake Up Packet 3rd Wake Up Packet 4th Wake Up Packet 5th Wake Up Packet Variables in Protocal Implementation On the Nodes:   General: When a node generates a request, it attaches a priority (1:high, 0:low). Node Variables: RQ_1: Number of requests with high priority before the node’s request. DQ_1: Index position of node’s request in the distributed queue for high priority. RQ_0: Number of requests with low priority before the node’s request. DQ_0: Index position of node’s request in the distributed queue for low priority. On the Packets: Request Packet: p_used: Identifies if the packet is used by high priority request. used: Identifies if the packet is used by low priority request.