1. 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.