Routing Protocol for Mobile Networks Initial Route Construction Phase

(submitted to the ACM Journal on Wireless Networks)

A Reservation-Based Multicast (RBM)

Routing Protocol

for Mobile Networks:

Initial Route Construction Phase*

M. Scott Corson University of Illinois at Chicago EECS Dept. (M/C 154) 851 S. Morgan, Rm. 1120 SEO Chicago, IL 60607-7053

(312) 996-2633

corson@https://www.wendangku.net/doc/c213511893.html,

Stephen G. Batsell

Information Technology Division

Naval Research Laboratory

Washington, DC 20375

(202) 767-3834

batsell@https://www.wendangku.net/doc/c213511893.html, Abstract

We propose a combined multicast routing and resource reservation protocol, termed Reservation-Based Multicast (RBM), that performs routing in a fashion similar to Protocol Independent Multicast (PIM), but which is intended for mobile operation and routes hierarchically-encoded data streams based on user-specified fidelity requirements, real-time delivery thresholds and prevailing network bandwidth constraints. The protocol retains the fully distributed operation, scalability and receiver-initiated orientation of PIM; but, unlike PIM, the protocol is tightly coupled to an underlying, distributed, unicast routing protocol thereby facilitating operation in a dynamic topology. This paper focuses on the initial route construction phase, assumed to occur during a static "snapshot" of the dynamic topology, and is therefore applicable to fixed networks as well, e.g. the Internet. A forthcoming paper will detail the protocol's robustness and adaptivity to arbitrary topological changes during both initial route construction and subsequent route maintenance and rediscovery.

Keywords: multicast routing, resource reservation, real-time delivery, quality-of-service, hierarchically-encoded streams, mobile networks.

* This work sponsored by the U.S. Navy and the American Society for Engineering Education under the U.S. Navy's Summer Faculty Research Program.

1. INTRODUCTION

We consider the problem of maintaining multicast communication in a mobile network. In our model, a collection of mobile communicating entities is distributed across a mobile network of processors. At any given time an entity is associated with a processor, but is free to change its association (by moving) as desired. Each entity is a potential source of a hierarchically-encoded, multicast transmission to be delivered to a subset of interested entities as in [1].

Three applications motivate our multicast problem: Distributed Interactive Simulation (DIS) [2], wireless communications and mobile Internet Protocol (IP) operation. In the first application, the entities correspond to mobile software processes or objects that need to periodically communicate their state to a subset of other entities in the simulation, each communication being a one-to-many multicast. These entities execute on or are contained in mobile processors which participate in the simulation. In the second application, the entities correspond to fixed or mobile users and the processors to wireless base stations. In the future, it is expected that multicast will become a significant (if not dominant) form of information delivery for communication networks, and that this delivery will extend to wireless users. It should be noted that the generality of our solution permits traditionally fixed-location base stations to be mobile. In the third application, the entities correspond to mobile IP users and the processors to potentially mobile IP routers. In each instance the application must specify a mechanism1for ensuring that a processor is always aware of its associated entities.

Common to these applications is the problem of constructing and maintaining adaptive multicast routing and bandwidth allocation tables for the transmission of hierarchically-encoded, (potentially real-time) signals in a mobile network, where the resulting solution must reflect the receivers' prioritized quality-of-service requirements, possible real-time delivery thresholds, and prevailing network bandwidth constraints. The protocol solution should be fully distributed, scalable and functional in the presence of topological changes caused either by mobility or arbitrary processor and link failures.

The proposed protocol, termed Reservation-Based Multicast (RBM), has these characteristics. However, its operation is complex and its ability to adapt to arbitrary topological changes requires tight coupling to an underlying unicast protocol. To fully understand the adaptive "mobile" version of RBM, one must understand the underlying protocol as well. A forthcoming paper will briefly describe the underlying protocol, its complete description can be found in [4], and detail its

1 For example, in the current Internet architecture, a group membership protocol [3] serves a similar function of keeping routers informed of the membership their directly attached subnetworks.

interrelationship with RBM that provides RBM its robustness and adaptivity to arbitrary topological changes during both initial route construction and subsequent route maintenance and rediscovery.

Here, we present a detailed description of the protocol's initial route construction phase, where its operation is assumed to occur over a static "snapshot" of a dynamic network topology. This presentation facilitates the introduction of RBM and also provides insight into its operation in a dynamic topology. Since the operation described here occurs over a static topology, the "approach" to combined multicast routing and bandwidth reservation proposed here is applicable to fixed, point-to-point networks as well, e.g. the Internet. As you consider the protocol and its operation in a static network, bear in mind that its design is driven by the need to function in a mobile environment.

1.1 Related Work

Most existing work on multicast routing considers fixed networks with static topologies. One line of research focuses on centralized implementations and formulates the problem as a Steiner tree computation [5]. However, since the Steiner problem is NP-complete [6], most of this work makes use of heuristic solutions [7, 8, 9]. Other work considers approximations of the Steiner tree problem itself such as the Minimal Spanning Tree (MST) [10, 11, 12] techniques and weighted, greedy versions thereof [13]. The difficulty with such approaches is that they are inherently non-scalable as the number of receivers becomes large. An optimal approach combining routing and resource allocation has recently been developed [14], but its computational complexity limits its scalability as well. At the other end of the complexity scale, researchers have examined just how poorly "naive" multicast routing behaves in random graphs where no attempt is made to construct an efficient multicast distribution tree [15].

Several years ago, two protocols were proposed in [16, 17] and implemented in DVMRP [18] and MOSPF [19] to accomplish multicast routing in "locally dense" portions of the Internet. Unfortunately, both protocols are "source-based" and suffer from scalability problems; DVMRP, because it is a data-driven protocol, requires periodic, truncated data packet broadcasts to all network routers that might serve group members and MOSPF, because it is a "link-state" protocol, requires the entire network topology to be known at all routers.

To overcome these problems, an algorithm termed "Protocol Independent Multicast" (PIM) [20] was introduced. PIM is distributed and may operate in either "dense" or "sparse" mode. Dense mode operation is similar to the data-driven functioning of DVMRP and is restricted to intra-

domain multicast for locally dense groups. While users may opt for this dense mode behavior, sparse mode operation is the default.

In sparse mode PIM, users comprised of sources and destinations are collected into multicast groups and each group is assigned a multicast address. A user may be both a source and a destination for the same group. Each group is assigned one or more Rendezvous Points (RP), the locations2 of which are known to all group members. Sources initially send their packets to the group address, i.e. to all RPs, while receivers subscribe to one of the RPs and individually select which subset of the sources they wish to receive. The resulting routing pattern is a "shared tree." After the initial connection, receivers may remain on the shared tree or switch to a source-specific distribution trees by directly contacting a source if desired. The sparse mode protocol is scalable in that it avoids explicit enumeration of receivers and utilizes shared trees containing a small number of non-member routers.

Another recent proposal that similarly addresses the aforementioned protocols' scaling problems is termed "Core Based Trees" (CBT) [21]. The CBT protocol is distributed, receiver-based and utilizes a shared multicast tree. Each group has designated "core" routers whose locations are known to all potential members. Receivers inform a core, or the first on-tree router their message finds on its way towards a core, that they wish to be added to the tree and a new branch is built to each receiver. Sources send their information to a core router which then distributes the information over the tree to all receivers. The protocol requires less state overhead than PIM since only a single tree per group is built, as opposed to the potential for numerous source-specific trees in PIM. However, it is noted in [20] that CBT may suffer from a traffic concentration problem, particularly if there is a large number of sources, as all the source traffic must travel on the shared tree which might congest the links and reduce performance. Source-specific trees are advantageous in that (i) the traffic is distributed over a larger number of routes lessening the load on any individual route and (ii) the expected source-to-receiver delay is less than for optimal core based trees. However, they are disadvantageous in that they consume a larger amount of network resources than center (or core) based trees [22].

Both PIM and CBT are purely routing protocols; they do not integrate resource allocation with the routing process (the assumption being that bandwidth is universally plentiful) and consequently use shortest-path routing when forming multicast distribution trees. Recently, a resource ReSerVation Protocol (RSVP) was proposed [23]; in part, to address the lack of resource

2 The member is said to know the "location" of another member or a RP if it knows a route to its location. PIM employs a link-state routing similar MOSPF to maintain shortest-path (i.e. minimal hop) routes to the sources and RPs.

reservation in the preceding routing protocols. RSVP is a modular protocol that separates the process of resource reservation from routing; "the only assumptions RSVP makes regarding an underlying protocol are that (i) it provide both unicast and multicast routing and (ii) a sender to a multicast group can reach all group members under normal operating conditions [23]." Through separation, the complexity of the overall task is easier to manage. However, a problem it presents is that since routing precedes resource reservation, the former cannot take into account any constraints present on the latter. Thus, routes may be chosen which have insufficient resources to carry the desired information flow in a bandwidth constrained or congested network.

A protocol that avoids the preceding difficulty by combining routing and resource reservation is ST-II [24]. ST-II is a connection-oriented protocol which also employs soft-state mechanisms for network control and guarantees end-to-end bandwidth and delay. ST-II is also a "sender-oriented" protocol meaning that the sender is aware of who is receiving its data. This can be advantageous when dealing with issues such as security, privacy and billing, although even this view is disputed [25]. Unfortunately, it renders the protocol non-scalable as the number of receivers becomes large since the source must be informed any time a receiver is added or removed from the multicast group. While ST-II was recently extended to permit receiver-initiated addition of receivers [26], it retains its fundamental bottleneck to scalability, viz. sender-oriented operation. ST-II is also limited in that it only permits one source per multicast group, as opposed to the multiple source, multiple receiver design of RSVP. The interested reader is referred to two recent papers [27, 28] for a more detailed comparison between RSVP and ST-II. Also, very recently in [25], it has been suggested that a "lightweight" version of RSVP might be incorporated into CBT without violating many of RSVP's design principles. While this is still the subject of future research, it may indicate a trend towards the integration of routing and resource reservation as proposed here.

1.2 Protocol Overview

RBM is designed to support the applications that motivated its development. However, the communication model we consider has been abstracted away from these applications slightly and embodies the core problem faced in each application. The model places no restrictions whatsoever on the mobile processor network's topology, it may vary arbitrarily. In this sense, it is the most general and difficult problem to consider. In many applications, something may be known regarding the locations or future movements of some or all of the processors. This knowledge may simplify the routing problem and be used to advantage by a routing protocol to increase performance.

The protocol's architecture incorporates the following properties:

? P ractical, i.e. one with a distributed operation based on partial knowledge that is scalable in the number of entities and processors.

? E fficient, i.e. in terms of its resultant routing and resource reservations and its computational and communication complexity.

? A daptive, i.e. the protocol must react quickly and reestablish multicast routing in response to movement or failures in the network.

?R eceiver-Driven, i.e. routing and resource allocation should reflect receiver-initiated requests. The same holds for multicast group membership; the sources need not know the receivers (a concept to be described shortly, originally introduced in [17]).

? Quality o f S ervice-Based, i.e. fidelity of information delivered to each user may vary, receivers individually prioritize service levels which directly affects the routing, resource allocation and selection of services delivered to the receivers.

? R eal-time S ervice (optional), i.e. receivers individually set real-time service thresholds which directly affect the routing, resource allocation and selection of services delivered to the receivers.

RBM is, in part, a combination of techniques selectively chosen from the existing body of work on fixed, point-to-point multicast to form an integrated routing and resource reservation protocol for mobile networks. In RBM, the concept of receiver-initiated operation borrows from existing and proposed internet protocols and the use of RPs to link sources with destinations in a mobile network borrows from PIM3. The use of a distributed approach to resource allocation involving multiple phases of packet propagation is motivated chiefly by [29]. These together with new techniques are then integrated and coupled to an underlying unicast routing protocol for mobile networks [4]. The resulting hybrid forms a novel approach to combined multicast routing and resource reservation for both fixed and mobile networks; one which is fully distributed and builds shared multicast distribution trees. The architecture is flexible and balances performance and complexity to maintain scalability.

Of course, the approach described here for initial route construction in mobile networks, after some obvious simplifications, also serves as a complete protocol for fixed networks. Additionally, if the "mobile" version of the protocol (without simplification) is run on a fixed network, its added

3 Comparisons between RBM and PIM will be made in portions of the paper. However, one should not strictly relate RBM to PIM. PIM, which utilizes multiple RPs, may simply be viewed as a generalization of CBT involving multiple, single-core based trees. Thus, the notions of "source-to-RP" and "RP-to-destination" routing, to be introduced shortly, can also be viewed as "source-to-core" and "core-to-destination" if comparison with CBT is desired.

complexity ensures fault tolerance since the protocol can react to any topological changes due to link or processor failures. However, this approach is excessive; the scope of changes which must be handled in a mobile situation is greater than that required to simply provide fault tolerance in a fixed network. Thus, a fault-tolerant version of RBM for fixed networks would include the initial route construction procedure described here and a subset of the logic required for mobile operation.

It should be emphasized that this is a "conceptual" work which outlines a practical approach to reservation-based multicast. No implementation or simulation of RBM has yet been made. The rest of the paper is organized as follows. Section 2 describes the network and communication model. Section 3 gives a detailed description of RBM and an example of its operation. Section 4 discusses RBM's scaling properties and other significant characteristics. Section 5 concludes with a summary and discussion of future work.

2. THE MODEL

We consider a network consisting of a set of mobile processors V and a set of mobile entities N. Each processor is associated with zero or more entities, while an entity is always associated with a single processor. Entities may move between processors. The processors serve as routers, whereas the entities are considered end-users incapable of performing routing functions. The routing problem considered here is an interprocessor or interdomain routing problem. It is assumed that once information is delivered to a processor, it is capable of delivering it to its associated entities.

The physical network topology is modeled by a graph G V E

=(,), where E is the set of bi-directional links which operate independently in each direction. Unless otherwise specified, the notation (,)

i j refers to the link directed from processor i to processor j. Each link (,)

i j E

∈ has a

finite bandwidth or capacity c

i j

(,)

.

Entities transmit and receive information. Entity communication occurs via multicast groups. Let MC be the set of all multicast groups. Associated with each multicast group m MC

∈ is a set of

sources S

m , a set of destinations D

m

, and a set of RP processors P

m

. Let a "source" or

"destination" be defined as a pairing of an entity i with a processor j, denoted s

i j, or d

i j,

,

respectively. Sources deliver information to RPs and destinations receive information from RPs.

A processor l serving as a RP is denoted p

l

.

Each source s S i j m ,∈ is assumed to transmit a signal 4 αi . This signal is hierarchically encoded into K layers, indexed 1 to K , where layer 1 is the fundamental or basic signal providing the most primitive information as in [1] (see Fig. 1a). Reception of layer j implies reception of layers 1 to j ?1 as well; this is termed receiving QoS or fidelity at bandwidth "level" j . The amount of bandwidth allocated to each layer j of signal αi is denoted b i j , , is positive, and may vary with each signal. The total bandwidth delivered at QoS level j for signal αi is W b i j i k k j

,,==∑1. We

define q i l as the QoS level for signal αi present at a processor l and Q W i

l i q i l =, as the bandwidth

required to carry QoS level q i l at processor l . The maximum deliverable QoS level for a signal αi

under a bandwidth constraint b is denoted ?()q b i and is computed as ?()max{|},q b j W b i j i j =≤,which corresponds to a deliverable capacity or bandwidth of ?(),?()Q b W i i q

b i =.Each destination receives its desired signals from the RPs. While the RPs receive all signals, a destination may elect to receive only a subset of these signals. Each destination d k l , independently assigns its own quality measure f i j k l ,, to receiving signal αi up to and including QoS level j ,

where f f j K i j k l i j k l ,,,,, ><≤?11. Similarly, each destination d k l , may optionally specify a real-time

delivery threshold t i k l , for signal αi dictating the maximum permissible delay from source s i j , to destination d k l ,. Initially, t i k l ,=∞ and if a different value is not specified by the destination, then the threshold does not affect the algorithm's computation. Additional QoS parameters such as jitter bounds [30] may be incorporated in the future if necessary.

RBM is overlaid on top of multiple, independently executing versions of an underlying,distributed, UNIcast Routing Protocol (UNIRP) for mobile networks [4]. For each processor l , a version of the underlying protocol, denoted UNIRP(l ), maintains a directed acyclic graph (DAG)rooted at the processor l, denoted DAG(l )5. The DAG(l ) provides one or more loop-free routes from any processor to the processor l . UNIRP weights these routes with a distance metric 6making the DAG a "Weighted" DAG (WDAG), denoted WDAG(l ). Each UNIRP version adapts asynchronously in a distributed fashion to arbitrary changes in topology in the absence of global 4 Without loss of generality, we assume each source entity only generates a single signal. In a real system, a source could generate multiple signals so making the signal ID the same as the source entity ID would not be possible.Also, to reduce notational complexity, the notation αi is actually shorthand for the full signal ID pair αi n i n ,(,)=which means a signal i is obtained from a RP n . Later in the paper, this association will become important and the full ID will be used. Until then, let ααi i =?, meaning the signal is coming directly from its source without passing through a RP.5 This differs from the description of RBM found in [31] (more on this in section 3.2.2).6 This metric typically reflects the number of hops along the route, but for real-time applications could reflect the estimated real-time delay along the route

topological knowledge. Because RBM is coupled to these underlying versions, these changes are made known to RBM which adapts accordingly.

3. THE PROTOCOL

The protocol description focuses on a single multicast group and the algorithm's operation proceeds independently for each group. However, it will be seen that sharing and state aggregation of the underlying unicast routing information exists between groups.

In RBM, the overall information flow is nearly the same as in PIM. Each multicast group is assigned a set of possibly mobile RPs. Each source attempts to send its information to all RPs. Destinations join the group by subscribing to one or more RPs.

Realizing that bandwidth can still be a scarce commodity, particularly for mobile networks, RBM requires that routing be based on bandwidth availability and a distance metric rather than simply using shortest-path routing. This implies that multiple routes be considered by the algorithm before a final route is selected. For users requiring real-time service, RBM provides an option of specifying a real-time service delay threshold which is incorporated into the routing decision. The routing process can be broken into two parts: source-to-RP and RP-to-destination.

3.1 Source-to-RP Routing

Since signals cannot be combined or mixed, the source-to-RP routing process proceeds independently for each signal. Source-to-RP routing consists of three message phases7: allocation, reallocation and selection.

Allocation Phase

In source-to-RP routing, each source attempts to send its information to all RPs and attempts to deliver the highest QoS level. To illustrate this procedure, let us consider one source s

i j,

, shown

in Fig. 2a, as it attempts to reach two RPs, p

m and p

n

. The entire network topology is shown in

Fig. 2a. Parts (b) and (c) of the figure show the

DAGs are maintained for each RP by the underlying protocol. The objective of the allocation phase is to explore all downstream routes from the source to each RP. Each source-RP combination presents a different set of downstream routes, referred to as a "localized DAG"

7 Each phase corresponds to a wave of packet propagation. The notion of using a multi-wave or multi-pass process borrows from [29].

(shown in parts (d) and (e)) and the allocation packets explore the links in the "union" of these sets shown in part (f).To initiate the phase, the source generates an "allocation" packet containing the following information fields (,,,,,,,,),g s G RL b M R u m i j i i i i i i RL i α where

? g m identifies the multicast group m ,

? s i j , identifies the source's [entity,processor] pair [i,j ],

? αi identifies the source's signal i ,

? G P i m ? identifies the set of RPs which the packet, representing signal αi , is currently seeking.

The set is stored as a list

{,,}p p i i n 1K and updated as the packet travels along route; initially G P i m =, all the RPs for multicast group g m ,

? RL i is the routing label, stored as a list of links {(,),(,),,(,)}i j j k l m K traversed by the packet representing signal αi along its route; updated as the packet travels along the route, initially empty,? b b j K i i j =≤≤{, },1is the bandwidth layer vector containing the bandwidth-to-layer assignments for signal αi , necessary to construct a signal profile (more on this later),

? M i gives the minimal required bandwidth for signal αi , initially set to W i ,1, the amount required to carry the signal αi at its minimal QoS level 1,

? R i gives the requested bandwidth for signal αi , initially set to W i K ,, the amount required to carry the signal αi at its full QoS level K ; updated as packet travels along route,

? u RL i holds the cumulative real-time delivery delay along route RL i , necessary to construct signal profile; updated as packet travels along route, initially set to zero (Note: This is not the allocation packet's actual travel time, but is the cumulative real-time service delay along the route which the processors guarantee will not be exceeded when serving the stream at a rate ≤R i ).

An allocation packet will have following default composition when generated (,[,],,,{},,,,),,m i j i P b W W m i i i K 10. Once generated, the source operates on the packet as if it just received the packet from a neighboring processor. This can be viewed as if the source "entity"generates the packet and then sends it to the source "processor" for routing. The only difference is that on receiving a signal from one of its own source entities, the source processor adds the signal to its own source profile instead of adding it to an incoming link profile (profiles will be described shortly).

During allocation phase route exploration, a signal may split into multiple "streams" and these streams may cross a given link numerous times. Simply identifying a stream by its signal number αi is not sufficient to uniquely identify the stream. Thus, an individual stream is identified by a triple (,,)αi i i G RL indicating its signal, the set of RPs to which it is heading and the route the stream has taken. Each allocation packet represents an individual stream.

A stream "profile" is a set (or list) of streams and their associated information. Each processor l maintains a "source profile" SP l containing streams originated by entities associated with that processor. An entry s l G RL i i i (,,)α into SP l for stream (,,)αi i i G RL is of the form (,,)q b u i l i i l where q i l is the QoS level delivered to processor l , b i is the bandwidth layer vector and u i l is the real-time delivery delay to the processor (see Fig. 1b). A processor l associates with each link (l,m ) an "outgoing link profile" LP l m (,) and an "incoming link profile" LP m l (,) containing streams traveling

to or from processor m , respectively. An entry s l m G RL i i i (,)

(,,)α into LP l m (,) is of the form (,,),(,)q b u i l m i i l m () where q i l m (,) is the QoS level delivered over link (l,m ), b i is the bandwidth layer vector and u i l m (,) is the real-time delivery delay over the link at processor m . Each processor l has an "incoming profile" IP l , formed from the union of its source profile and all its incoming link profiles which is computed as

IP SP P l l j l j V l =∈()(,)U U , and an "outgoing profile" OP l , formed from

the union of all its outgoing link profiles which is computed as

OP P l l j j V l =∈(,)U . When referring to

the streams "available" or "present" at a processor, we mean those in its incoming profile. Profiles contain "temporary" and "permanent" subsets. Streams are classified as "temporary" or "permanent 8" and reside in the corresponding subset.

Each processor l maintains a routing table RT l containing an entry r l G RL i i i (,,)α for each incoming

stream (,,)αi i i G RL , each entry being a set of pairs with each pair

((,),{(,),,(,)})l m p b p b j j j j n n 11K specifying an outgoing link (l ,m ) and an associated set of RP-flag pairs {(,),,(,),}p b p b p G j j j j j i n n 11K ∈. Each pair associates a RP p j with a Boolean reallocation flag bit b j (initially set to zero indicating "false") which indicates whether a "reallocation" packet (to be introduced shortly) has been received over this link for this stream for this RP. An empty routing label RL l ={} in a table entry r l G RL i i i (,,)α indicates that the stream originates at an entity associated with processor l .

On reception of an allocation packet, a processor places an entry for the incoming signal stream it represents in either its source profile or an link profile as appropriate. It also creates a routing table entry, but cannot yet specify any outgoing links until the following allocation procedure is run to determine if sufficient capacity exists.

Allocation procedure: On reception, an allocation packet requests from a processor j an amount of bandwidth equal to R i on each of its outgoing downstream links contained in the union of the DAGs corresponding to RPs the packet is currently seeking. To define this precisely, let V j be the 8 A stream or reservation becomes "permanent" if it corresponds to a route that is "selected" to deliver information to an RP or a destination; otherwise, it is considered "temporary." The reservation exists for the duration of the

multicast session, or until it is specifically deallocated by the protocol in response to node movement or some other event.

set of processors neighboring a processor j and let DN p V j k j ()? and UP p V j k j ()? be the sets of processors neighboring processor j connected via links marked "downstream" and "upstream" with respect to (w.r.t.) DAG(p k ), respectively. Thus, a packet at processor j requests bandwidth R i on a link (j,l ) if ?∈∈p G l DN p k i j k : (). In the example in Fig. 2, links (j,a ) and (j,b ) are downstream for the source in both DAG(p n ) and DAG(p m ). Thus it is possible for the source to place a single reservation on each link specifying a stream traveling to both RPs.

Let β(,)i j denote the bandwidth not permanently allocated on link (i,j ) where β(,)(,)i j i j c ≤ (see Fig.3). Let ρ(,)i j be the available bandwidth, i.e. that not permanently or temporarily allocated on

link (i,j ) where ρβ(,)(,)i j i j ≤. Let φα(,)

(,,)l m G RL i i i be a bandwidth reservation placeholder on link (l,m )for stream (,,)αi i i G RL .

Placeholders are used for temporary reservations. Because of the localized route exploration,multiple packets representing the same signal may take different routes and be destined for different subsets of RPs, yet cross the same link enroute to these RPs 9. Each packet makes a temporary reservation on a link, leaving a placeholder to mark its passing in the link's allocation table AT l m (,)(see Fig. 3). Let Φ(,)l m be the set of placeholders on link (l,m ), which is a temporary subset of the reservations in the link's allocation table. In general, each placeholder must have a separate,temporary bandwidth allocation. However, placeholder allocation aggregation is possible when two or more streams are present carrying the same signal over different routes to a single RP. In this situation, only one of the placeholders can ever become a permanent reservation, the rest will be deallocated. Hence, the amount of bandwidth temporarily reserved need only be the maximum

of these temporary reservations. Thus, let ?φαα(,),{}(,)(,{},)max l m p RL l m p RL i

j i

i j i = be the bandwidth reserved for the allocated placeholders for signal αi on link (l,m ) heading for the single RP p j ; ?α(,),{}

l m p i

j =0 if no

such reservation has yet been made.

Returning to the procedural description, each downstream link is checked to see if bandwidth for the requested, or at least minimal, QoS level is available. The full requested amount is reserved if available; otherwise, sufficient bandwidth is allocated to serve the highest possible QoS level,provided it is at least equal to the minimal level. For a link (l,m ), the decision proceeds as follows 10:9 Thus the need for individually identifiable streams as noted previously.10 The code segments presented use a syntax similar to the "C" Programming Language. Also, if a is a item and b is a set or list, the notation a b → or b a → means that the item is either placed in or removed from the set

or list, respectively.

if (G p i j l m p i

j =≠{} and (,),{}?α0) {

// if true, a single RP placeholder for p j already exists if (R i l m p i

j ≤?α(,),{}) {

// check if it fits within existing placeholders ()(,)(,{},)(,)φαl m p RL i l m i j i R =→Φ ;// if so, simply add new placeholder

}else if (M i l m p l m i j ≤+?ρα(,),{}(,)) {// check if minimal service is possible

??(min(,))(,),{}(,)φ?ρα=+Q R i i l m p l m i j ; // allocate as much as necessary or possible

ρρφ?α(,)(,)(,),{}(?)l m l m l m p i j =?? ;// reduce available link bandwidth

(?)(,)(,{},)(,)φφαl m p RL l m i j i =→Φ ;// add new placeholder

}else {// reject allocation request

}}// multi-RP or new single RP request

else if (M i l m ≤ρ(,)) {

// check if minimal service is possible ??(min(,))(,)φρ=Q R i i l m ;

// allocate as much as necessary or possible ρρφ(,)(,)?l m l m =? ;// reduce available link bandwidth (?)(,)(,,)(,)φφαl m G RL l m i i i =→Φ ;// add new placeholder

}else {

// reject allocation request }An allocation packet is replicated, modified and sent down each link on which an allocation is made. For a link (l,m ), the packet is modified as follows. The fields g m , s i j ,, αi , b i and M i

remain unaltered. The requested bandwidth field R i is set to φα(,)

(,,)l m G RL i i i , the value of the placeholder reservation, which is less than or equal to the field's original value. If X is a set of RPs, let G X l m (,)() be the subset of X for which link (l,m ) is marked downstream in some DAG(p j ), p X j ∈. More precisely, ?∈∈∈p X p G X m DN p j j l m l j , () if ()(,). Thus, the field G i is set to G G l m i (,)(). The field RL i is set to RL l m i ⊕(,) where the operator "⊕" denotes the

"append" operation for a list. Let v l m i R i (,), be the real-time service delay over link (l,m ) for signal αi

being delivered at bandwidth R i which processor l guarantees will not be exceeded. This accounts for all delays starting from the reception of a bit at processor l to the delivery of that bit to processor m , including processing, queueing (if any), transmission and propagation. The field

u RL i is set to u v RL l m i R i i +(,),. Also, an entry

((,),{(,),,(),()})(,)l m p p p G G j j j l m i n 100K ∈ is placed in the stream's routing table entry r l G RL i i i (,,)α.

If the bandwidth M i is not available on a link, then a downstream allocation cannot be placed on the link. Let U G i i ? be the set of RPs for which no downstream allocation may be made. More

precisely, p U p G m DN p M M j i j i l j i l m i l m p l m i

j ∈∈?∈>>+ if and (), or (,)(,),{}

(,)ρ?ρα. If the set

U i is non-empty, then an "unassign" packet is generated. The purpose of an unassign packet is to retrace the allocation packet's route and remove the members of U i from the RP sets G i stored in the upstream processors' profiles and routing tables for the stream. The intent is that since these RPs cannot be reached from this processor, the upstream stream identifiers (,,)αi i i G RL should be modified to accurately reflect the set of RPs serviced by the stream. An unassign packet contains the following fields (,,,,,),g s G RL U m i j i i i i α. An upstream processor l , upon receiving an unassign

packet over link (l,m ), modifies its LP i entry's stream identifier from s l m G RL i i i (,)(,,)α to s l m G U RL i i i i (,)(,,)α?,where the operator "-" denotes the "set difference" operation, and modifies link (l,m )'s portion of i t s RT l e n t r y f r o m ((,),{(,),,(,),})l m p b p b p X j j j j j n n 11K ∈ t o

((,),{(,),,(,),()})l m p b p b p X U j j j j j i n n 11K ∈?. Also, the processor checks the stream's RT l entry r l G RL i i i (,,)α to see if the stream splits (is replicated) at the processor. If so and if a RP p U j i ∈ is still present on any of those links, then that RP is removed from the set U i contained in the packet. If all RPs are removed in this fashion and the set becomes empty, the packet's upstream propagation is terminated; otherwise the propagation continues until either the set is empty or the source processor is reached. Note that no bandwidth is actually deallocated, this is simply an accounting procedure to ensure that the profiles and routing tables accurately reflect the RPs being serviced.An allocation packet's downstream propagation is terminated if, upon arrival at a processor, no allocation can be made for its stream on any downstream link. In this case, the allocation packet is "reflected" by the processor back along its route and any bandwidth previously reserved is freed for use by other streams. An upstream processor l , upon receiving a reflected allocation packet

over a link (l,m ), remove its stream's LP i entry s l m G RL i i i (,)

(,,)α, removes its allocation placeholder φα(,)

(,,)l m G RL i i i , restores 11 the appropriate amount to link's available bandwidth ρ(,)l m , and removes link (l,m )'s portion ((,),{(,),,(,),})l m p b p b p X j j j j j n n 11K ∈ from the stream's RT l entry r l G RL i i i (,,)α. The reflected packet's propagation terminates here, unless the routing table modification leaves entry r l G RL i i i (,,)α empty, thus indicating that the stream is not replicated at this processor, in which case the propagation continues upstream. This bandwidth-based propagation termination reduces overhead by pruning routes which cannot carry the minimally necessary signal information. The pruning rule cannot incorporate real-time constraints, such as comparing the u RL i field to a threshold, because different destinations may have different thresholds which are not known here.

11 The amount restored, if any, depends upon whether or not placeholder allocation aggregation is being used and is computed in the same fashion as in the allocation procedure.

Repeating the preceding procedure, the surviving allocation packets fan out in a pruned, localized search over all downstream routes to the RPs temporarily reserving bandwidth along those routes (see Figs. 4b-4g which continue the example of Fig. 2). Part (b) shows a separate packet being sent down each downstream link. Each packet is searching for both RPs p n and p m as indicated by (m,n ) in the figure. At subsequent processors (e.g. see part (c)), some packets are generated that seek only a single RP because the link directions differ in the underlying localized DAGs for the two RPs. In part (d), the packet arriving at processor d does not find sufficient bandwidth on link (d,e ) to make an allocation and so is reflected back upstream undoing the reservations made on link (c,d ). The upstream propagation stops at processor c because the stream is replicated there and the bandwidth allocated on link (b,c ) is needed to support the allocation on link (c,h ) and beyond. Also, in part (d), the attempt to send a packet seeking RP p m down link (f,g ) fails due to lack of bandwidth causing an unassign packet to be generated and sent upstream over links (f,a )and (a,j ) to remove the RP ID p m from reservations made on those links and at processors a and j .Reallocation Phase

If routes exist with sufficient bandwidth, one or more allocation packets will eventually arrive at each RP. Having been modified in route, each packet's R i and u RL i fields indicate its stream's reserved capacity and maximum real-time delivery delay, respectively. Each allocation packet reception generates a "reallocation" packet which is sent by the RP back along the incoming route.The reallocation packet's purposes are (i) to inform the source of the stream's capacity, real-time delay and reachable RP set and (ii) to backtrack along the route and, as necessary, deallocate any bandwidth previously allocated in excess of the delivered capacity, provided this does not reduce the delivered capacity of another stream. The "delivered" capacity of a stream is the minimum bandwidth allocated along its route, which is always equal to the value stored in the allocation packet's R i field on arrival at a RP.A reallocation packet contains the following fields (,,,,,),g s G b L m i j i i i i α where L i is a set of triples (,,)RL R u i p i p i p

j j j , one triple for each stream 12 terminating at a RP, each triple consisting of the capacity R i p j and real-time delay u i p j of signal αi delivered to RP p j , respectively, over route RL i p j . When initially generated at RP p j , the fields G p i j = and L RL RL R R u u i i p i i p i i p RL j j j i ===={(,,)} and the remaining fields are copied directly from the allocation packet. Note that while an allocation packet's routing label is of the form RL i j j k l m i p j ={(,),(,),,(,)}K , a reallocation packet's label takes the form

RL i j j k l m i p i j j k l m j ={((,),),((,),),,((,),)}(,)(,)(,)φφφK where φ(,)l m stores the "link bandwidth"12 Recall that multiple streams may terminate at the same RP.

allocated for the stream on link (l,m ), which is initially set to zero. An upstream processor l , upon

receiving a reallocation packet over a link (l,m ), sets its allocation placeholder φα(,)

(,,)max l m G RL p G i p i i i j i j R =∈returning the freed 9 bandwidth, if any, back to the free bandwidth pool ρ(,)l m and, for each

p G j i ∈, sets the link bandwidth field ((,),)(,)(,)

(,,)l m l m l m G RL i i i φφα= in the routing label to that value as well and sets its reallocation flag bit b j =1 in the corresponding pair (,)p b j j in the routing table entry r l G RL i i i (,,)α. The processor then checks this entry to determine whether the stream is replicated at the processor and, if so, whether all other reallocation packets have been received 13.If not, the processor queues the packet, and all subsequent packets, waiting until the final reallocation packet arrives. The processor then generates a "merged" reallocation packet where the new sets G i and L i are the unions of the respective sets in the queued packets and the remaining fields are copied from any queued packet, being the same in all 14. This procedure is repeated until all incoming reallocation packets are received at the source, which are finally merged into a single reallocation packet. The source uses the data present in this packet to make its routing decision.Figure 5 continues the example of Figure 4 and highlights reallocation phase operation. Since the reallocation phase typically begins before the allocation phase is completed, the illustration overlays reallocation packet propagation (shown in black) on top of the ongoing allocation phase operation (shown in gray). The initial reallocation packets are generated at RP p n in part (e). These two packets propagate upstream, subsequently merging at processor a and continuing upstream without being queued at the processor since they represent the only two remaining streams from the original stream which was replicated in Fig. 4c. Recall that the original stream arriving at processor a searched for both RPs; however, the unassign packet removed RP p m from the temporary reservations. Had this not been done, the two packets would merge and be "queued" at processor a (queuing is indicated by boxes in the figure) awaiting arrival of a reallocation packet from RP p m before continuing upstream. An example of this is seen at processor g where two packets merge in part (g), remained queued in part (h) awaiting the packet from RP p n which arrives in part (i), and then continue upstream towards the source.

Note that during this process, each RP has multiple incoming stream reservations for signal αi ,each with a QoS level and real-time delivery delay. While awaiting permanent "selection" by the 13 All reallocation packets have been received when all reallocation flag bits equal one in the stream's routing table entry.14 To avoid protocol deadlock, we require here that all reallocation packets arrive before generation and upstream propagation of a "merged" packet may proceed. This may not always occur, possibly due to link failures or node movement. Soft-state mechanisms involving timers could be employed to handle these situations. However, tight coupling to the underlying unicast protocol permits a more efficient and elegant solution to the problem of adapting to arbitrary topological changes in a mobile network. We will address this issue in a forthcoming paper.

source, the RP maintains a list of these reservations along with their associated information in the temporary portion of its incoming profile. No route can be used until selected.

Eventually, the source will receive one or more reallocation packets, depending on the network topology. The source processor knows it has received all incoming packets when all the reallocation flags bits for all its outgoing streams equal one. Each packet presents a source processor with an outgoing stream for its signal over an adjacent link serving a set of RPs . For each RP, the source may, in general, choose from multiple routes, each with its own capacity and real-time delay.

Selection Phase

Different decisions combining routing and resource allocation are now possible. A good policy seeks to (i) maximize the signal quality to each RP, (ii) minimize the signal delay to each RP and (iii) minimize the total bandwidth allocated throughout network. Different priorities necessitate different policies. One simple policy is to first maximize the signal quality to each RP and, if multiple routes exist with maximal quality, then take the minimal delay alternative. If multiple maximal-quality, minimal-delay routes exist, then select a routing which is as bandwidth efficient as possible. Another policy would switch the first two priorities, first giving preference to the delay measure taking the fastest route whenever possible or, if multiple routes are delay equivalent, then maximizing the signal quality, again giving third priority to minimizing the total allocated bandwidth. Other simple priority-based schemes, perhaps emphasizing bandwidth efficiency to be used during periods of network congestion, are easy to envision and implement. More complicated, implementation dependent schemes involving weighted combinations and trade-off between quality, delay and bandwidth are possible. However, detailed selection policies involving delay thresholds are difficult to implement here (during source-to-RP routing) because different destinations may have different real-time thresholds and because the remaining real-time delay from RP-to-destination is unknown. For the rest of this paper, it is assumed that the first policy described is operating, which emphasizes delivery of the maximum signal quality to the RPs. This policy can be implemented as follows.

Route selection procedure: To understand route selection, we must first identify the relationship between routes and streams. A route is associated with any signal stream which terminates at a RP and identifies the path (sequence of links) the stream follows from source to RP. A signal stream physically enters a processor either from a source entity or from an upstream link. If, according to the allocation procedure, the stream must split and depart the processor over multiple links, the stream is physically replicated and sent out over those links. While the routes streams follow may

logically diverge at a processor and then later converge sharing subsequent downstream links, the associated streams may never physically merge and must each retain a separate bandwidth allocation. Before such a divergence, however, a stream's associated routes common to a link share the stream's bandwidth allocation.

The set of routes "present" at a processor is divided into subsets according to the link over which they depart the processor. The associated routes that enter a processor with a stream and leave with that stream remain "associated" with the stream. On a given link, the stream's bandwidth allocation equals the maximum required by any of the associated routes. To compute its total bandwidth allocation, a set of routes is traced accounting for the shared bandwidth allocation until they diverge. After divergence, the routes are logically separated into subsets and may never again be recombined so as to properly track the separate bandwidth allocations of the associated streams,regardless of whether the routes once again share common links. Thus, while different streams of the same signal may diverge and later converge, clearly not forming a "tree" in a topological sense,the streams do form a "bandwidth allocation tree" since a signal can never recombine with itself when its paths' overlap. Eventually, the routes and associated streams must all diverge and be separated into G i sets, one route per set per RP.

In the procedure, let A r r m m n ={,,}1K be the set of routes contained in the final merged reallocation

packet, each route corresponding to some routing label in the packet. For each RP p G j i ∈, let A A j ? be the non-empty set of routes terminating at the RP. Let B A j j ? be the set of routes delivering maximal quality to RP p j ; this set is easily determined by comparing the capacity R i p j of each route. Let C B j j ? be the set of maximal quality routes with the minimal real-time delay;this set is similarly determined by also comparing each route's delay field u i p j . The algorithm proceeds by first considering each RP independently. If A j =1, then "select" r A m j ∈ to route to p j , otherwise consider set B j . If B j =1, then select r B m j ∈ to route to p j , otherwise consider set C j . If C j =1, then select r C m j ∈ to route to p j , otherwise execute the following procedure to attempt to minimize the overall bandwidth allocation.

The procedure computes a joint routing solution to all RPs. Let D be the set of all previously "selected" routes from sets A B C j j j ,or for any RP p j . Each of these routes must be present in the final routing solution. For each RP p j which does not have a selected route, some route r C m j ∈ must be in the solution. Thus the problem 15 reduces to picking one route for each RP which does not have a selected route such that the overall bandwidth, including that for the already 15 It should be noted that if bandwidth minimization is not a concern, then any maximal-quality, minimal-bandwidth route may be selected for each RP. In this case, the link bandwidth fields are not required in the routing labels.

selected routes, is minimized. If it is assumed that there are K G i ≤ such RPs with sets C j satisfying C j >1, then there are

C C C j j K * =××1K possible route set permutations. Since the number of RPs per group is expected to be small, and since the number of maximal-quality,minimal-delay routes per RP is likely to be very small, the number of permutations should be small enough to permit an exhaustive search to be performed quickly over all possible route set permutations.

Let E k C k , *1≤≤ be the k th route set permutation under consideration. The procedure examines all route set permutations searching for a set with the minimal bandwidth allocation ?min(())B B E E k k

=, where B E k () is the total bandwidth allocated using the permutation E k . Let F n G i j n i (,), 1≤≤ be the route set departing processor i over link (i,j ) sharing the n th stream 16;

clearly F F i n i j n (,)(,)?? since the route sets may never be recombined. The n th route set F i n (,)? is said to

be "present" at a processor i having arrived from some upstream processor.

The algorithm is executed by the source processor l . The computation begins by considering the initial route set F D E j k (,)?=∪1 at the source processor. Let r D E m D E m k k ∈∪≤≤∪,1 denote the m th route. Let L r l m () be the next processor downstream from processor l for route r m ; this is obtained from the routing label RL i p r m where p r m is the RP at which route r m terminates. Let

H X L r l l m r X m ()()=∈U be the set of processors downstream from a processor l w.r.t. the routes in a

route set X . A typical step of the algorithm concerns a processor l and a set

F F F F

G l l l n l i =≤??{,,}, (,)(,)1K of route sets present at the processor. For each route set F l n (,)?,since there exists a downstream link (,),()(,)l m m

H F i i l n ?∈?, the computation generates the sets

F F l m n l m n k k (,)(,),,1

1K from the set F l n (,)?. If k H F l n =()>?()(,)1, meaning there are multiple downstream links, then the stream is replicated at processor l . For each generated route set F l m n (,), the computation adds the link bandwidth φ(,)l m , obtained from the routing label for any 17 route in the set sharing the stream, to the total allocated bandwidth B E k (). Each generated set F l m n (,) is added to set F m of route sets at a downstream processor m . The computation step is repeated at any processor l with a non-empty set F l and terminates when all RPs have been reached. The procedure is repeated for each permutation and the permutation resulting in the minimal total allocated bandwidth is chosen.

16 Initially, there is just one stream as mentioned previously. However, during the computation, this stream

eventually divides into as many streams as there are RPs. A stream is always identified by its signal, the current set of RPs to which it is heading and the route over which it has traveled. When a stream is heading to only a single RP, it is synonymous with a route.17 The same "maximum" value is stored in the routing label for all routes in the set.

Once a choice is made, the source generates a "selection" packet. The packet indicates which routes and corresponding reservations have been "selected," the understanding being that any route or reservation not selected should be discarded or deallocated, respectively. A selection packet contains the following fields (,,,,),g s G L m i j i i i α, where the first four fields are the same as an allocation packet and where L i is a set of pairs (,)p RL j i p j , one pair for each RP p G j i ∈, each pair consisting of the RP p j and the route RL i j j k l m i p j ={(,),(,),,(,)}K over which it is reached. The packet is sent downstream in the same fashion as the allocation packet, being replicated as necessary and covering the same set of routes.

On reception of a selection packet at a processor l , the processor examines the packet and removes all unselected entries from the temporary portions of its incoming and outgoing link profiles. Any corresponding reservation placeholders are deallocated and the routing table entries are similarly modified. Selected placeholders are moved to the permanent portion of the allocation table and become permanent reservations. Similarly, the selected entries in the link profiles are moved to the permanent portion.

Note that while the same network portion is covered by the propagation as in the allocation phase,the number of packet transmissions is lessened. This reduction is possible because each propagating copy of the packet contains the same information. When a processor receives the packet, it makes the necessary modifications to its tables and forwards the packet as in the allocation phase. However, once it has already received one copy, it may discard any subsequent copies without processing or forwarding.

3.2 RP-to-Destination Routing

In RBM, as in PIM, destinations subscribe to RPs to obtain the signals they desire. In PIM, since each RP always has all the group's signals, a destination typically selects the nearest RP from which to obtain the desired signals. This selection is not always be possible or desirable in RBM.Because of limited bandwidth, the nearest RP may not receive all the desired signals or may receive them, but at QoS levels insufficient for the destination's needs. Also, in real-time applications, the delivery thresholds required at the destination may have already been exceeded at that RP. Thus,before RP-to-destination routing is attempted, it can be advantageous to first determine which RPs possess the desired signal characteristics and "select" these promising RPs as candidates for routing. Note, however, that selecting a RP to deliver a given signal does not guarantee that a satisfactory route can be found to the destination due to bandwidth limitations or real-time constraints.

对等网络模式

一、对等网简介 “对等网”也称“工作组网”，那是因为它不像企业专业网络中那样是通过域来控制的，在对等网中没有“域”，只有“工作组”，这一点要首先清楚。正因如此，我们在后面的具体网络配置中，就没有域的配置，而需配置工作组。很显然，“工作组”的概念远没有“域”那么广，所以对等网所能随的用户数也是非常有限的。在对等网络中，计算机的数量通常不会超过20台，所以对等网络相对比较简单。在对等网络中，对等网上各台计算机的有相同的功能，无主从之分，网上任意节点计算机既可以作为网络服务器，为其它计算机提供资源；也可以作为工作站，以分享其它服务器的资源；任一台计算机均可同时兼作服务器和工作站，也可只作其中之一。同时，对等网除了共享文件之外，还可以共享打印机，对等网上的打印机可被网络上的任一节点使用，如同使用本地打印机一样方便。因为对等网不需要专门的服务器来做网络支持，也不需要其他组件来提高网络的性能，因而对等网络的价格相对要便宜很多。 对等网主要有如下特点： （1）网络用户较少，一般在20台计算机以内，适合人员少，应用网络较多的中小企业； （2）网络用户都处于同一区域中； （3）对于网络来说，网络安全不是最重要的问题。 它的主要优点有：网络成本低、网络配置和维护简单。 它的缺点也相当明显的，主要有：网络性能较低、数据保密性差、文件管理分散、计算机资源占用大。 二、对等网结构 虽然对等网结构比较简单，但根据具体的应用环境和需求，对等网也因其规模和传输介质类型的不同，其实现的方式也有多种，下面分别介绍： 1、两台机的对等网 这种对等网的组建方式比较多，在传输介质方面既可以采用双绞线，也可以使用同轴电缆，还可采用串、并行电缆。所需网络设备只需相应的网线或电缆和网卡，如果采用串、并行电缆还可省去网卡的投资，直接用串、并行电缆连接两台机即可，显然这是一种最廉价的对等网组建方式。这种方式中的“串／并行电缆”俗称“零调制解调器”，所以这种方式也称为“远程通信”领域。但这种采用串、并行电缆连接的网络的传输速率非常低，并且串、并行电缆制作比较麻烦，在网卡如此便宜的今天这种对等网连接方式比较少用。 2、三台机的对等网

五款最好的免费电脑资料同步备份软件

文件夹同步就是将两个文件夹内的文件内容进行分析，可选择性的让两个文件夹内容保存一直。文件夹同步软件相当有用，虽然大多数人没用过，但它确实能够为你节省很多时间和操作。比如说：同步U盘上的数据和软件设置，查找软件版本区别和更新，同步FTP上的数据。我认为，很多情况下使用同步软件可以极大提高计算机操作效率。 高效文件同步工具GoodSync 在多种驱动设备之间自动同步和备份，（个人电脑、移动设备、网络设备）支持任何文件类型，支持多任务、多语言。人性化的界面，可自由选择部分单向双向同步，有强大的过滤系统，有完整的日志记录及更改内容报表。 注意：GoodSync分析之后会在任务文件夹生成“_gsdata_”的隐藏文件夹，里面存放在任务日志和备份文件。GoodSync有免费版和专业版之分。免费版在30天内没有任何限制，仅仅是不能可用于商业用途和政府机构。过来三十天依然可以免费使用，但是仅支持3个任务（相比很多单任务的还是强大不少）和每次100文件夹的同步工作（一般情况下够）。下载 开源同步软件FreeFileSync 界面简洁，操作简单。虽然是单任务，但是可以保存和加载配置。最重要的是，作为一款开源如软件，它没有任何限制。下载

多文件夹同步器Allway Sync Allway Sync 是一个非常容易使用的 Windows 文件同步软件。同样支持在多种设备进行同步、多向同步（1个文件夹到N个）、自动同步。有极其强大的过滤规则、错误管理，可以压缩备份、加密备份。可导出导入xml格式配置文件和任务。免费版有文件大小和数量限制。当然，有着强大功能的同时，体积和资源占用也偏大。下载

(完整版)博客系统需求分析

校园博客系统需求分析 评审日期：2010 年04 月01 日 目录 1导言 (1)

1.2范围 (1) 1.3缩写说明 (1) 1.4术语定义 (1) 1.5引用标准 (1) 1.6参考资料 (2) 2系统定义 (2) 2.1项目来源及背景 (2) 2.2系统整体结构 (2) 3应用环境 (3) 3.1系统运行网络环境 (3) 3.2系统运行硬件环境 (4) 3.3系统运行软件环境 (4) 4功能规格 (4) 4.1角色（ A CTOR ）定义 (5) 4.1.1博客访问者 (5) 4.1.2管理用户 (5) 4.1.3 数据库 (6) 4.2系统主U SE C ASE图. (6) 4.3客户端子系统 (6) 4.4管理端子系统 (8) 4.4.1 登录管理 ....................................................... 10 4.4.2 类型管理 ......................................................... 11 4.4.3 评论管理 ....................................................... 12 4.4.4 留言管理 ....................................................... 12 4.4.5 图片管理 ....................................................... 12 4.4.6 用户管理 ....................................................... 13 5性能需求 (13) 5.1 界面需求 (13) 5.2响应时间需求 (13) 5.3可靠性需求 (13) 5.4开放性需求 (14) 5.5可扩展性需求 (14) 5.6系统安全性需求 (14) 6产品提交 (14)

个人博客简介

1.1 博客信息系统概述 “博客”（Blog或Weblog）一词源于“Web Log（网络日志）”的缩写，是一种十分简易的傻瓜化个人信息发布方式。任何人都可以像使用免费电子邮件一样，完成个人网页的创建、发布和更新。博客就是开放的私人空间，可以充分利用超文本链接、网络互动、动态更新等特点，在网络中，精选并链接全球互联网中最有价值的信息、知识与资源；也可以将个人工作过程、生活故事、思想历程、闪现的灵感等及时记录和发布，发挥个人无限的表达力；更可以以文会友，结识和汇聚朋友，进行深度交流沟通[1]。 “博客”当然是个大家都陌生的名词，博客的英文名词就是“Blog或Weblog”（指人时对应于Blogger），是一个典型的网络新事物，查阅最新的英文词典也不可能查到。该词来源于“Web Log（网络日志）”的缩写，特指一种特别的网络个人出版形式，内容按照时间顺序排列，并且不断更新。 博客是一种零编辑、零技术、零成本、零形式的网上个人出版方式。 博客概念一般包含了三个要素（当然，也不需要局限这些定义）： （1）网页主体内容由不断更新的、个性化的众多日志组成。 （2）按时间顺序排列，而且是倒序方式，也就是最新的放在最上面，最旧的放在最下面。 （3）内容可以是各种主题、各种外观布局和各种写作风格，但是文章内容以“超链接”作为重要的表达方式。 因此，博客是个人性和公共性的结合体，其精髓不是主要表达个人思想，不是主要记录个人日常经历；而是以个人的视角，以整个互联网为视野，精选和记录自己在互联网上看到的精彩内容，为他人提供帮助，使其具有更高的共享价值。 博客精神的核心并不是自娱自乐，甚至不是个人表达自由，相反，是体现一种利他的共享精神，为他人提供帮助。个人日记和个人网站主要表现的还是“小我”，而博客表现的是“大我”。也许形式上很接近，但内在有着本质的差异。所有优秀博客网站中，真正表达作者个人的内容非常有限，最多只是点缀，而不像个人网站那样是核心。 1.2 博客发展趋势 趋势一：博客现在正在形成个人的信誉机制，有了博客之后就确立了一个个人虚拟身份，简单的来讲就是个人在互联网上是有名有姓的，而不再是一种匿名的行为，网民从流浪汉变成了一个定居者。以前在互联网上的各种行为都是在匿名状态中，相互之间是不认识的，但有了博客之后可以天天关注，而别的人也可

汇博通文档借阅管理组织系统软件使用使用说明

汇博通文档借阅管理系统使用说明书 汇博通知识管理系统的属性管理，实际上已提供了借阅与归还功能，但那是针对每一份文件 或档案而言的。 这里，为客户提供一款专门用于文档的借阅与归还的软件，不但可办理一份文件的借阅或归 还手续，只要有需要，也可批量办理借阅与归还，另外，还提供了与借阅有关的一系列统计 报表。 发放功能与借阅类似，所不同的只是发放不必归还，如将购买的资料、图书发放给职员学习 等。 注：借阅与归还模块的操作，需要获得以下三种权限中的一种： 系统管理员 归档授权（档案管理员） 编号授权（文件管理员） 与借阅与归还模块相关的系统参数的设置说明如下：

首页 汇博通主页的模块工具条上，有一个借阅与归还的按钮，单击它即进入借阅与归还首页。 借阅（发放） 前面已经介绍过，借阅与发放的区别在于，借阅需要归还，发放则不必归还，从某种意义上 来说，发放实际上已将所有权（或有条件的所有权）转移给接收者。 借阅界面包括左右两个子窗体，左侧子窗体用于显示可供借阅（发放）的文档，其上部有搜 索关键词输入框，输入相应关键词即可查找出可供借阅的相应文档，如果要借阅的文档已经 在操作者手上，并且，标注有条形码或电子标签，操作者可直接通过条码阅读器或电子标签

阅读器读取相应编码直接获取到该文档。 根据实际需要，通过点选左侧的复选框，选择具体文档，然后，通过点击两个子窗体中间的箭头，即可将选中的文档添加到右侧子窗体的列表中，即可直接办理借阅或发放手续。 可供借阅（发放）检索列表待选区。借阅（发放）选择勾选列表区。 可供借阅（发放） 输入文件名称、编号、责任者或主题词等属性，点击【检索】按钮进行查找，如下图： 勾选确定后点击该按钮，即可添加到已 选择列表区中。

如何使用群晖备份、同步文件

如何使用群晖备份、同步文件？通过群晖管家安装好NAS之后，想要实现备份、同步还要随时随地查看所有的文件？只需要一个Drive，就能把你的需求统统搞定。让你轻松的掌握文件同步和备份。 Drive既是备份盘、同步盘、网盘，还可以是协作盘。集中管理所有文件，还能够同步不同电脑上的数据。团队脑风暴时，可以多人在同一个文档上实时协同编辑，还能够备份电脑上的文件并且提供多版本保护。 安装及设置drive套件 1、打开群晖DSM界面，在套件中心安装Drive套件。 2、安装Drive套件会一并安装Drive管理控制台——顾名思义，就是可以设置Drive 相关功能、管理所有备份和同步的设备、查看历史版本等。 3、建议你在Drive管理控制台启用深度搜索，就可以在Drive里面查找内文关键字还有照片各种原始信息，步骤如图。

设置备份盘 1、首先进入群晖官网的下载中心，根据NAS机型，选择下载“Drive Client”PC客户端，Windows、Mac、Ubuntu一应俱全，系统兼容妥妥的。 2、PC客户端安装完成后，根据需求修改Drive服务器（NAS端）和电脑（本地端）的不同文件夹。 3、设置完成后，进入Drive PC客户端的控制面板，将同步模式改成“单向上传”，点击应用，然后就开始备份啦。 同步盘如何实现 1、同步盘很简单，设置步骤跟上面的备份盘一样，在需要同步的电脑上安装Drive PC客户端，并且选择双向同步。 2、如果在办公场景，希望把他人分享给你的共享文件夹同步到电脑本地，在PC客户 端控制面板点击“创建>启用同步与我共享”，这么一来，别人与你分享的文件也会同步到本地。

日志分析系统

Web日志集中管理系统的研究与实现 吴海燕朱靖君程志锐戚丽 （清华大学计算机与信息管理中心，北京100084） E-mail：wuhy@https://www.wendangku.net/doc/c213511893.html, 摘要： Web服务是目前互联网的第一大网络服务，Web日志的分析对站点的安全管理与运行维护非常重要。在实际运行中，由于应用部署的分散性和负载均衡策略的使用，使得Web日志被分散在多台服务器上，给日志的管理和分析带来不便。本文设计并实现了一个Web日志集中管理系统（命名为ThuLog），系统包括日志集中、日志存储和日志分析三个模块。目前，该系统已经在清华大学的多个关键Web应用系统上进行了应用，能够帮助系统管理员清晰地了解系统运行情况，取得了较好的运行效果。 关键词：Web日志日志分析日志集中管理系统 The Research and Implementation of a Centralized Web Log Management System Wu Haiyan Zhu Jingjun Cheng Zhirui Qi Li (Computer&Information Center,Tsinghua University,Beijing100084) Abstract：Web is now the biggest network service on the Internet.The analysis of Web logs plays an important role in the security management and the maintenance of a website.But because of the decentralization of deployment and the use of load balancing,Web logs are often seperated on each Web server,which makes the management and analysis of them not so convenient.This paper designs and implements a Web Log Centralized Management System(named ThuLog),which includes3modules:the centralization of logs,the storage of logs and the analysis of logs.Through log analysis of several critical Web systems in Tsinghua University,it could help system administrators learn clearly what happens in information systems and achieves good operating results. Key words：Web Logs Log Analysis Web Log Centralized Management System 1.引言 近年来，随着计算机网络技术的迅速发展，Web正以其广泛性、交互性、快

博客系统需求分析报告

博 客 系 统 需 求 分 析 报 告 院系：信息电子工程学院 班级：软件08-1 设计小组人员：29号 日期：2010年5月24日

一、系统概述 “博客”一词是从英文单词Blog音译（不是翻译）而来。Blog是Weblog 的简称，而Weblog则是由Web和Log两个英文单词组合而成。 Weblog就是在网络上发布和阅读的流水记录，通常称为“网络日志”，简称为“网志”。博客（BLOGGER）概念解释为网络出版（Web Publishing）、发表和张贴（Post-这个字当名词用时就是指张贴的文章）文章，是个急速成长的网络活动，现在甚至出现了一个用来指称这种网络出版和发表文章的专有名词——Weblog，或Blog。 在网络上发表Blog的构想始于1998年，但到了2000年才开始真正流行。而2000年博客开始进入中国，并迅速发展，但都业绩平平。直到2004年木子美事件，才让中国民众了解到了博客，并运用博客。2005年，国内各门户网站，如新浪、搜狐，原不看好博客业务，也加入博客阵营，开始进入博客春秋战国时代。起初，Bloggers将其每天浏览网站的心得和意见记录下来，并予以公开，来给其他人参考和遵循。但随着Blogging快速扩张，它的目的与最初已相去甚远。目前网络上数以千计的Bloggers发表和张贴Blog的目的有很大的差异。不过，由于沟通方式比电子邮件、讨论群组更简单和容易，Blog已成为家庭、公司、部门和团队之间越来越盛行的沟通工具，因为它也逐渐被应用在企业内部网络（Intranet）。目前，国内优秀的中文博客网有：新浪博客，搜狐博客，中国博客网，腾讯博客，博客中国等。 二、需求分析 博客系统是一个多用户、多界面的系统，主要包括以下几个模块组成。 1.匿名用户模块 本模块主要由注册、登录、浏览博客、评论4个部分组成。匿名用户可以对其他用户的博客内容时行浏览、评论。也可以通过注册后登录博客系统，申请一个属于自己的博客。 2.注册用户模块 本模块主要由个人信息管理、评论管理、好友管理、相册管理、文章管理5

人力资源管理系统软件操作手册

XX集团—人力资源管理系统操作手册 目录 常用操作（新人必读） (2) 1.基础数据管理 ................................................................................................................... - 5 - 1.1组织架构 (5) 1.2职位体系 (8) 1.3职员维护 (11) 1.4结束初始化.................................................................................. 错误！未定义书签。 2.组织管理业务 ................................................................................................................. - 27 - 2.1组织规划 (27) 2.2人力规划 (33) 2.3组织报表 (38) 3.员工管理业务 ................................................................................................................. - 41 - 3.1员工状态管理 (41) 3.2合同管理 (41) 3.3后备人才管理 .............................................................................. 错误！未定义书签。 3.4人事事务 (52) 3.5人事报表 (59) 4.薪酬管理 ......................................................................................................................... - 69 - 4.1基础数据准备 (69) 4.2薪酬管理日常业务 (92) 4.3薪酬管理期末业务 (107) 4.4薪酬报表 (108)

对等网络配置及网络资源共享

物联网技术与应用 对等网络配置及网络资源共享 实验报告 组员：

1.实验目的 （1）了解对等网络基本配置中包含的协议，服务和基本参数 （2）了解所在系统网络组件的安装和卸载方法 （3）学习所在系统共享目录的设置和使用方法 （4）学习安装远程打印机的方法 2.实验环境 Window8，局域网 3.实验内容 （1）查看所在机器的主机名称和网络参数，了解网络基本配置中包含的协议，服务和基本参数 （2）网络组件的安装和卸载方法 （3）设置和停止共享目录 （4）安装网络打印机 4.实验步骤 首先建立局域网络，使网络内有两台电脑 （1）“我的电脑”→“属性”，查看主机名，得知两台计算机主机名为“idea-pc”和“迦尴专属”。 打开运行输入cmd，进入窗口输入ipconfig得到相关网络参数。局域网使用的是无线局域网。 （2）网络组件的安装和卸载方法：“网络和共享中心”→“本地连接”→“属

性”即可看到网络组件，可看其描述或卸载。 “控制面板”→“卸载程序”→“启用和关闭windows功能”，找到internet 信息服务，即可启用或关闭网络功能。 （3）设置和停止共享目录（由于windows版本升高，加强了安全措施和各种权

限，所以操作增加很多） 使用电脑“idea-pc”。“打开网络和共享中心”→“更改高级选项设置”。将专用网络，来宾或公用，所有网络中均选择启用文件夹共享选项，最下面的密码保护项选择关闭，以方便实验。 分享文件夹“第一小组实验八”，“右键文件夹属性”→“共享”→“共享”，选择四个中的一个并添加，此处选择everyone，即所有局域网内人均可以共享。

销售管理软件操作手册

前言 本《操作手册》内容是按该软件主界面上第一横排从左至右的顺序对各个功能加以介绍的，建议初学者先对第一章系统设置作初步了解，从第二章基础资料读起，回头再读第一章。该管理软件的重点与难点是第二章，望读者详读。 第一章系统设置 打开此管理软件，在主界面上的左上方第一栏就是【系统设置】，如下图所示： 点击【系统设置】，在系统设置下方会显示【系统设置】的内容，包括操作员管理、数据初始化、修改我的登录密码、切换用户、选项设置、单据报表设置、导入数据、数据库备份、数据库恢复、压缩和修复数据库、退出程序。下面分别将这些功能作简要介绍： 1.1操作员管理 新建、删除使用本软件的操作员，授权他们可以使用哪些功能。此功能只有系统管理员可以使用。 1.1.1 进入界面 单击【系统设置】，选择其中的【操作员管理】，画面如下：

1.1.2、增加操作员 单击【新建】按钮，画面如下： 输入用户名称、初始密码、选择用户权限，可对用户进行适当描述，按【保存】后就点【退出】，就完成了新操作员的添加，效果如下图。

1.1.3 删除操作员 选择要删除的操作员，单击【删除】按钮。 1.1.4 修改操作员 选择要修改的操作员，单击【修改】按钮，可对操作员作相应修改，修改后需保存。 1.1.5 用户操作权限 选择要修改的操作员，单击【修改】按钮，出现以下画面，点击【用户权限】栏下的编辑框，出现对号后点【保存】，该操作员就有了此权限。 1.2数据初始化 1.2.1进入界面 单击【系统设置】，选择其中的【数据初始化】，画面如下：

1.2.2数据清除 选择要清除的数据，即数据前出现对号，按【确定】后点【退出】，就可清除相应数据。 1.3 修改我的登录密码 1.3.1进入界面 单击【系统设置】，选择其中的【修改我的登录密码】，画面如下： 1.3.2密码修改 输入原密码、现密码，然后对新密码进行验证，按【确定】后关闭此窗口，就可完成密码修改。 1.4 切换用户 1.4.1进入界面 单击【系统设置】，选择其中的【切换用户】，画面如下：

对等网络(P2P)总结整理解析

对等网络(P2P 一、概述 (一定义 对等网络(P2P网络是分布式系统和计算机网络相结合的产物,在应用领域和学术界获得了广泛的重视和成功,被称为“改变Internet的新一代网络技术”。 对等网络(P2P:Peer to Peer。peer指网络结点在: 1行为上是自由的—任意加入、退出,不受其它结点限制,匿名; 2功能上是平等的—不管实际能力的差异; 3连接上是互联的—直接/间接,任两结点可建立逻辑链接,对应物理网上的一条IP路径。 (二P2P网络的优势 1、充分利用网络带宽 P2P不通过服务器进行信息交换,无服务器瓶颈,无单点失效,充分利用网络带宽,如BT下载多个文件,可接近实际最大带宽,HTTP及FTP很少有这样的效果 2、提高网络工作效率 结构化P2P有严格拓扑结构,基于DHT,将网络结点、数据对象高效均匀地映射到覆盖网中,路由效率高 3、开发了每个网络结点的潜力 结点资源是指计算能力及存储容量,个人计算机并非永久联网,是临时性的动态结点,称为“网络边缘结点”。P2P使内容“位于中心”转变为“位于边缘”,计算模式由“服务器集中计算”转变为“分布式协同计算”。

4、具有高可扩展性(scalability 当网络结点总数增加时,可进行可扩展性衡量。P2P网络中,结点间分摊通信开销,无需增加设备,路由跳数增量小。 5、良好的容错性 主要体现在:冗余方法、周期性检测、结点自适应状态维护。 二、第一代混合式P2P网络 (一主要代表 混合式P2P网络,它是C/S和P2P两种模式的混合;有两个主要代表: 1、Napster——P2P网络的先驱 2、BitTorrent——分片优化的新一代混合式P2P网络 (二第一代P2P网络的特点 1、拓扑结构 1混合式(C/S+P2P 2星型拓扑结构,以服务器为核心 2、查询与路由 1用户向服务器发出查询请求,服务器返回文件索引 2用户根据索引与其它用户进行数据传输 3路由跳数为O(1,即常数跳 3、容错性:取决于服务器的故障概率(实际网络中,由于成本原因,可用性较低。

多文件夹的自动同步和各向同步工具

多文件夹的自动同步和各向同步工具 出处：小建の软件园作者：佚名日期：2008-06-25 关键字：同步 对于经常需要备份文件，同步文件的网友，Allway Sync 可谓不可多得，虽然不能激活其专业版，对文件数量多和经常性的同步操作可能会超过免费版的限制，不过对于一般文件数量不多同步操作可以完全满足，Allway Sync 使用相当简单，多种同步方式能满足你不同需求。对重要文件进行备份是文件恢复最好的方法，而 Allway Sync 可以简化你许多备份的过程，能实现自动备份，如果你“胃口”不大，免费版应当已经可以满足。 下载地址：https://www.wendangku.net/doc/c213511893.html,/soft/23495.html Allway Sync 可以进行自动同步，可以对的文件/文件夹进行筛选，只备份需要的东东。

Allway Sync 备份方式介绍 - 同步方式有源文件夹同步和各向同步两种方式： 1、源文件夹同步方式将以一个文件夹为基准，删除或覆盖其余文件夹与源文件相比较不相同的文件。 2、各向同步方式则自动将更新的文件覆盖几个同步文件夹中的旧文件。软件带有一个小型数据库，监视每次更新后的文件状态。如果在一次同步之后，你删除了同步文件夹中某些文件，它在同步的时候将其它的几个文件夹的副本也删除，而不会将不需要的未删除文件重复拷贝到已更新的文件夹。由于软件自己会对文件进行删除和覆盖，它提供了使用回收站进行文件备份的措施，使用者可以在不慎执行错误的同步动作之后，从回收站将错误删除或覆盖的文件找回来（默认禁用该功能，请到软件选项处激活相应设置）。 主程序在 AllwaySync＼Bin＼里面，此为多国语言版，在语音选项那里选择中文即可。不过退出的时候会有错误提示（貌似没影响？）

博客系统需求分析报告1

系统需求分析和概要设计 1 系统需求分析 1.1 开发背景 过去很多人都喜欢写文章写日记以及交流自己的文章和作品，以求实现相互间的沟通、展现自己的才华和让别人了解自己的想法观点。现在的网络已经成为人们生活中不可或缺的一个元素，所以自然而然诞生了博客这样一个新兴事物，它不仅仅能取代前面所说的功能，还能加入图片，而且使得作者更能无所拘束地生动地写出自己想写的，旁人也能非常便捷地阅读并且加以评论，并且它还能作为展示个人个性的窗户。个人博客现在已经成为很多人生活中必不可少的一个部分，方便了人与人之间的沟通和交流。 1.2 系统实现目标概述 基于个人博客以上的特点，本系统要实现个人博客的主要基本功能有主界面，博客用户登录发表文章（心情、日志），用户登录/退出，游客发表评论，分页浏览文章和评论等。这里其中比较主要的是区分了个人博客用户和游客。博客用户可以在任何时候写下自己的主张，记录下自己的点点滴滴。而游客主要的权限是阅读博客所有注册用户写的文章，阅读后可以发表评论和留言，还可以分页浏览所有注册用户上传的图片。以上是个人博客的系统功能目标，当然由于个人博客的网络流行特点以及个人个性的展示，还适当要求界面比较漂亮轻快，直观便捷，操作方式简单以及人性化。 1.3 系统功能需求 根据对系统的特点和应用的分析，可以得到本系统主要有如下功能： （1）登录 这部分功能又分为用户登录、用户退出两个部分。 登录：主要用于验证博客网站用户信息的真实身份，以便对博客网站进行管

理和维护。通过系统管理员写入的用户名，密码登录到网站。网站检测用户的用户名，密码并给予其相应的权限对博客网站进行操作。 用户退出：已经登陆的用户可以退出，释放自己所占有的各种信息资源。 （2）文章管理 文章管理主要有文章的发表、查询、浏览、评论和删除功能。 博客的系统管理员除了可以查询、浏览和评论文章外，还可以对系统中的所有文章以及评论进行修改、删除操作。这些维护和管理拥有最高权限，并且系统自动更新在服务器端数据库中的数据。 文章的发表：博客用户可以发表自己的文章，文章包括主题、正文、表情、图片等信息，作者通过各种元素来展示自己的想法和思想。系统接受这些信息并且存储在服务器端的数据库中。 文章的删除：博客用户可以删除自己已经发表的文章内容和各项信息，系统自动在服务器端数据库中删除这些记录。 文章的浏览：游客和博客用户根据所获得的用户权限获取服务器端数据存储的各篇文章并且浏览阅读文章的所有信息，包括标题、正文、表情、图片以及其它读者的留言评论。 文章的评论：文章的读者可以评论和回复所阅读的文章，发表自己的看法。系统自动将这些评论存储在服务器端的数据库中，并且可供博客作者以及其它读者浏览。 文章的查询：博客用户可以按文章题目或作者来查询想要查的文章。 文章中还可能包含一些图片视频等多媒体,所以文章管理中还包含了网站中媒体的管理。 媒体管理有添加，浏览、删除和查询功能。博客用户可以添加自己喜欢的图片或视频等，还可以查询和浏览系统中的所有媒体信息。游客只能浏览博客系统中的媒体信息。系统管理员拥有以上的所有权限，除此之外还可以删除媒体信息。 （3）博客管理员管理 博客管理员可以添加、删除新用户，用户的角色又分为订阅者、作者、编辑、投稿者、管理员。 还可以对博客主页的外观、博客使用的插件、工具进行添加、删除、设置。

博客作用

1.过滤信息 在这个网络信息泛滥的时代，网上的信息太多、太杂、太乱，学习者无法判别哪些信息是有价值的，哪些是重要的。教师可以通过博客将经过过滤过的信息传递给学生，而学生也可以通过博客将信息传递给他的伙伴。通过浏览别人的博客日志，知识获取的效率将得到很大的提高。 2.提供学习的丰富情境 通常的教辅网站，只是提供一些参考资料的链接，而博客则提供更多的评价，更广泛的背景资料。有一些学者通过博客日志反映他们对某些问题的认识，开始对于这些问题的看法可能也是粗糙的，但是他们将这些思想表达出来，然后在博客上发表后续的看法。在这一过程中，专家可以将最近看了哪些书，读了哪些人的文章，听取了哪些意见都通过博客方式表达出来。这样，阅读者了解的不仅仅是专家静态的、目前的观点，而重要的是可以把握专家思想的流程。同样，这一方式对于学生来讲也是有效的，学生的博客日志可以反映出他们在学习过程中产生的问题、关于问题的想法与思路、问题的解决过程，使得教师可以更有效地了解学生的学习状况。 3.提高学生的媒体文化水平 博客（blog）的个人化使得博客们（blogger）在信息发布的过程中，要采用最适当的方式对信息进行过滤与说明，使得他的博客日志能够为更多的人接受，使得他的思想和资源为更多的人所了解。与传统BBS相比，博客日志具有更强的规范性，博客们具有更强的自律性。由于博客一般是由个人或小组拥有的，通常具有共同的主题，所谓敝帚自珍，所以在博客的世界中，很少出现在BBS中常见的不负责任的"胡说八道"。 4.鼓励参与者发表自己不同的观点 博客的模式是平等的，博客更看重的是参与的过程而不是结果。对于教师或书本上的观点，学生可以通过博客的方式发表他对于这些问题的理解，博客并不要求意见的统一，但要求意见的针对性和独立性。另外，在课程设置的过程中可以设置多个不同的议题，允许学生自由地选择他们感兴趣的议题。 5.提供对信息的评价 博客的重要特征就是对信息的过滤，使得信息可以转换成有用的知识。但是

对等网络的网络弹性分析

对等网络的网络弹性分析 摘要：网络弹性研究的是网络在节点失效或被有意攻击下所表现出来的特征。分析Gnutella网络的网络弹性，包括对于随机攻击的容错性和对于选择性攻击的抗攻击性，并与ER模型和EBA模型进行了对比。Gnutella网络对于随机攻击具有很好的容错性，但是对于选择性攻击却显得脆弱。最后对网络弹性进行了理论分析，给出了网络在出现最大集团临界点之前的平均集团大小的公式解。 关键词：对等网络；无标度；网络弹性；脆弱性 中图分类号：TP393.02文献标识码：A 文章编号：1001-9081(2007)04-0784-04 0 引言 在过去的40多年里，科学家习惯于将所有复杂网络看作是随机网络。随机网络中绝大部分节点的连结数目会大致相同。1998年开展的一个描绘互联网的项目却揭示了令人惊诧的事实：基本上，互联网是由少数高连结性的页面串联起来的，80%以上页面的连结数不到4个，而只占节点总数不到万分之一的极少数节点，例如门户网Yahoo和搜索引擎Google等类似网站，却高达上百万乃至几十亿个链接。研究者把包含这种重要集散节点的网络称为无标度网络[1]。

具有集散节点和集群结构的无标度网络，对意外故障具有极强的承受能力，但面对蓄意的攻击和破坏却不堪一击[2]。在随机网络中，如果大部分节点发生瘫痪，将不可避免地导致网络的分裂。无标度网络的模拟结果则展现了全然不同的情况，随意选择高达80%的节点使之失效，剩余的网络还可能组成一个完整的集群并保持任意两点间的连接，但是只要5%―10%的集散节点同时失效，就可导致互联网溃散成孤立无援的小群路由器。 许多复杂网络系统显示出惊人的容错特性，例如复杂通信网络也常常显示出很强的健壮性，一些关键单元的局部失效很少会导致全局信息传送的损失。但并不是所有的网络都具有这样的容错特性，只有那些异构连接的网络，即无标度网络才有这种特性，这样的网络包括WWW、因特网、社会网络等。虽然无标度网络具有很强的容错性，但是对于那些有意攻击，无标度网络却非常脆弱。容错性和抗攻击性是通信网络的基本属性，可以用这两种属性来概括网络弹性。 对等网络技术和复杂网络理论的进展促使对现有对等 网络的拓扑结构进行深入分析。对网络弹性的认识可以使从网络拓扑的角度了解网络的脆弱点，以及如何设计有效的策略保护、减小攻击带来的危害。本文研究Gnutella网络的网络弹性，并与ER模型和EBA模型进行了比较，对比不同类 型的复杂网络在攻击中的网络弹性。当网络受到攻击达到某

备份软件使用方法v1.0

备份软件使用方法 一Bestsync2012使用说明 1 软件运行 点击BestSync2012运行软件 2 设置任务 在编辑菜单下点击追加任务（如果任务列表下没有任务可以在文件菜单下选择新建任务选项） 软件会弹出任务窗口，用来设置同步任务

以其中一个任务为例

选择好同步的文件夹和同步方向，点击下一步，按照要求设置任务即可。 3 查看任务 在以有任务中点击设置任务（任务必须是未在同步状态，否者不能点击设置任务选项）

点击后软件会弹出设置同步任务窗口，在这里可以在里面进行任务修改和设置

目前我们设置的同步任务只需要修改一般和日程两个窗口下的内容，其他暂时不需要修改。 BestSync2012这款同步软件目前还不是很稳定，需要不定期检查一下软件是否运行正常，如果发现软件出错，就关闭软件后在打开BestSync2012软件，因为打开软件后软件不会自动启动同步功能，所有需要手动启动所有任务 注意： 1 在修改任务在开启后，必须将修改的任务停止一下在开启，不然同步任务不能正常同步。 2 现有BestSync2012同步软件在16.15和151.247这两台机器上。

二Backup Exec 2010 R2 SP1使用说明 1 软件运行 点击Backup Exec 2010运行软件 2 设置任务 在作业设置选项中可以看到作业的作业名称、策略名称和备份选这项列表。 其中作业名称里放有现有作业，双击其中一个作业就可以看到作业属性。作业属性默认显示设备和介质窗口，在设备和介质窗口下可以选择设备和介质集。目前设备选项中因为只有一台磁带机工作，所有只有一个选项，而介质集一般选择永久保留数据-不允许覆盖选项。

博客需求分析

博客系统需求分

一、系统概述 “博客”一词是从英文单词Blog音译（不是翻译）而来。Blog是Weblog 的简称，而Weblog则是由Web和Log两个英文单词组合而成。 Weblog就是在网络上发布和阅读的流水记录，通常称为“网络日志”，简称为“网志”。博客（BLOGGER）概念解释为网络出版（Web Publishing）、发表和张贴（Post-这个字当名词用时就是指张贴的文章）文章，是个急速成长的网络活动，现在甚至出现了一个用来指称这种网络出版和发表文章的专有名词——Weblog，或Blog。 在网络上发表Blog的构想始于1998年，但到了2000年才开始真正流行。而2000年博客开始进入中国，并迅速发展，但都业绩平平。直到2004年木子美事件，才让中国民众了解到了博客，并运用博客。2005年，国内各门户网站，如新浪、搜狐，原不看好博客业务，也加入博客阵营，开始进入博客春秋战国时代。起初，Bloggers将其每天浏览网站的心得和意见记录下来，并予以公开，来给其他人参考和遵循。但随着Blogging快速扩张，它的目的与最初已相去甚远。目前网络上数以千计的Bloggers发表和张贴Blog的目的有很大的差异。不过，由于沟通方式比电子邮件、讨论群组更简单和容易，Blog已成为家庭、公司、部门和团队之间越来越盛行的沟通工具，因为它也逐渐被应用在企业内部网络（Intranet）。目前，国内优秀的中文博客网有：新浪博客，搜狐博客，中国博客网，腾讯博客，博客中国等。 二、需求分析 博客系统是一个多用户、多界面的系统，主要包括以下几个模块组成。 1.匿名用户模块

博客简介

漫漫教学路，博客伴我行能在互联网上拥有一个真正属于自己的空间，是我的梦想，而 今天这个梦想在“博客”中实现了。我怀着一颗好奇心，在博客上流连，申请了一方属于自己的免费空间，置身于梦幻秋天的背景下，设置自己喜欢的几个栏目，于是我便拥有了博客。当我第一次在博客中添加文章的时候，兴奋得无法入眠。我想：平素与网络无缘的我也终于拥有了一个网上家园。一个可以让我任意挥洒激情、记录人生轨迹的网上家园。感谢博客给我一块自由的空间，让我展翅飞翔！在与博客“亲密接触”的日子里，我深深地感觉到博客对教育的促进，对自身专业化成长的帮助。 在开始的时候，我也只是摘录一些自己感兴趣的信息，很少有经过自己思考的原创日志。随着对博客认识的加深，以及浏览其他著名博客所受到的启示，我也试着把自己在教育中的思考及时记录下来。就这样我在博客里“书写着，记录着，思考着，分享着，品味着，学习着”，在不断地积累中感受着学习的乐趣。在博客里写作已经逐渐成为我的一种习惯，在博客中我不断地阅读、书写，在阅读、书写中释放心情，这让我感到在博客中学习竟是如此快乐。我在博客中开设了心灵随笔，教学案例，教学反思，教学相长，教学设计，教学论文，主题中队会等栏目…… 作为一名教师，我深深地认识到：要想鼓励、指导学生写出好的文章，教师必须要有过硬的写作基本功，博客中的心灵随笔这个栏目正好为我提供了这样一个平台，我在这个栏目中及时捕捉教学生活中细微的瞬间，从中悟出深刻的道理，并马上形成文字。例如：《让心灵跟着爱飞翔》、《如何赏识学生》、《感动》、《怎样转变学生的不良习惯》等文章。心灵的感悟，出乎意料的发挥了作用，有了这样的历练，对学生进行写作指导和评改，就驾轻就熟了。学生也会在老师的指导下逐渐明白，写作并不是一件很难的事情，只要真实的记录自己在生活中的所见、所闻，有了自己的感悟，慢慢就会写出具有真情实感的文章。 在博客中记录教学过程是一个不断充实自己，提高自己的过程，教学中我也曾遇到过很多困惑，于是把这些困惑书写到我的博客中，期待与博友们交流和切磋。博友们的热心触发了我很多灵感，常常使我茅塞顿开……我现在博客中的教学案例就是平时点滴的积累。《位置与方向》《那只松鼠》《笔算除法》《商中间、末

管理软件使用说明书

目录 1 软件介绍...................................................... １ 2 软件运行环境 ................................................. １ 3 软件安装步骤 ................................................. １ 4 软件卸载步骤 ................................................. ４ 5 软件使用...................................................... ４5.1、创建数据库.............................................................................................................................. ４ 5.2、创建数据数据表................................................................................................................... ６ 5.3、历史数据读取 ........................................................................................................................ ７ 5.4、查看历史数据、通道信息.............................................................................................. ８ 5.5、打印数据、曲线或图片输出 .................................................................................... １３ 5.6、数据实时采集 .................................................................................................................... １５ 6 软件使用中可能出现的问题与解决方法.................. １８6.1、不出现对话框 .................................................................................................................... １８ 6.2、数据库不能建立............................................................................................................... １８ 6.3、U盘不能数据转存........................................................................................................... １８ 6.4、U盘上没有文件 ................................................................................................................ １８ 6.5、U盘数据不能导入计算机；...................................................................................... １８