Note that these variables are not summed up like
Resource available ¼ Resource required À Resource used
ð19:6Þ
This is simply because “Resource used” is a derivative of TTL and “Resource
required” is defined by type of package during formation of package, while
“Resource available” is an internal property of a router. Note that TTL for real-time
packages should be set much tighter than for normal package.
In other words, if we have more time to deal with a package without “a stress”
the level of desperation is low:
Resource available ) Resource required À Resource used
ð19:7Þ
Then, the closer we are approaching the equality the higher level of desperation:
Resource available ! Resource required À Resource used
ð19:8Þ
And when
Resource available\Resource required À Resource used
ð19:9Þ
We are, obviously, already late. We might introduce a “probability” of
unsuccessful/successful delivery of package as
P i ¼ 1 À
P n
i¼1 x i
D
ð19:10Þ
where x i is a cost of i-th segment; D—“a diameter” of network, or full distance of
package transaction in it. This probability, in other words, indicates that the longer
we travel the less chances to be on time.
Equation 19.11, in turn, defines a workload for i-th package delivery in time
required from the network in terms of relative cost:
Begin: get all real time packages inside the router queues (might be several queues)
- calculate a derivative – how fast each package is approaching its limit of stay in
the router (it is possible to do very fast with 4-7Ghz processors in the routers)
- create the list of packages with order to pull out accordingly the “desperation”
- execute the most emergent ones
- return to the Begin
Fig. 19.2 Algorithm of desperation control
274
19 Distributed Systems: Resilience, Desperation
Resource available ¼ Resource required À Resource used
ð19:6Þ
This is simply because “Resource used” is a derivative of TTL and “Resource
required” is defined by type of package during formation of package, while
“Resource available” is an internal property of a router. Note that TTL for real-time
packages should be set much tighter than for normal package.
In other words, if we have more time to deal with a package without “a stress”
the level of desperation is low:
Resource available ) Resource required À Resource used
ð19:7Þ
Then, the closer we are approaching the equality the higher level of desperation:
Resource available ! Resource required À Resource used
ð19:8Þ
And when
Resource available\Resource required À Resource used
ð19:9Þ
We are, obviously, already late. We might introduce a “probability” of
unsuccessful/successful delivery of package as
P i ¼ 1 À
P n
i¼1 x i
D
ð19:10Þ
where x i is a cost of i-th segment; D—“a diameter” of network, or full distance of
package transaction in it. This probability, in other words, indicates that the longer
we travel the less chances to be on time.
Equation 19.11, in turn, defines a workload for i-th package delivery in time
required from the network in terms of relative cost:
Begin: get all real time packages inside the router queues (might be several queues)
- calculate a derivative – how fast each package is approaching its limit of stay in
the router (it is possible to do very fast with 4-7Ghz processors in the routers)
- create the list of packages with order to pull out accordingly the “desperation”
- execute the most emergent ones
- return to the Begin
Fig. 19.2 Algorithm of desperation control
274
19 Distributed Systems: Resilience, Desperation