Information Technology Reference
In-Depth Information
admit client via
next multicast cycle
send EXTEND request
IDLE
No
Yes
t
a
2
δ
?
A C >
1?
Yes
m
+
1
i
No
Legend
received
START reply
State
Yes
A C = 0?
STARTED
update {A C , A L } and
send START request
Decision
Action
No
Event
update {A C , A L }
Figure 19.3 State-transition diagram for the admission controller
multicast channel, or should start playback with a dynamic multicast channel. In the former
case, the client just waits for the next multicast cycle to begin, without incurring any addi-
tional load on the backend service nodes. In the latter case, the admission controller performs
additional processing to determine if a new request needs to be sent to the appropriate service
node to start a new dynamic multicast stream.
Figure 19.3 depicts the state-transition diagram for the admission procedure. Beginning
from the IDLE state, suppose that a new request arrives at time a i , which is between the start
time of the previous multicast cycle, denoted by t m , and the start time of the next multicast
cycle, denoted by t m + 1 . Now a predefined admission threshold, denoted by
, determines the
first admission decision made by the admission controller: the new request will be assigned to
wait for the next multicast cycle to start playback if the waiting time, denoted by
δ
w i , is equal
to or smaller than 2
δ
, i.e.
w i =
t m + 1
a i
2
δ
(19.2)
We call these requests statically-admitted and the admission controller returns to the IDLE
state afterwards. This admission threshold is introduced to reduce the amount of load going to
the dynamic multicast channels. Optimization procedures for this admission threshold will be
presented in Section 19.3.3.
If equation (19.2) does not hold, then the admission controller will proceed to determine if a
request needs to be sent to the appropriate service node to start a newdynamicmulticast stream-
dynamically-admitted . The service nodes and admission controllers each keep a counter-length
Search WWH ::




Custom Search