ࡱ> syxY qbjbjWW E==]@0 &  $. . . . P~ *. NK*(*!m$dKKKKKKK$.M"O9K %%%9K12 2 **g*111%2 l* *K2 0 64 2 2 %K1n1;5YGj , K*\]㼾. . *6JP FILLIN \* MERGEFORMAT Fcast Scalable Multicast File Distribution: Caching And Parameter Optimizations Jim Gemmell Microsoft Research 301 Howard St., #830 San Francisco, CA 94105 USA  HYPERLINK mailto:Jgemmell@microsoft.com Jgemmell@microsoft.comEve Schooler Computer Science, 256-80 California Institute of Technology Pasadena, CA 91125 USA  HYPERLINK mailto:Schooler@cs.caltech.edu schooler@cs.caltech.edu Jim Gray Microsoft Research 301 Howard St., #830 San Francisco, CA 94105 USA  HYPERLINK mailto:Jgemmell@microsoft.com gray@microsoft.com  FILLIN \* MERGEFORMAT June 22, 1999 Technical Report  FILLIN \* MERGEFORMAT MSR-TR-99-14 Microsoft Research Microsoft Corporation One Microsoft Way Redmond, WA 98052 Abstract Reliable data multicast is problematic. ACK/NACK schemes do not scale to large audiences, and simple data replication wastes network bandwidth. Fcast, file multicasting, combines multicast with Forward Error Correction (FEC) to address both these problems. Like classic multicast, Fcast scales to large audiences, and like other FEC schemes, it uses bandwidth very efficiently. Some of the benefits of this combination were known previously, but Fcast contributes new caching methods that improve disk throughput, and new optimizations for small file transfers. Fcast is the first product based on this technology, to our knowledge. This paper describes Fcast's design, implementation, and API. Introduction Frenzied downloading that raises Internet traffic by an order of magnitude has been dubbed the Midnight Madness problem because the mad dash for files often takes place late at night or in the early morning when files are first made available. Spikes in activity have been due to a range of phenomena: popular product releases; important software updates; security bug fixes, the NASA Pathfinder vehicle landing on Mars, the Kasparov vs. Deep Blue chess match, and the Starr report. The danger of such traffic spikes lies not in the data type, but rather the distribution mechanism. For example, when Internet Explorer 3.0 (IE 3.0) was released, the number of people attempting to download the new product overloaded Microsoft web servers and saturated network links near Microsoft, as well as elsewhere. Not surprisingly, nearby University of Washington found that it was nearly impossible to get any traffic through the Internet due to congestion generated by IE 3.0 downloads. Unexpectedly, whole countries also found their Internet access taxed by individuals trying to obtain the software. These problems are caused by the web's current unicast "pull" model. A TCP connection is established between a single sender and each receiver, then the sender transmits a copy of the data once over each connection [POS81]. Each copy must traverse many of the same network links. Naturally, links closest to the sender can become heavily saturated. Nonetheless such a transmission can create bottlenecks anywhere in the network where over-subscription occurs, as evidenced by the IE anecdotes above. Furthermore, congestion may be compounded by long data transfers, either because of large files or slow links. Most individuals connect to the Internet via voice-grade links (~30 kbps) and so downloading IE 3.0 could take nearly an hour. These problems could have been avoided by using the multicast file transfer technology (Fcast) described here. In fact, using Fcast, every modem user in the entire world could have been served by a single server machine connected to the Internet via a modem, rather than the 44 machines that serve microsoft.com via two 1.2 Gbps network connections. This paper describes how Fcast combines erasure correction with a data carousel to achieve reliable multicast transfer as scalable as IP multicast itself. Multicast file transmission has been proposed before [RIZ97a, VIC97]. However, previous work focused on network efficiency. This paper, extends previous work by describing how Fcast optimizes network bandwidth for small file transmissions, and how Fcast uses caching to optimize disk throughput at the receiver. The paper also presents the Fcast API for multicast file transfer. Reliable Multicast of Files Using Erasure Correction IP multicast provides a powerful and efficient means to transmit data to multiple parties [DEE88]. However, IP multicast is problematic for file transfers. IP multicast only provides a datagram service -- best-effort packet delivery. It does not guarantee that packets sent will be received, nor does it ensure that packets will arrive in the order they were sent. Many reliable multicast protocols have been built on top of multicast [BIR91, CHA84, CRO88, FLO95, GEM97, HOL95, KER98, PAU97, RAM87, TAL95, WHE95, YAV95]. Scalability was not a primary concern for most of these protocols, hence they are not useful for the midnight-madness problem. The primary barrier to scalability of these protocols is feedback from the receivers to senders in the form of acknowledgements (ACKs) or negative acknowledgements (NACKs). If many receivers generate feedback, they may overload the source, or the links leading to it, with message implosion. Some protocols, while addressing scalability, are still not as scalable as IP multicast. Others, while fully scalable, require changes to routers or to other infrastructure, making their use unlikely in the near future. For a more complete discussion of the drawbacks of each protocol see [GEM97]. The data carousel [AFZ95] approach is a simple protocol that avoids any feedback from the receivers. The sender repeatedly loops through the source data. The receiver is able to reconstruct missing components of a file by waiting for it to be transmitted again in the next loop without having to request retransmissions. However, it may be necessary to wait for the full loop to repeat to recover a lost packet. The forward error correction (FEC) [BLA94] approach requires no feedback and reduces the retransmission wait time by including some error correction packets in the data stream. Most of the FEC literature deals with error correction, that is, the ability to detect and repair both erasures (losses) and bit-level corruption. However, in the case of IP multicast, lower network layers will detect corrupted packets and discard them. Therefore, an IP multicast application need not be concerned with corruption; it can focus on erasure correction only. The erasure correction used here is called an (n,k) code. k source blocks are encoded into n>k blocks, such that any k of the encoded blocks can be used to reconstruct the original k blocks ( REF _Ref440356186 Figure 1). (Note: in this paper, we will refer to blocks of data from a file; a packet is a block with an attached header, which is sent over the network.) For example, parity can be used to implement (k+1, k) encoding. Many (n,k) codes based on Reed-Solomon codes are efficient enough to be used by personal computers [RIZ97c, NON97]. For example, Rizzos public domain codec can code and decode data at 90 mbps on a 133 MHz Pentium processor [RIZ97b].  EMBED Word.Picture.8  Figure  SEQ Figure \* ARABIC 1. An example of (n,k) encoding and decoding: k original packets are reconstructed from any k of the n encoded packets. In practice, k and n must be limited for Reed-Solomon based codes as large values make encoding and decoding expensive. (k,n) = (64, 255) are typical limits [RIZ97a]. Tornado codes [BYE98] based on bipartite graphs, are an attractive alternative to Reed-Solomon codes. A Tornado code may require slightly more than k blocks to reconstruct the original k blocks. However, the value of k may be on the order of tens of thousands. This paper uses a Reed-Solomon based (n,k) code, but discusses the impact of switching to Tornado codes, or codes like them, where appropriate. As most transmissions (e.g., files) are longer than k blocks, they must be divided into groups of k blocks each, with erasure correction (EC) performed on a group-by-group basis. Each block in the session is assigned to an EC group of k blocks, which is then encoded into n blocks. Each block is identified by an index specifying which of the n encoded blocks it is, as well as a group identifier associating it with an EC group. A nice property of FEC encoding is that encoded blocks are approximately the same size as original blocks. The only overhead is introduced in the block header where the index, group and other transmission details is carried a few bytes. Systematic encoding schemes simplify matters by making the first k of the n encoded blocks be the original blocks. If no blocks are lost, a receiver does not incur any processing overhead decoding the k blocks of a systematic code. Fcast uses a systematic coding scheme. The order in which blocks are transmitted is important. Suppose, for example that all n blocks were sent from one group before sending any from the next. Receivers with few losses would be forced to receive more FEC than they actually needed -- indeed the scheme would be more like a data carousel -- a typical receiver would have to wait for 1/2 the file to be retransmitted to correct the typical single error. To avoid this, the sender sends all blocks with index i before sending blocks with index i+1. As shown in Figure 2, when block n of the last group of the last file is sent, the transmission cycles.  EMBED Word.Picture.8  Figure  SEQ Figure \* ARABIC 2. Transmission order: Any k blocks must be received from each group to reconstruct the transmitted file. To minimize receive time, one block is sent from each group in turn. While sending a given index value, the group order may be randomly varied to avoid correlation of periodic losses. G, the number of groups is the ceiling of the file size divided by k. To complete the reception, k distinct blocks (i.e., with different index values) must be received from each group. For some groups, more than k blocks may be received, in which case the redundant blocks are discarded. These redundant blocks are a source of inefficiency, as they increase the overall reception time. Supposing that only one additional block is needed to complete the reception. It is possible that a receiver may have to wait an entire cycle of G blocks (receiving blocks from all other groups) before obtaining a block from the desired group. Thus, the inefficiency is related to the number of groups G, which is the file size divided by k. Fcast efficiency is discussed further in section  REF _Ref437389861 \r \h 5. One danger with this transmission order is that a pattern of periodic network losses may become synchronized with the transmission so as to always impact blocks from certain groups; in the worst case, a single group is always impacted. The impact of periodic losses may be eliminated through a few straightforward modifications to the block transmission. One modification is to adjust the data rate timer [FLO93]. The timer interval for sending blocks is randomly set to an amount from the uniform distribution on the interval [0.5T, 1.5T], where T is the desired timer interval. However, this does not solve periodic burst losses. A more general solution is to randomly permute the order of groups sent for each index [VIC98]. Thus, periodic losses are randomly spread among groups. Sending Models: TIDDO and Satellite There are two primary models for file multicast. In the first model, illustrated in  REF _Ref422796808 \h  \* MERGEFORMAT Figure 3, the sender has a single set of files, which are continuously sent for some period. Receivers subscribe to the multicast, obtain the necessary blocks to construct the files, and then drop out of the multicast. We refer to this as the tune in, download, and drop out model (with respects to Timothy Leary) or TIDDO. TIDDO is applicable to the midnight madness scenario, where a file set is known to be in high demand by many concurrent receivers. The second model has the receiver continuously tuned in to a multicast address. Over time, the sender pushes different file sets that it believes may be of interest to the receiver. The receiver discards any unwanted files. We refer to this as the Satellite model, as it is most applicable to satellite transmission, where the receiver continuously receives a satellite broadcast.  EMBED Word.Picture.8  Figure  SEQ Figure \* ARABIC 3. TIDDO (Tune In, Download, and Drop Out) model. Sender continuously sends the same files. Receivers tune in when they like, get the bits they need, and then drop out of the multicast.  EMBED Word.Picture.8  Figure  SEQ Figure \* ARABIC 4. Satellite model. Receivers are continuously tuned in. The sender sends when it has material that may interest the receivers. The satellite model should be used with some caution. Using this model, it would be easy to write applications that send multiple files sequentially in a number of transmissions. If files are sent sequentially, then a receiver may not obtain enough blocks for a given file before the transmission ends, and may receive extra blocks for other files. In contrast, files sent in parallel (i.e., combined into a single batch file) do not suffer from this inefficiency. With Fcast, files may be sent in parallel by combining them into a single file, e.g., a tar, zip or cab file. Alternately, each file may be sent using Fcast on separate multicast addresses. Furthermore, if the Satellite model is widely used on conventional networks, it may not be possible for users to subscribe to all the channels of interest to them because the aggregate bandwidth may be too high. To avoid this problem, publishers will need to make their sending timetable known, so that receivers can tune in only for the files they need - but then we are back to the TIDDO model. Therefore, satellite mode is most applicable to actual satellite receivers. Fcast Implementation This section outlines Fcast's implementation, describing the architecture, the transfer of session and meta-file information, the Application Programming Interface (API), and the block header format. Sections  REF _Ref437389861 \r \h 5 and  REF _Ref437409379 \r \h 6, describe novel solutions to tune the k parameter and to enhance disk performance. General Architecture Fcast assumes that a single sender initiates the transfer of a single file to a multicast address. The sender loops continuously either ad infinitum, or until a certain amount of FEC redundancy has been achieved. Receivers tune in to the multicast address and cache receive packets in a temporary file name until they receive enough blocks to recreate the file. Under the TIDDO model, receivers then drop out of the multicast. Under the satellite model, they continue to receive blocks in anticipation of the next file to be sent. In either case, the file is then decoded, and the file name and attributes set. See Section  REF _Ref437409379 \r 6 for more details on the reception algorithm. The Fcast sender and receiver are implemented as ActiveX [CHA96] controls. These controls may be embedded in web pages and controlled by scripting languages such as VB script [HIL96], or embedded into applications (see  REF _Ref437408653 \h  \* MERGEFORMAT Figure 5). Each has an Init() call to initialize the Fcast with the multicast address and other transmission settings. A call to Start() begins the sending/receiving in another thread and returns control immediately. Progress of the transmission can be monitored by a call to GetStats(), and via connection points (ActiveX callback routines). For more details, see Appendix A. An Fcast receiver spawns two threads. One thread simply receives packets and puts them in a queue; it ensures that packet losses in the network can be distinguished from packets dropped at the receiver when transmission proceeds faster than disk writes. The second thread takes packets from the queue, and writes them to a temporary file name disk. When sufficient packets have been received to construct the file, the packets are decoded, and the file name and attributes are set. Figure  SEQ Figure \* ARABIC 5. The Fcast receiver embedded in a web page (left) and in an application (right). Session and Meta-file information The Fcast sender and receivers need to agree on certain session attributes to communicate. This session description includes the multicast address, and port number. We assume that there exists an outside mechanism to share session descriptions between the sender and receiver [HAN98]. The session description might be carried in a session announcement protocol such as SAP [HAN96], located on a Web page with scheduling information, or conveyed via E-mail or other out-of-band methods. In addition to the actual file data, the receiver needs certain metadata: the file name, its creation date, etc. Metadata could be sent out of band. For example, it could be part of the session description or sent as a separate file in the transfer with a well-known file ID. For simplicity Fcast sends file metadata in-band. The metadata is appended to the end of the file as a trailer and sent as part of the transmission. The receiver places the metadata into a temporary file name. Once the data is decoded, the metadata is extracted (the real file name, length and other attributes). The metadata is appended rather than prepended to the file so that the correct file length may be achieved via simple truncation rather than requiring re-writing. A checksum is included in the trailer to validate that the file was encoded and decoded correctly. Packet Headers The packet header structure is shown in  REF _Ref436467019 \h Figure 6. Each file sent is given a unique ID. Thus, each block in the transmission is identified by a unique tuple. Packets with indices 0 to k-1 are original file blocks, while the packets with indices k to n-1 are encoded blocks. The sequence number, dwSeqno, monotonically increases with each packet sent, allowing the receiver to track packet loss. The file length is included in the header so that the receiver can allocate memory structures for tracking reception once it has received its 1st packet and read the header. Similarly, the k value is included so that the group size is known (the number of groups is calculated by dividing the file length by k). Instead of including the file length and k in every packet, we might have sent these values out of band. However, by including them in-band, and having meta-information embedded in the trailer, we enable a receiver to tune in to a well-known multicast address and port and begin receiving with no additional knowledge. Including the sequence number, k, and the file size only increases the header size by 5; with a payload of 1KB the difference is negligible. Note that in a satellite transmission, the file length will change with each file, and k may also. Our implementation makes the assumption that all packets are the fixed size. This value is not included in the packet header the receiver simply observes the size of the first packet it receives. The n value of the (n,k) codec also need not be transmitted, as it is not needed by the receiver. typedef struct { DWORD dwSeqno; //sequence number for detecting packet loss DWORD dwFileId; //file identifier DWORD dwFileLen; //length of file DWORD dwGroupId; //FEC group identifier BYTE bIndex; //index into FEC group BYTE bK; //k of (n,k) encoding } tPacketHeader; Figure  SEQ Figure \* ARABIC 6. Packet header structure. Selecting a value for k In general, the larger the value of k, the more efficient the file transfer. However, implementation details prevent construction of a codec with arbitrarily large k. Let the maximum possible value of k be kmax. This section explains how to select an optimal k, given that k can be at most kmax. First, it examines the impact of k on transfer efficiency. Then, it considers selecting k for small file transfers. Suppose that packet loss is random, and that the probability a given packet is lost is r. Let pg(k+x) be the probability that, for a given group g, no more than x packets are lost out of k+x packets, i.e., the receiver has obtained at least kdistinct packets and is able to decode the group. This is calculated by the cumulative binomial distribution:  EMBED Equation.3  If k+x packets have been sent for each group, and there are G groups, then the probability that at least k packets have been received for all the groups is P(k+x) =( pg(k+x))G Therefore, the probability of completing reception depends on the loss rate, and inversely on the number of groups. Increasing k reduces the number of groups, so a larger k will tend to produce a more efficient transmission.  REF _Ref437058009 \h Figure 7 shows listening time versus the probability of complete reception for a number of values of k. The ideal transmission has one group and has k set to the number of blocks in the file. In this case, the receiver has completed reception once it has received exactly as many blocks as are in the file. Note that this is the best case for a unicast transmission. With k limited to at most kmax, the number of groups, G, must grow with the file size.  REF _Ref437058436 \h  \* MERGEFORMAT Figure 9 shows the expected transmission time for file sizes ranging from 1 MB to 1 GB. It illustrates how the efficiency decreases for larger files. The average overhead goes from 20% to about 30% for a loss rate of 10%.  Figure  SEQ Figure \* ARABIC 7. Expected time required (as percent of time to send the file once) to complete reception with random loss of 10%. File size 1 MB, block size 1 KB, various values of k plotted. Ideal is k = number of blocks in the file (1024).  Figure  SEQ Figure \* ARABIC 8. Expected time required (as percent of time to send the file once) to complete reception with random loss of 40%. File size 1 MB, block size 1KB, various k plotted.  Figure  SEQ Figure \* ARABIC 9. Expected time required (as percent of time to send the file once) to complete reception with random loss of 10%. Block size 1KB, k=32, various file sizes plotted.  Figure  SEQ Figure \* ARABIC 10. Expected time required to complete reception with a random loss of 40%. Block size 1KB, k=32, various file sizes plotted. From  REF _Ref437058009 \h  \* MERGEFORMAT Figure 7 and  REF _Ref437058436 \h  \* MERGEFORMAT Figure 9 we see that with a 10% loss rate, using k=32 gives reasonable results. Higher loss rates exacerbate the impact of the k value.  REF _Ref437846537 \h  \* MERGEFORMAT Figure 8 and  REF _Ref437846540 \h  \* MERGEFORMAT Figure 10 repeat  REF _Ref437058009 \h  \* MERGEFORMAT Figure 7 and  REF _Ref437058436 \h  \* MERGEFORMAT Figure 9, but with the loss increased to 40%. However, the results are still acceptable. While we want a large k value for transmission efficiency, our sender currently must read k blocks to generate each encoded block, so this creates an incentive to keep k low (see section  REF _Ref437409379 \r \h  \* MERGEFORMAT 6 for more details). We use k=32 as a default value that allows reasonable sender speeds combined with efficient transmission. We have shown how larger files are transmitted less efficiently. However, at the other end of the spectrum, small transfers also require a careful consideration of k value. For instance, transmitting a 17 block file with k = 32 would require 15 padding blocks to fill out the single group Recall, however, that larger k values only improve efficiency by reducing the number of groups. Therefore, using k=17, avoids the overhead of padded blocks, and has the same efficiency as k=32, since there is still be only one group. Therefore, any transmission of S ( kmax should use k=S. Transmissions of slightly larger values are also problematic. Assume for the moment that k must be fixed over all groups in a file. Consider a transfer of kmax + 1 blocks. Using k= kmax would give one full group of k blocks, and a second group containing only one data block with k-1 empty padding blocks. The overhead of the transfer would be close to 50% with k values that are larger than 10. For example, if kmax =8 and 9 blocks are to be transmitted, then 7 padding blocks would be required (see  REF _Ref437058894 \h  \* MERGEFORMAT Figure 11). Again, larger k values are not necessarily better. Rather than having 2 groups of 8 each, with 7 padding blocks, there should be 2 groups of 5 blocks (i.e., k=5), with only one padding block. This is just as efficient in terms of erasure correction (it still uses only 2 groups) but greatly reduces the number of padding blocks.  EMBED Word.Picture.8  Figure  SEQ Figure \* ARABIC 11. Avoiding padding overhead by selecting smaller k. In general, when transmitting S blocks, with kmax 0 ? 1 : 0); if (nBlocks <= nMaxK) return nBlocks; if (nGroups >= nMaxK) return nMaxK; return nBlocks/nGroups + (nBlocks%nGroups > 0 ? 1 : 0); } Figure  SEQ Figure \* ARABIC 12. Selection of optimal k value. Let the wasted transmission due to padding be w. Naively using k= kmax can yield w as high as kmax -1, regardless of the transmission size. Minimizing k, as above, means that w will be at most d. As a fraction of the file length, this is:  EMBED Equation.3  Therefore, the fraction of waste due to padding will always be less than 1/ kmax. For S ( kmax, the overhead is zero. For kmax < S < kmax2, the overhead is limited to 1/ kmax. For S > kmax2 the overhead is at most 1/ kmax, and tends to zero as the transmission size grows. With kmax = 32, file sizes from 32 to 1024 (k to k2) have an overhead of at most 3%, with an average of 1.32% and a median of 1.25%.  REF _Ref440268038 \* MERGEFORMAT Figure 13 shows the padding overhead for files from size 0 to 2500 blocks, with kmax=32. So far, we have assumed k must be the same for all groups in the file. However, as we carry k in each packet, we have the option to vary k for each group. Suppose that we have discovered the optimal k=k0, as above and that S = (d+1)k0 p, where p>k, keeping FEC blocks in memory or on disk may consume much more space than the original file. Furthermore, in some cases the time penalty to pre-compute and write this file may not be acceptable. Fcast does not support this precomputation feature, but may support it as an option in a future release. The Fcast receiver has a more complicated task than the sender. Blocks may not arrive in the order sent, portions of the data stream may be missing, and redundant blocks must be ignored. Because the receiver is designed to reconstruct the file(s) regardless of the senders block transmission order, the receiver does not care to what extent the block receipt is out of order, or if there are gaps in the senders data stream. The receiver keeps track of how many blocks have been received for each group and what the block index values are. As each block is received, the receiver tests: Does the block belong to the Fcast session? Is it a new block (not a duplicate of one already received)? Is the block for a group that is still incomplete? (a group is complete when k distinct blocks are received) If a block fails any of these tests, it is ignored. Otherwise, it must be stored. In designing Fcast we considered five possible schemes to deal with received packets: In-Memory, Receive-Order, Group-Area, Crowd-Bucket, and Bucket-per-Crowd. The In-Memory scheme supposes that the receiver has enough RAM to hold the entire file (plus metadata). Blocks are received, sorted and decoded all in main memory. Finally, it is written to disk. Naturally, this approach cannot scale to large files. Receive-Order simply writes all blocks to disk in the order they are received. When reception is complete (i.e., k blocks have been received for each group) the file is sorted into groups prior to decoding. This scheme allows fast reception (sequential writing to disk is fast) but suffers delays in the sorting and decode phases. Such sorting delays can be significant for large transfers. Note also that in-place sorting typically requires disk space of twice the file size. All the other schemes presented here require only the disk space of the transmitted file (plus the metadata trailer). The Group-Area scheme writes blocks to the area of the file corresponding to their group (i.e., for group g, the k blocks beginning at block kg). Blocks are received into one of two single-block buckets in RAM. While one bucket is receiving, the other is written to disk. The block is stored in the next empty block position within the group, which may not be its final location within the file (see  REF _Ref437753060 \h Figure 14). Once reception is complete, each group is read into memory, decoded, and then written back in-place. This scheme avoids sorting delays in the decode phase, but must perform a random disk seek to write each block (in a perfect reception it will be seeking from one group to the next to write each block). The round-robin transmission order challenges file caching mechanisms. In fact, disk caching may slow down writing. For example, if a disk cache uses 4KB pages, then a 1 KB write operation may involve a 4KB read (to get the page) followed by a 4KB write. To prevent such problems, blocks are written in unbuffered mode during reception. However, even in unbuffered mode, 1 KB writes are so small as to allow disk latencies to dominate total writing time, making writing inefficient.  EMBED Word.Picture.8  Figure  SEQ Figure \* ARABIC 14. Group-Area reception method. The Crowd-Bucket scheme assigns multiple groups of blocks to crowds ( REF _Ref437753034 \h Figure 15). Blocks are written as in the Group-Area scheme, but rather than writing to the next available position in the group, they are written to the next available position in the crowd. In order to write several blocks as a single sequential write, blocks are buffered in several buckets, each of size b, before writing. The crowd size is set to be b groups. As long as a bucket is not full, and the incoming block is from the same crowd, no writes are performed. When the bucket is full, or the crowd has changed, then the bucket are written out to the next available free space in the appropriate crowd position in the file. When the Crowd-Bucket scheme has completed reception, each crowd is then read into memory and sorted into its constituent groups. The groups are decoded and then written back to the file. This requires no more disk I/O than is minimally required by decoding (one read/write pass). As sorting time should be small compared to decoding time, performance will be good. The cost is in memory: kb blocks of memory are required to read the crowd into memory to perform the sort. Note that Group-Area is a special case of Crowd-Bucket, with b=1. If groups are always sent in order starting with the first group, then Crowd-Bucket only requires two buckets while receiving: one to receive into while the other is written. However, as mentioned previously, group send order should be randomized in order to prevent periodic loss leading to correlated group loss. The sender could randomly permute crowds rather than groups, but as crowds are a receiver concept and would have their size adjusted by receiver disk speed and memory availability, it is not suitable to have the sender select a crowd size. A better choice would be to have the sender randomly select the first group to send, and then proceed in order, modulo the number of groups. That is, it could randomly select x in the interval [1,G], and send groups x through G, followed by groups 1 through x-1. The position of a group in a round is random, so correlated loss of the same group due to periodic losses is prevented. If the sender only randomizes the selection of the first group in a round, then the Crowd-bucket scheme can operate with 3 buckets. If the first block sent in a round is from the first group of a crowd, then only two of the buckets need be used, and writing can operate as described above (receive into one while the other writes). If the first block is not from the first group of its crowd, then the crowd will be split up so some of its blocks are sent at the start of the round, and some at the end. In this case, one bucket is dedicated to receiving blocks from that crowd. The third bucket is only written when the round is complete. All other crowds are received and written as described above using the other two buckets. (Note: as kb blocks of memory are required to decode and sort, and typically k>2, using 3 buckets instead of 2 has no impact on overall memory requirements in fact, k buckets might as well be used to allow for variations in disk performance). Testing on a Gateway Pentium 300 running Windows NT 4, with a block size of 1 KB, and k=32 yielded the following results: Using the Group-Area method, the fastest that data can be written (and, hence, received) is 1674 kbps. Using Crowd-Buckets, with a crowd size of 4 groups (i.e., b=4), data can be written at 4715 kbps, approximately a 3 times speedup. This requires 3k extra memory, but with k=32, this is only 96KB.  EMBED Word.Picture.8  Figure  SEQ Figure \* ARABIC 15. Crowd-Bucket reception method. The Crowd-Pool scheme also arranges groups into crowds. Like the crowd-buckets scheme, it writes blocks to the next available position in the crowd, and performs a single pass sort and decode when all receiving is complete. However, rather than having 2 buckets, it maintains a pool of block-sized buffers. With the Crowd-Pool method there need not be b groups per crowd more or less are possible. Also, the Crowd-Pool scheme does not constrain the randomization of group order as the Crowd-Bucket scheme does in fact, it does not make any assumptions about the send order. There are two ways to implement crowd-pool. One uses gather writing, i.e. the ability to gather a number of discontiguous blocks of memory into a single contiguous write. The other way, non-gather, does not assume this capability, so discontiguous memory blocks must be copied to a contiguous write buffer before writing. The gather implementation works as follows: Let the number of crowds be c, and the number of groups per crowd be g. Thus, g=S/ck. Let the buffer pool consist of bc + b c + 1 blocks. Whenever a crowd has more than b blocks buffered in the pool, it writes b blocks to disk. The write is performed as a single contiguous write in the next available space in the crowd. Whenever all crowds have less than b blocks buffered, then any crowd may be chosen arbitrarily, and its blocks are written to disk.  REF _Ref437752929 Figure 16 illustrates the gather implementation of Crowd-Pool. We now prove that bc+b-c+1 blocks of memory are sufficient for the gather implementation of Crowd-Pool: Theorem: bc+b-c+1 blocks is sufficient to prevent buffer overflow, provided that the disk can perform writes of b contiguous blocks at least as fast as blocks are received from the network. Proof: Suppose that during the time taken to perform a single write of up to b blocks, no more than b blocks will be received over the network. Now consider a point in time when at least b buffer-blocks are empty. Now consider the following two possibilities: Some crowd has at least b blocks buffered. In this case, b blocks from the crowd are written to disk (as a single write). By the time the write completes, at most b blocks could have been received from the network. Therefore, there is still at least b free buffer-blocks. All crowds have less than b blocks buffered. Then some crowd is chosen to have its blocks written. Suppose it has x blocks. Then the total buffered before the write is at most x+(b-1)(c-1) blocks. By the time the write completes, at most b blocks have been received. Therefore, after the write is done, there are at most (b-1)(c-1) + b blocks buffered. The number of blocks in the buffer pool is bc+b-c+1, so the free space is still at least bc+b-c+1 ((b-1)(c-1) + b) = b. Therefore, if there are ever at least b free buffers, we can perform a write such that when the write completes there will still be at least b free buffers. As all buffers are initially empty, the buffer will never overflow. (  EMBED Word.Picture.8  Figure  SEQ Figure \* ARABIC 16. Crowd-Pool reception method (gather implementation). Now suppose gather writing is not possible. Let a write buffer of size b blocks be used along with a pool of bc-c+1 blocks, for a total which is still bc+b-c+1 blocks of memory. Whenever any crowd has at least b blocks in the pool, b blocks are copied to the write buffer and a write is initiated. Whenever all crowds have less than b blocks buffered in the pool, then a crowd is chosen arbitrarily to have its blocks copied to the write buffer, and the write is initiated. Thus, it is possible to avoid requiring gather writing at the expense of extra memory-to-memory copies (which should not be significant).  REF _Ref454152643 Figure 17 illustrates the non-gather implementation of Crowd-Pool. We now prove the sufficiency of the memory for the non-gather Crowd-Pool algorithm: Theorem: bc+b-c+1 blocks is sufficient to prevent buffer overflow, provided that the disk can perform writes of b contiguous blocks at least as fast as blocks are received from the network. Proof: Suppose that during the time taken to perform a single write of up to b blocks, no more than b blocks will be received over the network. Let the memory be divided into a pool of bc-c+1 blocks and a write buffer of b blocks. Now consider a point in time when at least b buffer-blocks in the pool are empty, and some number of blocks have just been copied to the write buffer to be written. By the time the contents of the write buffer finish writing, at most b blocks will be received. Note that at least b blocks were free, so there will be no overflow from receiving these new blocks. Now consider the following two possibilities: Some crowd has at least b blocks buffered. In this case, b blocks from the crowd are copied to the write buffer, and b blocks are freed in the pool. Therefore, there are still at least b free buffer-blocks. All crowds have less than b blocks buffered. Then some crowd is chosen to have its blocks copied. Suppose it has x blocks. Then the total blocks buffered in the pool before the copy is at most x+(b-1)(c-1) blocks, and after the copy is (b-1)(c-1) = bc-b-c+1. Therefore, the pool has at least b free blocks. Therefore, if there are ever at least b free buffers in the pool, we write the write buffer, and then copy into the write buffer so as to ensure that there will still be at least b free buffers. As all buffers are initially empty, we can ensure the buffer will never overflow. (  EMBED Word.Picture.8  Figure  SEQ Figure \* ARABIC 17. Crowd-Pool reception method (non-gather implementation). The memory required to implement Crowd-Pool is, as we have stated, bc+b-c+1. However, in order to sort and decode a crowd in one pass, there must also be sufficient memory to hold an entire crowd. A crowd consists of S/c blocks. Therefore, the memory required to cache, sort and decode is m( max(S/c, bc+b-c+1). As a function of c, S/c is decreasing, while bc+b-c+1 is increasing. Therefore, the minimum memory required is found at their intersection, which is at (b-1)c2 + (b+1)c S = 0 . This can be solved for c to obtain:  EMBED Equation.3  substituting into m=bc+b-c+1 yields  EMBED Equation.3  So we see that as S gets very large m can be approximated by (S(b-1))1/2, which grows with the square root of the file size. The above uses continuous functions, but, of course, all the variables must have integer values. In practice, g should calculated as  EMBED Equation.3  Now g must be an integer and be at least one. Let gc=max(1,(g() and gf max(1,(g(). Then calculate  EMBED Equation.3  and m=max(gck, bc-c+b+1, S/c). Perform the same calculations using gf in place of gc, and then select gf or gc according to which one requires less memory. MethodMemory required (blocks)Disk space required (blocks)Total Disk I/O requiredExperimental rate (Mbps)In-MemorySSS sequentialNetwork speedReceive-Order12SS random + 4S sequential29.1Group-Areas1SS random (size 1) + 2S sequential1.2Crowd-BucketsKbSS/b random (size b) + 2S sequential2.7Crowd-Pool (Sb) (approx)SS/b random (size b) + 2S sequential2.7Table  SEQ Table \* ARABIC 1. Comparison of receive methods.  REF _Ref437835852 \h  \* MERGEFORMAT Table 1 compares the memory, disk space and I/O requirements of the five methods. It is clear that both Crowd-Bucket and Crowd-Pool achieve low I/O costs, while maintaining low disk space and reasonable memory requirements. To compare their memory requirements, one must look at the parameter values.  REF _Ref437835388 \h  \* MERGEFORMAT Figure 18 illustrates this for k=64 and b set to 16 or 128. Note that when b=16, Crowd-Pool uses more memory for all but the smallest files. With b=128, Crowd-Pool uses less memory for files up to about 0.5 GB. Therefore, low bandwidth applications that need a relatively small b value can use the simpler Crowd-Bucket scheme, while higher bandwidth applications sending relatively small files would save memory by using Crowd-Pool. For modern PCs, b=8 should suffice to handle transfers on the order of several Megabits per second.  Figure  SEQ Figure \* ARABIC 18 - Memory requirements for crowd-buckets and crowd-pool schemes; k=64, block size 1KB. To support Crowd-Bucket, the sender must restrict randomization of send order to crowds, meaning the sender must select a crowd size. However, for Crowd-Pool, the receiver selects the crowd size, and the sender may send in any order. A receiver with memory m could determine the receiving strategy as follows: If m(S then use In-Memory. Otherwise, find the largest b that m can support using Crowd-Pools; call it bp. Let the maximum b that m can support (m/k) using Crowd-Bucket be bb. If bb> bp and bb>1 use Crowd-Buckets. Otherwise, if bp>1 use Crowd-Pools. Otherwise, use Group-Area. If the receive method selected above cannot keep up with the receive rate, switch to Receive-Order. Finally, we note that decoding a group could begin as soon as k packets have been received for the group, in parallel with reception of other packets. However, disk I/O is required to fetch the packets for the decode and then write the results; such I/O may interfere with the writes required for new packets received. In the current version of Fcast, decoding is deferred until all groups have completed. In the future we may add parallel decoding, but only as a lower priority I/O activity to writing newly received packets. In satellite mode, a new file may start being received while the previous one is still decoding. As no special priority is given to writing received data, care should be taken when using satellite transfer mode to target bandwidths such that the receiver can simultaneously decode and receive, or else space out transmissions such that simultaneous decode and receive will never be required. Conclusion and Future Work Fcast file transfer is as scalable as IP multicast. Fcast handles receivers with heterogeneous loss characteristics. It requires no feedback-channel communication, making it applicable to satellite transmissions. This paper described the Fcast design, API, and implementation. It discussed how Fcast optimally selects the k parameter to minimize transmission overhead while maintaining the best loss resilience. It also explained how to efficiently use the disk at the sender, and, more critically, at the receiver. We are considering several enhancements to Fcast. When data is compressed, it would improve performance to perform decompression in combination with decoding, so that there is only one step of read/decode/decompress/write, instead of read/decode/write + read/decompress/write. Another important enhancement is to multicast in a layered fashion, i.e., to split the transmission up among a number of different multicast addresses. Receivers only subscribe to as many layers as they can handle, thereby addressing the congestion control issue [KAS97, MCC97, VIC97]. To our knowledge, Fcast is the first commercial implementation of FEC-based multicast file transfer [SCH97]. Currently, it is being used on the Microsoft Campus to distribute nightly updates of Windows 2000 a 336 MB download. It has also been incorporated into a Multicast PowerPoint Add-in, to distribute master slide information in one-to-many telepresentations [GEM98]. By the time this paper appears, Fcast should be freely available on the World Wide Web to allow distributors of software and other popular content to avoid the catastrophes associated with the midnight madness download scenario. Acknowledgements The authors wish to acknowledge the helpful comments of Dave Thaler and Shreedhar Madhavapeddi. References [AFZ95] Acharya, S., Franklin, M., and Zdonik, S., Dissemination-Based Data Delivery Using Broadcast Disks, IEEE Personal Communications, pp.50-60, Dec 1995. [BIR91] Birman, K., Schiper, A., and Stephenson, P., Lightweight Causal and Atomic Group Multicast, ACM Transactions on Computer Systems, 9(3): 272-314. Aug 1991. [BLA94] Blahut, R.E., Theory and Practice of Error Control Codes, Addison Wesley, MA 1984. [BYE98] Byers, J.W., Luby, M., Mitzenmacher, M., and Rege, A., A Digital Fountain Approach to Reliable Distribution of Bulk Data, Proceedings ACM SIGCOMM '98, Vancouver, Canada, Sept 1998. [CHA96] Chappell, D.. Understanding ActiveX and OLE. Redmond, WA. Microsoft Press, 1996.  HYPERLINK "http://approjects.co.za/?big=com/activex.asp" http://approjects.co.za/?big=com/activex.asp [CHA84] Chang, J.M., and Maxemchuck, N.F., Reliable Broadcast Protocols, ACM Transactions on Computing Systems, 2(3):251-273. Aug 1984. [CRO88] Crowcroft, J., and Paliwoda, K., A Multicast Transport Protocol, Proceedings of ACM SIGCOMM 88, pp.247 - 256, 1988. [DEE88] Deering, S., Host Extensions for IP Multicasting, RFC 1058, Stanford University, Stanford, CA, 1988. [FLO95] Floyd, S., Jacobson, V., Liu, C., McCanne, S., and Zhang, L., A Reliable Multicast Framework for Light-weight Sessions and Application Level Framing, Proceedings ACM SIGCOMM 95, Cambridge, MA, Aug 1995. [FLO93] Floyd, S., and Jacobson, V., The Synchronization of Periodic Routing Messages, ACM SIGCOMM Computer Communication Review, 23(4):33-44, Oct 1993. [GEM98] Gemmell, J., Schooler, and E., Kermode, R., A Scalable Multicast Architecture for One-to-Many Telepresentations, Proceedings IEEE International Conference on Multimedia Computing Systems, ICMCS'98, Austin, TX, June 1998. [GEM97] Gemmell, J., Scalable Reliable Multicast Using Erasure-Correcting Re-sends, Technical Report MSR-TR-97-20, Microsoft Research, Redmond, WA, June 1997. [HAN98] Handley, M., and Jacobson, V., SDP: Session Description Protocol, RFC 2327, April 1998. [HAN96] Handley, M., SAP: Session Announcement Protocol, Internet Draft, IETF MMUSIC Working Group, Nov 1996. [HIL96] Hiller, S., Inside Microsoft Visual Basic, Scripting Edition. Redmond, WA. Microsoft Press, 1996.  HYPERLINK "http://msdn.microsoft.com/scripting/" http://msdn.microsoft.com/scripting/ [HOL95] Holbrook, H.W., Singhal, S.K., and Cheriton, D.R., Log-based Receiver-Reliable Multicast for Distributed Interactive Simulation, Proceedings ACM SIGCOMM '95, Cambridge, MA, Aug 1995. [KAS97] Kasera, S.K., Kurose, J., and Towsley, D., Scalable Reliable Multicast Using Multiple Multicast Groups, Proceedings ACM SIGMETRICS 97, Seattle, WA, 1997. [KER98] Kermode, R., Scoped Hybrid Automatic Repeat ReQuest with Forward Error Correction (SHARQFEC) , Proceedings ACM SIGCOMM '98, Vancouver, Canada, Sept 1998. [MCC97] McCanne, S., Vetterli, M., and Jacobson, V., Low-complexity Video Coding for Receiver-driven Layered Multicast, IEEE Journal on Selected Areas in Communications, Vol.16, No.6, pp.983-1001, Aug 1997. [NON97] Nonnenmacher, J., Biersack, E., and Towsley, D., Parity-Based Loss Recovery for Reliable Multicast Transmission, Proceedings ACM SIGCOMM '97, Cannes, France, Sept 1997. [PAU97] Paul, S., Sabnani, K.K., Lin, J. C.-H., and Bhattacharya, S., Reliable Multicast Transport Protocol (RMTP), , IEEE Journal on Selected Areas in Communications. Special Issue for Multipoint Communications, Vol. 15, No. 3, pp. 407 421, Apr 1997. [POS81] Postel, J., ed,. Transmission Control Protocol, RFC 793, Sept 1981. [RAM87] Ramakrishnan, S. and Jain, B. N., A Negative Acknowledgement With Periodic Polling Protocol for Multicast over LANs, Proceedings IEEE Infocom 87, pp. 502-511, Mar/Apr 1987. [RIZ97a] Rizzo, L, and Vicisano, L., Reliable Multicast Data Distribution protocol based on software FEC techniques, Proceedings of the Fourth IEEES Workshop on the Architecture and Implementation of High Performance Communication Systems, HPCS97, Chalkidiki, Greece, June 1997. [RIZ97b] Rizzo, L., and Vicisano, L., Effective Erasure Codes for Reliable Computer Communication Protocols, ACM SIGCOMM Computer Communication Review, Vol.27, No.2, pp.24-36, Apr 1997. [RIZ97c] Rizzo, L., On the Feasibility of Software FEC, DEIT Tech Report,  HYPERLINK http://www.iet.unipi.it/~luigi/softfec.ps http://www.iet.unipi.it/~luigi/softfec.ps, Jan 1997. [SCH97a] Schooler, E., and Gemmell, J., Using Multicast FEC to Solve the Midnight Madness Problem, Technical Report MSR-TR-97-25, Microsoft Research, Redmond, WA, Sept 1997. [TAL95] Talpade, R., and Ammar, M.H., Single Connection Emulation: An Architecture for Providing a Reliable Multicast Transport Service, Proceedings 15th IEEE International Conference on Distributed Computing Systems, Vancouver, Canada, June 1995. [VIC98] Vicisano, L., Notes On a Cumulative Layered Organization of Data Packets Across Multiple Streams with Different Rates, University College London Computer Science Research Note RN/98/25, Work in Progress (May 1998). [VIC97] Vicisano, L., and Crowcroft, J., One to Many Reliable Bulk-Data Transfer in the Mbone, Proceedings of the Third International Workshop on High Performance Protocol Architectures, HIPPARCH 97, Uppsala, Sweden, June 1997. [WHE95] Whetten, B., Montgomery, T., and Kaplan, S., A High Performance Totally Ordered Multicast Protocol, Proceedings International Workshop on Theory and Practice in Distributed Systems, Springer-Verlag, pp.33-57, Sept 1994. [YAV95] Yavatkar, R, Griffioen, J, and Sudan, M, A Reliable Dissemination Protocol for Interactive Collaborative Applications, Proceedings ACM Multimedia 95, Pages 333-343, Nov 1995. Appendix A: Details of the API Both the sender and receiver are implemented as invisible (i.e. without any graphical interface) ActiveX controls. An ActiveX control can be called from any programming language.  REF _Ref437408653 \h Figure 5 shows the receiver control being called from VBScript in a web page on the left, and being called from a Visual Basic application on the right. In the future, we may also release ActiveX controls that do include a visible interface (these controls would wrap the invisible controls). The sender has an Init() call, which initializes the Fcast for a particular multicast address, destination port, TTL, and data rate. The data rate limit prevents the sender from multicasting faster than can be handled by the intended recipients or network links. For example, if receivers are connecting over a dial-up line, the data rate is set below the modem speed limit. The k value is not specified in the interface. Instead, kmax is set to 32 and an optimal value for k is determined as described in Section  REF _Ref437389861 \r \h 5. Sender functions: HRESULT Init(BSTR Addr, short nPort, short nTTL, long nBytesPerSec); HRESULT Start(BSTR FileName); HRESULT Start(BSTR FileName, float Redundancy); HRESULT Stop(); HRESULT GetStats(VARIANT* pvSentCount, VARIANT* pvSentRounds, VARIANT* pvCurrentIndex, VARIANT *pvComplete, VARIANT* pvErrorCode); Connection points: void OnComplete(); Figure  SEQ Figure \* ARABIC 19. Sender control API. Once the sender is initialized, Start() can be called, giving the name of a file to send. The file is sent in a separate thread, and control is returned immediately to the caller. Sending continues indefinitely, until it is terminated by calling Stop(). A second form of Start() includes the amount of redundancy to include after which the send is automatically halted. For example, if the redundancy is set at 50%, 1.5 times the file size is sent, at which point the transmission halts. Stop() may be called to halt the transmission even before the target redundancy has been achieved. In a satellite transmission, Start() and Stop() are called for each file after calling Init() (see  REF _Ref440444617 \h Figure 20). To monitor progress of the transmission, GetStats() may be called to obtain the number of packets sent and to check for any errors that may have occurred. Additionally, one connection point (a call-back function that the caller implements) is defined: OnComplete(). It is called when sending completes after the desired redundancy is achieved. Sender.Init(239.99.99.99, 1711, 16, 1000); Sender.Start(myfile.txt); Sender.Stop(); Sender.Start(otherfile.htm); Sender.Stop(); Figure  SEQ Figure \* ARABIC 20. Starting and stopping the sender. The receiver API is similar to the senders. Init() is called to set up the session with the multicast address, port, and the directory in which files should be saved. Once Start() is called, the receiver subscribes to the multicast address and continues receiving until it either has at least k blocks from each group or is instructed to stop. When running in TIDDO mode, the receiver will drop out of the session after receiving a file. In Satellite mode, it will remain connected. To find out how the reception is proceeding, GetStats() may be called to retrieve session statistics. Five connection points (call-back routines) are defined. OnFileStart() is called when the 1st packet of a file is received. It indicates the ID number assigned to the file at the sender and the length of the file. OnFileComplete() is called when a file has been completely received and decoded. It indicates the ID number of the file, the file name, and the length of the file. OnComplete() is called when, in TIDDO mode, the receiver is shutting down after completing a file. OnError() is called in the event of a non-fatal error, indicating the error number. OnFatalError() is called when a fatal error occurs. The crowd size is not currently exposed in the interface, in order to keep it simple. Instead it is set to 4, which allows reasonable write performace without requiring much additional memory. Receiver functions: HRESULT Init(BSTR Addr, short nPort, BSTR SaveDir); HRESULT Start(); HRESULT Stop(); HRESULT GetStats(VARIANT* pvRecvdCount, VARIANT* pvLostPackets, VARIANT* pvRedundantCount, VARIANT* pvOutOfOrderCount, VARIANT* pvStrayCount,VARIANT* pvDropped, VARIANT* pvDecoded, VARIANT* pvFilesDone,VARIANT* pvFilesRcvd, VARIANT* pvFilesStarted, VARIANT* pvPayloadLen); Connection points: void OnFileStart(long dwID, long dwLen); void OnFileComplete(long dwID, BSTR FileName, long dwLen); void OnComplete(); void OnError(long nError); void OnFatalError(long nError); Figure  SEQ Figure \* ARABIC 21. Receiver control API. Appendix B: Disk performance experimental results We tested write performance on a number of systems, simulating the writing patterns for Fcast employing the various schemes described in Section  REF _Ref437409379 \r \h 6, with k=32. Testing was done on the following systems: System labelPentium clock speed (MHz)Operating SystemDisk drive typeFile systemA300Windows NT 4.0 WorkstationSCSINTFSB266Windows NT 4.0 WorkstationIDENTFSC333Windows 2000 Beta 3SCSIFATD266Windows 98IDEFAT32Table  SEQ Table \* ARABIC 2 Systems tested for disk performance. Receive-order was simulated by doing sequential unbuffered writes of 8KB. Sequential performance could be even higher with larger writes and/or buffered writes. Receive-order does 1 KB writes. 4-Crowd does 4 KB writes simulating the write pattern of crowd size 4. 8-Crowd does 8 KB writes simulating the write pattern of crowd size 8.  REF _Ref441462613 \h Figure 22 shows the maximum write rate for each of the systems using the different approaches.  REF _Ref441462616 \h Figure 23 shows the same results, with the sequential rate removed to allow the other results to be more readily compared.  Figure  SEQ Figure \* ARABIC 22 Experimental results for disk performance.  Figure  SEQ Figure \* ARABIC 23 Experimental results for disk performance sequential results removed.  Notation: bps = bits per second, Bps = bytes per second.  Naturally, to support higher-speed downloads, a higher speed connection would be required. It is likely that several simultaneous Fcasts would be performed at various speeds (e.g., 12, 24, 50, 100, 200, and 300 kbps). The receiver would select an appropriate transmission speed and tune in to the corresponding Fcast. Layered schemes are also possible (see the Conclusion).  In the case of a batch file (.zip, .tar, .cab,) that contains many individual files in a standard format, Fcast manages only the meta-information of the batch file itself.  It is easy to prove from the derivation of k0 that k0 ( kmax/2. With kmax = 32, k0 ( 16. The difference between k=15 and k=16 will be very slight (at least until the loss rate approaches 100%).  Without pre-computation, k packets must be read to create one encoded packet. Thus, the reading throughput must be k times the sending rate. However, the k blocks are sequential, so the read is efficient. (Performing a sequential k block read is not k times slower than performing k ransom block reads as seek and rotation times, along with other overhead, mask the impact of the length of read.)  Unbuffered I/O requires writes that are multiples of the disk sector size often 512 bytes. We use a fixed block size of 1024 bytes in this first version of Fcast.  Using a Pentium 266 running Windows 98 with IDE hard drive. Crowd methods used a crowd size of 4. Receive order did sequential unbuffered 8 KB writes. See Appendix B for more detailed experimental results.  This assumes an -2pass sort which uses order sqrt(Sb) memory for the sort to generate the runs and them merge them.  Currently, we simultaneously send a number of Fcasts, each targeted to a particular bandwidth. This deals with the problem to a gross approximation, e.g., it allows a dial-up customer to ask for no more than 28.8 kbps. However, it does not coordinate the multiple transfers, so if a receiver were to jump between layers as congestion changes, the ordering of packets may lead to unnecessary redundancy.  The API described is that of the research prototype; the released API may differ. PAGE 7 PAGE 25 PAGE \# "'Page: '#' '"  The old intro made it sound like we were bragging about IE. I rewrote it to make the first 2 paragraphs more engaging. Hope it worked. I also merged the footnotes into the text (I hope). ijab !3478PQ^_ars  / MN}3mwyz¿56 j0JUnH6j0J"<UnHCJCJ jCJUCJj\UjU0JjU jUGklx &Ja567`ar$$$Tl 5 " $ !$$%klx &Ja567`ar  Og y? "z$i%y&ſ   q ( P  Z &  b  &  $  %5  Og y?$$$d%d&d'd$$88$ & F$FLdk    ' , C D E r s { | !!!!""`"f""###)#-#.#######$ $"$#$G$L$i%s%%%%%3&5&&&M(N(p(s((((((6CJOJQJ565 j UjXg@: UVmH6mHnH jUS "z$i%y&((*h-x002c44Z5[5w568::$$$d%d&d'd$$d%d&d'd$$d%d&d'd$ $d%d&d'dy&((*h-x002c44Z5[5w568::;<>EA'C(C*C,C-CCCEH¾yrmgYSM  &          4 &  &  a   &     m  (((())))))0)5)6)?*@******++,,--H-I-b-c-d-e-f-x/|/~////001111 1!1"1 2-233c4d4{4|4}4~44444444Z5[5\5s5 j|Uj+: 5UVmHnHmHjU CJOJQJjU6565mHnH jU j` Uje@: UVmHnHDs5t5u5v5~55555556::f;g;;;;;;;;;;;;;;;>>>>>>?????????(C)C*C+C4C5CKCLCMCNC!D"D5D6DEEFF$G,G3I4IJI j0JU56 jLUmH j+UmHmHj\+U6j*Ujb*Uh5mHnH jU js!Uj+: UVmHC:;<>EA'C(C*C,C-CCCEH IWJ7N`OqOOOO%PMP $d%d&d'd$&d$$l,"$$H IWJ7N`OqOOOO%PMPpPPPPqRSSTTWhXjXoYqY8Z9Z;Z[[["_ga{wqmic_[WS  LN SU#7L&   {     ) O     &   JIKILISITIUIIIIIIIII9J:J>JAJKKLL1L2LfMiM+N,NOOOOPPPPPPPPyQ{QQQQQQQQQQQR RURVRRRRRRRSSSS,S0SbScSSSSSSSSSSS T jeEHUjï8: UVmH6H*6nH6 CJOJQJmHnH jUj"eUPMPpPPPPqRSSTTWhXjXoYqY8Z9Z;Z[[ $d%d&d'd$1$$d%d&d'd$$d%d&d'd$$$ $d%d&d'd TT%T&TRTSTTTTTTUUEUGU{U|UUUUUUUUU,V-V W W W!W$Wb?bbbbbccc\c]csctcccccccc/d3dddddj9 UVmHjU6H* j66hhj+U6mH jUNgaddMeffKggggggg!h"h rp VdddddeeeeJeLekeme{e|eeeeeeeeffffff#f$f%f(f+f,f/f3f4f6f9f;fVfXfYfZf]fgflfxf{fffffffffffffff g ggggBgCgKghhhhhhhCJmHjU jEHUjT : UVmH j6H*6H*6mHnH jU j%UMhhhii j#l[o]oooorsuSxzz{{{{o|i} & F $d%d&d'd$$d%d&d'd$$$ $d%d&d'dh3i5iDiFiGiHiKiViXicidihijiiiiiiiii j j j jYjZj^jcjejfjhjkjljjjjjjjjjjjjjjjjj#k$k'kJkKkOkPkQkkkkkkkklll;lef̞Ξ !# jn5mHnH j5Uj; UVmHnH jU6W? "#?UgzKfƫޫ\]uƾ~xrlf`ZTN Q i   j   $ < ` { L    $  $   _  q.    #$;<=>FG]^`aߟ /8jkqrgnˣ̣ 'DEyz89fg "\^ЦҦ')wڧܧj2; UVmHnH jn56mHnH jB/Uji; UVmHnH jUQ?UgzKfƫޫ\]u$$$$d%d&d'd & F$$$d%d&d'd$%;<>?ũSWêʪߪKQRc}ƫǫګ۫ܫݫ#&ʬˬ,-.2456ƿ j6H* jYEHUj^ ; UVmHnH jVEHUj.; UVmHnH jTEHUj ; UVmHnH6H* j66mHnH jU j@U@678>?@DFGHIJ]^qrstyǭȭɭۭܭݭ~֮׮cdگۯ 12HIj/_Uj^UmHnHCJH* j0JUnHj0J5U5 jx\EHUj; UVmHnH jU j j6H* j6Bu1Nf$$Q$$l t7  r t,"$$ 1Nfخݮޮ$')NRS^nzupkfa\W  h  s t  x              #                   *  7  9  ;  E F  `  x       خݮޮ$~#$$$$$$l t7   t,"$$Q$$l t7  r t,"$')NRS^npگtv%A!< & F%$$d%d&d'd$$$d%d&d'd$$$l t7   t,"$$npگtv%A!<9T*[qbm Ƚ{urlrf`ZTN  Q  U   &      &   %%  %  %  %  ׻P R, -  1  V  XIYZacdz~st"tuv}~()*,]_deҵӵԵٵڵ۵ܵ޵ߵ ߶t+,b0J0J6 j0JU6H* j6mH j_UmH6mHnH jUS9T*[qbm v]`$ $ & F  $bcd`HL2];;<nop!<fM $;KMNF]^jzU j0JU>*6H*jyUj;yU0J60J jUjxxULv]`Xt((t+EkfG.ľ|vpjd^[XT N 4     a  7  : :   e     d    ]  J `Xt((t+EkfG.dh$d%d&d'd & F$ $ $Z\:Mgh~FG]^_fhiiuRSijlm>E!68Ua |H*CJOJQJnHj{UmHnH5j8{U6H*6 CJOJQJ jUmHOXv9:M`l<Ku@IZj{|¾}wqke_YS  = P Q b r     W ;     `4l     & V t  Xv9:M`l<Ku@$dh$d%d&d'd$dh$d%d&d'd $d%d&d'dIZj{|!A{$ & F$$dh$d%d&d'd$0$d%d&d'd$$d%d&d'd|HI_`bc{>?XYZ[\cd-./689$%&-.DEGHwxy!"JKwxy6H* j0JU j~UmH j}UmHj,}UmHj|U6j2|UmHnH jU5J!A{ 6:?@BFZ_cdfjuy$&vwy!JD tulpq       > 6XQ$$l t    rN\-"$Q$$l t    rN\-"      6:?@BFZ_cdfjuy$&vwyܐp $d%d&d'd$$d%d&d'd$$l t    N\-"$y!JD tuklmno#&`#$$x $d%d&d'd)* )+DE !uv|}~q j0J"U0J" jU0JmH0J j0JU j0JU6H*6 j>opq 0/ =!"#$%" 0 0/ =!"#$%DyK yK <mailto:Jgemmell@microsoft.comDyK yK >mailto:Schooler@cs.caltech.eduDyK yK <mailto:Jgemmell@microsoft.comWDd-)N^B  S A? 2k-x#"VuM`!k-x#"Vu%S%/cxY}TU?~X*S . 6":fS(F ٟelǔEmRKLdņ䂝s９F羙ysݏs:04`,zAǽu| ]ޘ޵6ٺ+;l3!):PbO :1p}W8%޹nxT Ov'OIOvWF'+cZrtKӋ3m<=C-#(LcBM[L{3B֝m8a~?&\U w|W;γ0Dv3(/jTMvm*G1c020y&e̻fZYr(㓐!$FLdV\,Efzf(O8oq>xŖBcKp#6a6QafbS{ NU}1NSNe պ{;̶,y`"b; сcOjdHNvm*G3 l?`}m]a?]}5wuI[~lX&52l~KhklS9~AffY0%Cvnd;NbuGw1_*O3ws_w/)5TTs3÷J~ۚޖjBp}~T4ǿe!wjOIyߵ3ۗوR.?W{ ?mwrdo3Ǔr]Ne" yF Mvm*Gq'&c_o׻fIy1,(q%6K4T&eL>X%nZq~RX%(q%!!pq=dئr4qہl&\\tL\׳ZNFO,m\ q gNV#ŕklS9:p>< y*OxY %-X?O0Op~J8) &Iχv8sl,;K|t|h[!ʃC΍3ٺ]r|Lxq[сr@*܊Сdئr+*û͹1wU׾ ЉzfŘjmWQl!'!UiV<۹Și*wU|4cmSnŖBddq {'45 3We9˧T,OM;_PKes^VM>9a[y[HwLM1 " Dd B  S A? 2 8{*6Ѩ2$h  `!` 8{*6Ѩ2$|1("l). xZkl>>JPB mVD`R" gETRnqm'a>,lK(%)/W2 \) RTŭe&jAm{g;3;s|{^y^/Ӹ b]uBӯ!eEYՌ],g% EYeN-Rx:=-/֝\a+*Nݎjah S<1rدͲoAJȆYl"[%hxe[i*Vf7aHVhŋEϬ0br0(0rٯ="+~v}a+==4hk}bVxge"V^YaV F_0w2+EH] #) #ZY  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~XRoot EntrypppPpp`pPp```ppp@p Fv CpW^㼾Datappppppppp`pppp0000ppppppp WordDocumentoEObjectPoolro\㼾W^㼾_977299288 Fo\㼾\㼾1TableCompObjhObjInfo [$@$NormalmH <A@<Default Paragraph Font"*18:<>@LT[_dknqt      !" # $ % & '()*+,"*18:<>@LT[_dknqt  !"#$%&'()*+, r8PQ@RP (  x2  HGf!H))?x2  HGf!H))? x2  HGf!H))? l  0?| f  s *?| f  s *?| l  0? r  6? l  0?| l  0?| l   0 ?| r   6 ? l   0 ?| l   0 ?| r   6 ?   N?   N ?  l  0 ?|  l  0 ?|  l  0 ?|  l  0 ?|   r  6?  r  6?    N? l  0?|  l  0?|  l  0?| r  6? r  6? B S  ? A R 4P=a 4AR ^44Zz4 0 4j4 j 4 j4 j 4j 4 z 4 ` z 4 z 4p z 4` z 4 z 4  * 4  *4 * 4 `*4 0*P4*4*4:4 :4 :4 :4 :4//00667799::<<==??@@GGHHNNOOUUVVWWXXYYZZ[[\\]]^^iijjqqrrxxyy||}}0378@FHKOR^bjpruyz}~@`@GTimes New Roman5Symbol3& Arial"1hB1B1!>0' Jim Gemmell Jim Gemmell  #$&),/367:=>ADEFILNOPQRSUVWXYZ[\]^_`abcdefgi  FMicrosoft Word Picture MSWordDocWord.Picture.89q  FMicrosoft Word Picture MSWordDocWord.Picture.89q  FMicrosoft Word Picture MSWordDocWord.Picture.89qObjectPool o\㼾o\㼾WordDocumentSummaryInformation( DocumentSummaryInformation8    0 !"#$%&'()*+,-./I2345678:;<=>?@BCDEFGHYKLMNOPQRSTUVWr[\]^_`acdefghiklmnopquvwxyz{|}~Y bjbjWW ==]BBBBB NBvvvvv{{{$V{j{{{vvv{vv&4{Bvj p j;;BB Original packets . . . k 2 1 decode . . . . . . take any k encode . . . n k+1 . . . k 2 1 Original packets . . . k 2 1 /0679:<=?@GHNOU^ijqrxy{}5 jUmH./0679:<=?@GHNOUVWXYZ[\]^ijqr$/0679:<=?@GHNOUVWXYZ[\]^ijqrxy{|}Prxy{|}$N N!" #V"$A%Oh+'0\   $ 0<DLTss Jim Gemmellim  Normal.dot Jim Gemmell2m Microsoft Word 8.0@F#@/;;@RS;;՜.+,D՜.+,0 hp  MSFTitl  Title 6> _PID_GUIDAN{9A6EBBB6-EF04-11D0-A5DF-00A02435F763}_977298886$ F\㼾=\㼾1Table)CompObj hObjInfo [$@$NormalmH <A@<Default Paragraph Font $(,26[abc $(,269  [ [[S[ZDij@NUi ( $h| JN !)_-+ 9 Z : S ?|!)7#+ Z ; S ?|A#)$+ Z < S ?|$)/&+ Z = S ?|+)_-+ dZ 'z&t)& > ~'l*V)*N2 ? 3 'z&'& N2 @ 3 d(z&(& N2 A 3 ,)z&t)& N  S ?| l  0  l  0 f  s *  f  s *! f  s * f  s *  f  s *  N  S ?| N  S ?| N  S ?|  N  S ?| N  S ?| N  S ?| f  s * N  S ?| J@ 'z&t)& "N2  3 'z&'&N2   3 d(z&(& N2 ! 3 ,)z&t)& XN 'z&t)& # N2 $ 3 'z&'& N2 % 3 d(z&(& N2 & 3 ,)z&t)& <@ !)_-+ 8Z   S ?|!)7#+Z   S ?|A#)$+Z   S ?|$)/&+Z  S ?|+)_-+dZ 'z&t)& 0 ~'l*V)*N2 1 3 'z&'&N2 2 3 d(z&(&N2 3 3 ,)z&t)&@ `"(,) SdZ `" (%R( , `"(%)N2 - 3 `" ("R(N2 . 3 # (3$R(N2 / 3 v% (%R(T2 6 C ,(,)@ `" (,R( ThL `" (%R( +`" (%R(T2 ( C `" ("R(T2 ) C # (3$R(T2 * C v% (%R(T2 7 C , (,R(JN !)_-+ B Z C S ?|!)7#+Z D S ?|A#)$+Z E S ?|$)/&+Z F S ?|+)_-+dZ 'z&t)& G ~'l*V)*N2 H 3 'z&'&N2 I 3 d(z&(&N2 J 3 ,)z&t)&N `"(,) U dZ `" (%R( V `"(%)N2 W 3 `" ("R( N2 X 3 # (3$R( N2 Y 3 v% (%R( N2 Z 3 ,(,) N `"(,) [ dZ `" (%R( \ `"(%)N2 ] 3 `" ("R( N2 ^ 3 # (3$R( N2 _ 3 v% (%R( N2 ` 3 ,(,) f a s *    f b s *   f c s *   TB d c $D1TB e c $D1TB f c $D1TB g c $D1TB h c $D1TB i c $D1B S  ?  ![i:% thIp p tg] tf5 te] tdg tc\ Ltb-  t t"ta  ttkttB * t[ n P tUT n tT5 tS5J t9= * t8I4 t#g? dt"qI Nt W4 t m4 /tctmtm"/tm*/t4m/t4u7tu*7tu"7tmvt#GHOPUV\@[`@GTimes New Roman5Symbol3& Arial"0hB1B1>02 Jim Gemmell Jim GemmellObjectPool\㼾\㼾WordDocument1SummaryInformation(9DocumentSummaryInformation8AY [bjbjWW ==#7]JJJzzzzz z&I&I&I&}&&&&&&&$n'b)V&JI&I"I&I&I&&}&}&}&}&I&<J}&^lI&}&}&}&}&|J}& Џ#j:;zzI&4}& Index Group 1 1 2 2 3 k G k+1 n "#*+2[5 jUmH#)*+1235679:;=>?ABCEFGIJKMNOS      !"#)*+1235679:;=>?ABCEFGIJKMNOSTUWXYZ ESTUWXYZ[N N!+ " #t"$%Oh+'0\   $ 0<DLTss Jim Gemmellim  Normal.dot Jim Gemmell2m Microsoft Word 8.0@F#@85:;@X:;՜.+,D՜.+,4 hp   Microsoft-  Title 6> _PID_GUIDAN{0E344DCF-7F35-11D2-BAE9-00E0291ABD56}_9759466976 Fp$\㼾p$\㼾1TableJpCompObjhObjInfo [$@$NormalmH DD Heading 1 $$@&59B*CJ$hnH B@B Heading 2 $$@&5B*CJ hnH <A@<Default Paragraph Font>B@> Body Text$59B*CJ$hnH  ')179L\ltz    ')179L\ltz}  8$%@( $@( 8$ xB  HDԔ333?  x  < 333   x  <  333?    T 333333))?     T 333333))?   Z 0   3  x2  <333333333?0 ` x2   <333333333?  x2   <333333333?  x   <  333? d@ xP "    ` 333o333))?x`P B  NDo333? B  NDo333?XX B  NDo333? B  NDo333?88 B  NDo333? B  NDo333? x  < 333? x  < 333? d@  P.! $   `333o333))? P.! B  NDo333? X B  NDo333? X B  NDo333?P. P.X B  NDo333?! !X B  NDo333?& &X B  NDo333?0* 0*X ~  B 333? ~  B 333? x   <  333? B S  ?   t  ) t97t$i *ft"1 V t y t9 7 t ').8ty)t,K0(t90tI/1vt!-tqt 9>@D@p?@GTimes New Roman5Symbol3& Arial5&  Impact"h߼,f߼,fY>0* Jim Gemmell Eve Schooler  FMicrosoft Word Picture MSWordDocWord.Picture.89q FMicrosoft Equation 3.0 DS Equation Equation.39qObjectPoolp$\㼾p$\㼾WordDocumentZSummaryInformation(bDocumentSummaryInformation8jG bjbjَ  {]XXXX444ddddd p d8$$X#4#XXqXV4HVXXXX4| p.ddL leave join High loss receiver leave join Low loss receiver File set + FEC File set + FEC Sender time !678?@EFGB*CJ0hnH 9B*CJ$hnH B*CJ OJQJhnH 59B*CJ hnH  jUmH!"5678?@EFGHZ[jkz{$$$   !"5678?@EFGHZ[jkz{N N!G"#Z$C&%Oh+'0`   ( 4@HPXss Jim Gemmellim  Normal.dot Eve Schoolero2e Microsoft Word 8.0@@2K.@2K.՜.+,D՜.+,, hp|      Title 6> _PID_GUIDAN{7C4D1401-F96E-11D1-9BAE-444553540000}_9759467261; FP| ]㼾P| ]㼾1TabletCompObj hObjInfo  [$@$NormalmH D@D Heading 1 $$@&59B*CJ$hnH B@B Heading 2 $$@&5B*CJ hnH <A@<Default Paragraph Font );CI[y  ! );CI[^ y  yyyx8,-@,( 8$ xB  HDԔ333?x  < 333  r  6  333?    T 333333))?    Z 333333))?  Z 0   3 x2  <333333333?0 ` x2   <333333333?  x2   <333333333?  x   <  333?    Z 333333))? ~B  NDo333?~B  NDo333?~B  NDo333? ~B  NDo333?~B  NDo333?~B  NDo333?x  < 333?  ! Z !333333))?  xB " HDo333? xB # HDo333? xB $ HDo333? xB % HDo333? xB & HDo333? xB ' HDo333?  xB ( HDo333?  xB ) HDo333?  xB * HDo333? xB + HDo333?  xB , HDo333? B S  ? y!#-t9Uti#t y t  D t9t 0t t,t K0t,*t*t*9't9't)q%tq%t(#t#t',t,t+)t)t!t!t&I tI t$tt#tt"AtAt%itit) t) t 1 )1 ttttttt t tq,YtI/1t)1z!%)1_cz@y?y@GTimes New Roman5Symbol3& Arial5&  Impact"h,f,fY>0* Jim Gemmell Eve SchoolerObjectPool"P| ]㼾P| ]㼾WordDocumentSummaryInformation(!#DocumentSummaryInformation8G ybjbjَ  \]HHHHH T HlllllKMMMMMM$rfXq.qKllalKKKpllK,:KKKKKl` Q*.HH4K join receiver File set B + FEC File set A + FEC Sender time File set C + FEC !&'()2_cdevy5B*CJ hnH B*CJ0hnH 9B*CJ$hnH 59B*CJ$hnH B*CJ OJQJhnH 59B*CJ hnH  jUmH  !&'()23DEVW^_devwxy$$ !&'()23DEVW^_devwxN N!G"B#<$/%Oh+'0`   ( 4@HPXss Jim Gemmellim  Normal.dot Eve Schoolero2e Microsoft Word 8.0@@x.@x.՜.+,D՜.+,, hp|      Title 6> _PID_GUIDAN{7C4D1401-F96E-11D1-9BAE-444553540000}_976793539&F ]㼾 "]㼾Ole  CompObj%' fObjInfo(Equation Native _972918016+ F2]㼾5]㼾1Table@5CompObj*-h  p g k+x()=B(x,k+x,r)=k+xy()r y (1"r) (k+x"y)y=0x "  FMicrosoft Word Picture MSWordDocWord.Picture.89qn(7TsIZ;wRvȵokۥ#إ{nᵶQ=PjP~k~oZ˨|Lj6~wKMy d1p9nΑd|Fɜ-% WR.|loˑ =웳$_]F§GI~5 ;kpD`QсɈ?Qdq`7a hYGde2EV,FE #6x嗕M~obeee(+VO3Ϭ0brYeP~Ya,_{6DV1+u6#r.8ˆ@4(0b7aRHL|i`VY.O[^]#mgp~8b}G[i8>' _,o<!̍ AoEj կ6﹀kErTv_$GkEPF`CZmO09AXTcމ4& 9f9;?I`VLBpV&( H #jht`AcƠٯrXr2+V:E) gV1M_V9>%]4ˆ)U_V9دrX״=upod;LBX!gv#y+QO|5E2qU;uЈAb/EGwwpu܈y ^s/?+vm=}DyK _Ref437389861}DyK _Ref422796808 Dd1#B  S A? 2a  Yv-$JzBQ= `!5 Yv-$JzBQ<y @{XZ> x lgfg绦D @"jk5jR@ 6`ME@TB% j%RCRա@(AQPJqgf|Aj43ٙ \T_(3yie._ܰ-j7|ds~~5[!DXKKCEXn<%]_tld&d> _W\˸lւ+~1}/>>;1X^T`6?DeezE]R`6?!0Ĺ:Ei4_ PȰ`؟AԪIiz+q8d R+Vbr9Y]Wѧ8sWoGJ;U9Lt_w*'4XFK袤l~ "tMf4UR`6? `h k " Td8 0U uPIقb1+4)2,fPȴsO~z 5k j(|c:c'P61Ԉ^ aZZ;Z3\Ո&gב#G1^I.m 676Gl|HfvB;y]ߢ_Z)s3[.Pol;~m]qs]K#sAB}MF4 zUX+B^hpc,vkEF3i`W#G=v"yOz qY]ﮏ?.B;sdmڎXp̙&clk+z#uIF/PYgFup.W G9f]/2E9LܯoBaE|c6V{Fd8OAd 0\E+_at1*2<*)0p`8{OC7 20*2  "ggzp ` 22Cj͊ %fSZ@  Ԣ6nSkȻ ǡU0p`8 72N FFXZj+l~ "_a` . }DI0Qς*%fSςN_,dP 6klĖ3z4^, 푣v{d}=2G $'qB\G5 $#e 5fu $1n?ގ;{`LbP9m9 XhSmU҇W"BS^c'fNYzpaeHƟ[{J·X\$I 24`G=^R`6h 0 ?Qdx`xWAd0\ . |Dٶ0V{c) Kz܃kZ_%%[=K/ /*  s_z9ᜯmf €%fW\-xjjo+myc6?TzNM=gK ̦m\A헹J{3WAdC?h,a6ӧF>5taVS%fSIkf;/Z_`跃<}C_N{'!s\Mk;|Zzl6%{fS^^sIv*  8OK }Dm6%_ _dP+CRgZ'5I[yd ?^M=t<Gy2p9GG̈`F0b0L 0IR` O Ob0 İ`Xa9(WuEPDJZV{U@5#1P! F$`hLEC*k4Ġhv[/w3;~` ,f18FᶖTռ{oamu.PzOпc_.z5y/u|gi>9g`-mWީ\Pt3T$yEƠxPo Z5  BG?lT0l J?Y3fMASk=^4fb1s\bxu2Ӻ`kʭ EwB3*U(w*/+f=Ay/i/] N(x) fx)k| G?,P0, CQ G?Tin*q64{C¥넂G?R0 0]0]*sW~qp[j,ElWww^'+If6ɵ^ti=ÝٸƤC2$Q[=F>609gga&pA_8ƦG49,{ep\̲ {p585݂CߢhGh|.#d >buZ}4a SL9Vo\gHJtdFXOS%")(kr0k*z8ƻ)|G9Ȑ8PQzHb,(zpWĕe}Q>e7_&V9S b)S;=Mo]Êu!KٸTz\fq9j1OYƐ?+Cr0 (`t8#䟲;$)/fMF) Kʣ>)w3Ua6 (1m4l#⏲3!QQcy^G$")`Df愊r~'I?&插2(7iLEr,gOy_LR~rf&%e {1ƏO򼸤\G9'! lWQ4>O}rV?ѕr0GW(14NOFsfJʷ# ?Zh}DyK _Ref437389861}DyK _Ref437409379}DyK _Ref437408653 Dd<  C Ab j u폵(,nj u폵(PNG  IHDRt(2gAMAsBIT3 IDATx?.TOylq y A*)TA.;IGQe$M^@UT:.EE&sÙ!9C~?Yrf?*q{B t;|.xŷ/& ;}p1U?cwP~3Iwu_&z[B/N<'D.pM;=VU4 qz[;lu:DsA뾳?ϛ)CP7?d\5J!Ԅq{=9OZZj7\ۨ~kt%gq>ĵ;˵Z@RG:R;;o?=}„(u㩽j9C4a!-N^3Xޞ>n>tܷuiVJju;wIJ^3NyܺѢwk֣۷w37 i¿2ͪC5nJYm`}P;?PKE+O0a?ZBB?Y.W1BJ\q|?gW5UkXNй~ FMt"kVƞC73f>(f9I<{rj%cXPx\Gci3yXq<;Il߁4_=Y4]"bpm]<*2  !Nl,3~?Mb 8[oz#WGof{sssppp;o>Yb+% 3YB⵸g777o~x#a @<Bg{!~|ڬכ?W*-l:&롫)-Zmy |=Dӣ=InUgmoZ?<b_2эG;bl+:Z ~]p8A5B ]0bH\_}!WW/֛c]ͣwmrDHif־C[ogo>ƬO~&{5߾MZÏmrzcCFlձ?k^'ҖZ4-3ꙵu!'z=v|wًgB׿x)bZ!{! _&ݜaKwmΌg7?ҝ22J2ɘנkW<#ᐥXoߊ_U3˛"~(7^H=EQ>]㕝!۔g6=?7?T m J#B hU Gj,st[;f`+ĭz8Uؚ*oaen8ϵ|us%}t{_~Wd^G;,4m \vΝ;ج<zSɕDv%iV.S2.`V\<Āٴ+ꌜ5'!JbkiS 7Ϳv1.oMi_r/xøm?)6bGϟMǨ*=g=qקy-W<ɠՍz2kڵ77!Wlo֛K,7#L?|y|z!ḽċS\{ZӯO~XjfX{ݣf!чGn#%lUV\IPT2-{;a ژ+rLFVᑋ`f \n `?}xɱYy?*a d$@e[*CPƶ'O̿$r4Mz[RLݗ-y+ro_߬'2l-4f o+cB1z? 51ǧkLm _BV]/p*(jlҫvU#` Qlk dm׷~hWmfZriӄTlO'ZSʼ1kΉ4D(m8I W =JfIgm)ƣ>nt֕6ܘ]xs!2OY r\ƶ7mHt+nD_Λ>qbe9C-.QؖGQߡ1!uzr9C,8YBGp._m~p3jZVY 󩻐W'se[_k$6F9Yz Р_N݅ vse[mj\IlMGaF[,whZmMk5d$N0$F:3fYM]GfKXKfc`}*blu/\9T`s)B:3ȵ},1Ucc[NYgOaޛ  Lm'|tFٙe[&j q`+)4\FYc[r9J%_*Ѧq=3y)N,--ƝQbDQg*q8EYj !y5$zŹGwc\ym3C+0%֜uQ WUs?%A| j}b?u|zqt*zl ryxؤYHmYk5id漣vxEd[`˓+y[}U~+ [},1r]I[>aDŽS)"۪ $TKμ %o?xlUװDӖ[?]Ll 3iZf@˝|o ABrX y5WY4ȽYE)JǔBn1;"וDƶ- IYc[,xpzتpVq7`<ЩYE5e>J-~˞kl/@WQd|'l)nlK搉 )kl T}[@ VM ;(E\I\fQ6r5~^2Y"'k_a_h]pn5D0h?%m}Xh]+zqJ"'XIA닱-`bYn_$> Wҳ-6uPU+lr?|6ʺ(v}iD4 q0o&hC`nhr]I6eDD}!ysUpm,pw;^\c[<A%+.4 F.Ac%kcmm(P_nQhʈ٣tK~?\r.y~:a 8AF5%z5Cz0mTc[zYpc[za8- :U%v@QRL}vdug (GwɫwWG0kGND.Ed[ j5V{Udd[2D;*`ȶA!nP案lk zQ (DVxBi OYJ%YLlKgfTeʕmq<0Sw!;s%Os] GN>:/ʍlc/"ۚGǒ ۅil5%"T}[҄LܷlusJ,47l+5jYzA?kl+4Y15;d=_輸lK#s cYg'f!koG)I W:"dX)ۏ?2+iRA5rx4' T+`f*ȶ^Ub*4dd[ʕmPf`<˝5}XlgqV槛.@/g[|t%WŐ=dKɶB}h FTRԞYZ,Z!pKɶZR`-Z:ꉚ.uxl=F8!]r-okE lH[.q%ѳ+^xqUvh}ߖܹCruk?{-rDg˶gs`$m WTl @eȶTl @eȶTl @e>[g@'>|n-'lUW9IPT2  ;g$0 3B|ub-^C05r =`Jm Y`rm `zn'l a @e[*zM/-#{t7K=zz} XHuzn/(٭AWT=il0uIENDB`DdE<  C Abtg%\m].Lntg%\m].PNG  IHDRk 0ugAMAsBIT3 |IDATx?\Gǫ\shpQ6kv;M]ԭ 4ә '29AO 1s7XV L NS`X}j߫W^{CS_կ~Rs !} cuBܨxvkeH @ܐ]U(;6syHvp2lm8iyj2(@l^lB7yգۦC W/z6* 'n!ċOסvK*toAuXG?t7 ŗB񋹸6`Dm 9k.ER@+?=u r@!~8Th)5ɓdՙF%C |?o?H_~ ~Fi\k6b(k:V$[O,"=8jc7Z(6tw>>>?=OO7O[1R6K(֭q{hpjQw'w>珿~||?_j u~EmZHB$L_Pm>{@; -@ ͽ!{_~zt҂ʴ ;+ sDx;7m8p˶z}blÓC4vD{?{yɫ_܏YQ/& F tl}Oq)Z;?ͽ=}tw͟7}׫Vrp宛ccS&0} P^1TD\?>>u~w}7SXd{ҁ҄SeiIy@avwf ڏ, o}OƒD<<X{ ]}o1}WFӮm.qTGMFc. $%aLٴqZFq^A:Fuʮu3`F A<]`e﾿’3[JwNKѨ~}|ζGD^~4bۧgP㉌ʱ8~+Gr\ P1m7nxb_r+slL}WD}1no{DW ~VȷvwBne y#cy40h}9=>SE@苸\ .)̯eƸ@Ј'LcBjxPx $Lg`Y rRqOy>u_dylsH*@a%GĄZE1ju}[<3JMAw4"ap^ij(Z,$FhO_lqr#JA< G2rjc#c۠*_i3KxY6gd%AZ%CMzB#GTDzjLAbx1.E&1UhܰO>;öiGhqWɐqʓꖏdR}Z74sdlD]0R I+qyId#2Ɛ9TF(H+qB|'#1O=#@)+l3OayD&"h0+,؈TŃEp< x7pq2!~-TaϨvE/c̋bOGA Y]6_ ?Ƀ}t\n.I50ֶ! ck'^ 2'xBxS0ɓTez8mL&|12ô%PXO&b$ gW}WEXtFCP b+~ʣdBX.gByT4E,4.j!_L>jQxGE"9gNj<"ų !&ҧ ,؂GTQGAJ>;bm\[ͫ#u2ɪpׇX:^-{B4+"auS+N+{ewķbŃA(P3r ҩ?ܨ.ʿ UP8[=16Hx0A~0rAfO w`v`3 S?_Iԯ lOheHϳkk7y`@d1?T$"B>Q$(sɍul(f qDՖ4hA\2AF 6Kַ }1/&C/LS}JA!_Ln2q d`s0.+? D?yRޤ:`ؿy ܩ^DdBJ?Dsvw)OD21_O~:;#H L gCj#%qD=K6Qg]b,q><3Wi=Q)sAZb|J|^^]jo Sf 5UQ/e GÔS6[̼l2ɇmeT-"z:6&@_I&d4_:P NCF6H܊jG!鴑|/g?uZ+ CD%WTϳEş:*5~!cИjjb2 7/b O؇`|2JPDkDwI "&4DRj@<(ă@<(ă@nQ)NVHI͇G,ik89J Ly-5]-xPxJk)]R䟉`` 蒔Av 0C//@̋iCL_ D 9eyVA P")m w 2Pr?1Tqf@)IUG{s P"A܋vWY\xPԹȁk >[WߛwR_q {Ts!ΌG ht]AnS13A`RPUmdK(j5+=u5bɓ'u ʓncWn,qTܓڲ>M j~1SaJR6|6q ݛĿnqgd[[X qǭHc7vlh)W%@{&pgBzy~![PTTrxGmwc$p! 59xPxPbu02Jxyt63jz|UĀqO}&=ߩRTܟf WB>w $T^Q5K_ 哒xW[zt:ovS}ݴz/i[=.tfJ$>~Gt| mwvBo87i͗kxY=DɘoCol/6}DyK _Ref437058009}DyK _Ref437058436DdH<  C A"q㼋NfNCj@=q㼋NfNhJ%/q*x Օo:7  D~1 : # N&D$, ,""ABX )LXd ²EXv xBDhš=9~xH'̻眾_{Ͻs{QJ= O2Q+/{*R݋K*+n;Z){YԔ\ @nt'J_rEu4Ts@{%~o10mn?o T!\'H.yR)wIRm+]vWjW^=AAzBRscZMUϫ *nWaO />rV4@Zڂ7yN9m@yy֦zU*q!?s v6>[`=?(Ly"S[ξj68PunW,7hLQ n>~A[v΋U/>\G8[mܮCyճTo:ܮyFb~_jWF5ݡWWult+'^vz&Js{vwϲ=WvV{ǖmP|oo\?}noq{kX*{vo۪W}Ym徶;$k][m(-nr<0zlcvˀzT_0oc\ˇK󖾔'd08m7G,YDfE_`2-urϡ r傭(!}^f]Ud[Ri+TۅO)W4\9}F :_'/ K_%U?JG @(gGs_'c>/&uޏgѢE,cqsS0-1HǼI:X/1X#R%iU"Xz*K}V`M,'`%i5I*, & V`^e*R%iU%XՂ U ZbY3k`>`l-1Hق5WX1XsR%iU#Xk>XhAg-ł,K 2b}ZZbYk``*-1HUFX_kրe}ZZ/Xo0XAK >k`m,7M`٬%iY  Vl&X;kXvjAgZb}n-1H݂WXge}>,:: XXkAg1u,Ǵ b:ZbY'^X?mrZK >`5g VXjAgFbjy-1HuQX`]ZbY V`;iAgN. K`XK >c,Xj.S-1HO`8> %i86+߱Y4Xi%iR  V[j'X [s}mQXd:}V'"Xw3X]΋Agu,yM|-m W6N6 6 V7byn E`Cf-^ՋX=V/`Ce-X}/y Ob X@ ew`/XAu?ȃ`C`=,X0#`Cy`=&Xc=R 6Ǭł5BFk2l(##k`!VR 61VR/X5c6VމU.XĪX `C)VTJJ5l(S5McM4+o`ĚfL+,#Xs5c 69V޹5Okǚ2l(k`-$bd1PZy RZJek)2,.X+= `CYa])Xk5x kʻF :bX@փ ew`m6lF+&"X[cm 6-Vޭ]kl(ۭ;k`"VR 6]VZ#X{c 6=V޽_c~+o`:A+!:"XGuc9 6#Vޣu\:rl(ǭ'`"V:R6SVz:#Xg΀4 匕A 9b5zs `C9gmzIgv!tӞ;Jq/o(CG#pnϺ]nI` !n՚-pZkCg|%=`'WK>+Wdt3 X%iט&_6X-qH?%KX>Hқ VX>@. {_4X8}{(XHo4X`9%iuN ,g!V`"`Ճ唖8}):!XI?aN帖8}q:*XGH?j刖8}:$XI?d堖8}A:/X{k{ ^#XZU ]ZYk`m'}ZYk`m!} -ZY[k`m$}ZYk`#}ZuZYk`&}ZZYk` }Z ZY+k`-%}ZZYKk`-$}Z ZY k`#}yZYk`!} 9ZYsk`$}ZY3Z^m2MK>k`U T+ V%XjCgM *'`U\K>\& x'`%i5^Jk ,c!HAH5,#!FVq=WyT~(m\N#P[h<+X :΂4 嬕AN V=N{ `C9muX'=I`C9i=!X(yc Gr{T !bXA 尕`:bX@r['Xk/y} {ʻWv V-v{ `Cm7vN+&X[cm 6mVޭY6k l(k`'d=P6Xy ZZCk-UX<*`CYe])Xk{ ʻLbb-XK@ ew`-Z+|ĪX5 sRc+Xkf{ 2;KfV5fx `Ca*$VǪJR& V&{ `ClI5X<$`Cd(XeUJ2UR 62+o`Hbx`C)aULakH1PYyk`=Bk0#`Cl}DzAVނSc)JO+o`uBbuX]@ [(Xt|Jn'ռsS}.3a]\1|r]#_+$/ W (%w~O运f lM_m$ksUqT3$97,;@t̢P3#1Fw~yM*|4끇 ?rBg{ ?/mُ}g;w({l!텿B7'[ßNx^`'?Yg?^0/r/ [c/~Wkqg?Xg?19NuauwvھQc[O0 ?r BgRe/Xuź0_/sy>Pu 8kOُ.:[89Wُ5ٿ}7Er/7x):?˺9~c<. h-)n>/." A{HQ+z3dן8JT殉##5Q4:Ա$:>Au q~y,K:unXc<3_z1֣XGV@}G}Ƚ,ӿ_dy!"1ⳏP &k\Կ#YG3 #>Sns흾~Zby's{xЇXN;:UX-0O{y A E(֑͝I.pslNF4ٺd뒭K.ٺ=`~q  ^#^h]^NX];쏯(z3uNau91k h]YX]~Ċb]~^X]nzxօ=I:u}M҉e龈%XuwgpN_l/[l֯y{akÕ}&t1Iv}wdFS=*&`:g {}tϼߕ{y:Xb5*w߂FS`Z#X?~0~x87y:?'t:g(z*TΣPbǬ|ڷ, ®](GzM|߁rgx?$?]ό]q$'1(l1(l1(l1FƈߩDY)/}:qYbmX.qnRhG1FXg,gR1o\=_⟤2l]bg"F1Gsce 4e(߉wT'&O $~cTcZbH͍%(FQ{.^ӄ$_!~ctXZbSޓ+ǧ#.KP~wy]wg!U柽T>Q)1Snmn,A15*`]㳧//?15ềxqhsce Q;)e?~plmNT}d"F}O|uL1Ũ#_~|wtG1F?X2NtƈB\>$w g!8l18l18l18l18l18lӎ1ΣOP+>2H#\{we?&?1/LiIy1=.~I#C!)hY tj*g',A1ge~6R1?3?R=ޛ\%(?Ts}.Ps{!m)abܨ2\/zO\ %(ƿT..LHe?oLoc6J&bm͍1%(ƹM֎# Ho>k2zF y2sYb %G%wBSG]lcߝDxm\|1%(1BC]RG}<}usiĘcMXW%͓~jd0Fgӌє$1ߙ"bT?D%pQQEchj1H52J- hhr1*O5_Kqh(h=19kPtsceIuMy*75.!J1PenWwҙo}eIIM*wM/γ7V3#|_}tҸ,A1sY۰];_(Ϥȉ61kNzrYb]}';;ɿÉ\Lhmc\1$F#52s@M'A3aihTXI,P;,2q&[:Uxs~ʽe}~9}8G){B PۆSC/7 95Yiv ࿑5}!I@>^ag>BϱMbƸmKx `}S=(mt FAJ۸/p~죒%lߪ e_zZK)K" [$@$NormalmH <A@<Default Paragraph Font $*:>BSW[aeiuy}nrbcs $*:>BSW[aeiuy}        @}/X$r$9C_iyuUi0 www@ +[p\    F*( $h| @ X "%@3 x  0 "(##2 x  0Z#F2%@3A x  0"81x#(2? x  0!$`"%8 x  0!0%`" &> x  0#81$(2= x  0X +`",5  L j","- "J.>#F/T2 W C  j","b,7T2 ] C  j","-6x b 0 b -`"-/  x c 0 c!/`"0-  x n 0n!\&`"L'(   hA,?|Light upward diagonal"-#. ` ~ c $?|"+#,*`  c $?|"*#+*`  c $?|")#**`  c $?|"(#)*` x c $?|"a'#b(2` y c $?|"@&#A'3` z c $?|"%# &-` { c $?|"##%,  hA,?|Light upward diagonal#-$.f  s *?|#+$,f  s *?|#*$+f  s *?|#)$*f  s *?|#($)f  s *?|#a'$b(f  s *?|#@&$A'f  s *?|#%$ &`  c $?|##$%Z j","-  "$J.j$F/N2  3 j","b,N2  3 j","-  bA,?|Light upward diagonal"/#0  bA,?|Light upward diagonal#/$0x  0!~'`"n( x  0!(`") x  0!)`"* x  0!*`"+ t@ &d.# 4 t &d.##x r 0 r).  x s 0 s).     bA,?|Light upward diagonal&'u!#(v"`  c $?|&': #(;!Z  S ?|&'#( x  0) !.B" @ +"B12 x  0$,".<# x  0.1B12 x  0T.0/1 x  0<-#-$ x  0<-$-% x  0/0401 x  0+p+-`, Z j","-  .-..N2  3 j","b, N2  3 j","- x  0,,-Z- x  0-l/-\0 x  0<-%-&   bA,?|Light upward diagonal8.,5/-   bA,?|Light upward diagonal8.l+5/m,   bA,?|Light upward diagonal8.K*5/L+   bA,?|Light upward diagonal8.*)5/+* Z  S ?|8. (5/ ) Z  S ?|8.&5/' Z  S ?|8.%5/& Z  S ?|8.$5/% Z  S ?|8.#5/$   bA,?|Light upward diagonald/,a0-   bA,?|Light upward diagonald/l+a0m,   bA,?|Light upward diagonald/K*a0L+   bA,?|Light upward diagonald/*)a0+* `  c $?|d/ (a0 ) Z  S ?|d/&a0' Z  S ?|d/%a0& Z  S ?|d/$a0% Z  S ?|d/#a0$ Z j","-  /-/.N2  3 j","b, N2  3 j","-   bA,?|Light upward diagonal8.g/5/h0   bA,?|Light upward diagonald/g/a0h0 x  0<-'-' x  0+((-) x  0<-@)-0* x  0 <-b*-R+  B S  ?ZSt(t St()/5BCGN_`@|<@GTimes New Roman5Symbol3& Arial"1h+f+f>02 Jim Gemmell Jim GemmellObjInfoObjectPool,/2]㼾2]㼾WordDocumentSummaryInformation(.0Y bjbjWW ==]JJJJJ V$J@21112222222$24V+21O1^111+22+2221D2.<12222D2z @1*HbJJ1X2 Index Group 1 1 2 2 3 k=8 =normal block 9 n =padding block 7 6 k=5 4 3 =EC block 7 6 5 4 n 9 8 2 2 1 1 Group Index   <=UVwx5 jUmH    "#$&'(,-.<=>@$    "#$&'(,-.<=>@ABDEFUVWYZ[]^_cdeghiklmwxy{|} b@ABDEFUVWYZ[]^_cdeghiklmwxy{|}$}$ N N!X "W!#$%za9C_iyuU( ww     T !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRS8hVWXYZ[\]^_`abcdefgjklmnoprstuvwx{|}~Oh+'0\   $ 0<DLTss Jim Gemmellim  Normal.dot Jim Gemmell2m Microsoft Word 8.0@F#@Ja@EbDocumentSummaryInformation8_973931860)3F%H]㼾oJ]㼾Ole CompObj24f՜.+,D՜.+,4 hp   Microsoft-  Title 6> _PID_GUIDAN{0E344DCF-7F35-11D2-BAE9-00E0291ABD56} FMicrosoft Equation 3.0 DS Equation Equation.39qRHkIvI k=dk+rd+1 FMicrosoft Equation 3.0 DS EqObjInfo5Equation Native d_9739327098F}V]㼾}V]㼾Ole CompObj79fObjInfo:!Equation Native "_986891245 S= Fdb]㼾pd]㼾uation Equation.39qRόx~II dS=ddk max +r=1k max +r/d  FMicrosoft Word Picture MSWordDocWord.Picture.89qJlD]|_R68t+x*/^m!Y"?j;vW$nxfgTj<ߩy;؞;S*WEЫ-~[R[RXȞKB-hnyqQ1J\b˹C[TC7=]j tԉVVy O;.*{:=?/P%\='4[S".~Xse!UƏeg*kAeJ8NJr+m 1ȆDc5F+/@o/o$ jRM98 `}*/h c1W6c<^Ʋ\9‹ks7qy5b^W6ghw/(ﾫ}Qnr;6(݆1~\ؗJGL^}Z"qA}O6}&^#Ǹʾ-ow)wro?&X6ө۾}Vu*~w|\Z˒}c4Rw%,Ae?% 3>>8SRWv@ug9n9е"o(uA]J ?j'BuM$6?oԎ?8=E9>6>F^aZ<}, /ɲc$:Nw-deͬu\ j,Y_Zcf?O1ͼm(//ayo'j76U:''DdZ<   C A "OwzyX v>Ĉ@=OwzyX v>|X1(x ŕǫAFKap@  <&  0^〈B4!* b$DD>#Ĉ/DkQ<3~S]*w|sNׯT0OS!%g(~K V{s*wYPTU#y?@hҭMѣ4>RbEw =ek-:6ma_B߶j/VU'JM]:EV ݓK8^ڶ>W^FbVo"}9YürjVciH{UtW~^|D^JBZ8TBP'Cv_yݯdJ>O2y>xTݧ64}>گ_W+my5uvlv{%ScJ4nX Wg4on7-%E6ighWE_o&T>蓧J踬_{_Ns>{nsvzYTmqYђ麥Sld(-7O.]L? :G0Z&Y:RPLsak dn+/}Eu7Stc Y 9Wi*kLb?.k/?GW @(=֟ScE6)ڼ8Ǟ vnk0$ZRH(7:Xna%t.X(U(-)C(,XJXhI!xb}-)C,'[jX&kI!& V`>b2CK 5Cj:U K!N -"=ukbm:``'I#Mlљu;[%t:K: V{wXi%tj/Xm+e-8)-iCVJZ iFoeZs4!4j!X͍b4!`5FofTKT۟*HKU$X*άOaDK`}d-ǰ|%tH&Xoo|%tP F?h4!zW1]XђF:d#Xo ֛Fb˛ZH75o,kגF:dWej^e-iC˂`6 XvkI#v ֳџX4!zR0IXВF:d=!X[kѷX-l֒F:dmQ?fQ-iC֣`XG`4!뗂`Y`4!`Za4!맂u`k,}ܫ%tȺW~źYw b;Ywb-bXnӒF:d&X[==XnђF:d"X F/X `QKu`]/Xs~ź9ZH95[f}Ś L-iCL&XS>bMe4!k`Mk>bM-iC55N>bJKU%XW ֕Fb]˕ZH+k`tfe4!k` !Ff2DK5DeУOΉH?a/H:y=a X{ F`3`쀍dw`m[H;y+X[75`m6NFam X!dׂ^6k=aH;y ZB~Z'/k`̰VՐF3Z%X?1Uk'rDV֏ kEZl$+?eua- X wF{`- kIZ6%Nk`}װEF]Z(X7€rl$ 7 `dw`U hê XѰT:yG V`]aXrl$N+\Vy* ;T e5(`ѿ`#Lņ5 ` \ 'łO.4~BH9y/ua X}!F{`+`􄍤W-U ]a#)svRdX 6R'o' X CiI'o;j#X MjhZ8y[ |ޝUw%j>}Լڸ:h|r]?.k/?GW @(=~N#,o{¿Z_WWl3F*x*~^9#[s~NdY( O~419=x=V܎UUtm-z~z^nYg?kg4/":xOz[~OsOgc?]ׯ|~Xg!b_JlwfHth+~dYg>Xg?]sXgs:9HO׵-?iΞݾX4嶟i-ȵuӜfĺ}vcuu3:9tϺ}}bYg=n_O*JQ1?V!?":i>}g.]ԿX~{+_'Uy]=N{A9%h쑞qxy%*EʼyVH+ =Q4I:&uL1#Ցг2GmX˕]'<WGFtocwr <Wo6uȽYG#%k=pcwicqu c _B#GՑށgpgy=B#Ցޅw:/g MXG73,&x>g?KR.I]$ug]s\]toM .<.4VPJ&h]y~\]h>;/;dc .< ..)ol*к<лԷ 鈫 NՐ G ~CNh]xHR~zO1ig7[%K/_R~I>\ָu49kߣtt!֏ʿKQx',wA҅X?\?*& BBυݻEoS;[WA8.\={'~ԫ^ _Nbxnz\{^;ݼG7J ~+xϬ*q26IMi<|M~}uO"uY~>cg.2NnI%1Jb(Q$FI%1Jb(Q$FI%1lc4JxbD(,1DňƴE{!?2bKUĈ#z79b]ߥ~&?sB[7F\we'FFm/o#F3Qi}ϒe}uOoooeDَ'Fsnz;1Dňޛ.xn?3c] cMxbTjc^}ceoGIw/U#F(Zc5 F\QgG~u}'1Nb8q$I'1Nb8q$I'1Nb8q$I'1Nb/aʟߕS=+Ęcm벟ލ?8?bkǵƘ3>R(Ǫle;>] 7!ELאT;\?cx8َgs䟗0yv|m/}\*mqb -ի4WH e=)?~=[ƾYvS3q_0qߚ]TMQ`L?2z5LML웘ر{#+6i^d+Yo,v~ %6wO76&n1r -|Rd-b&X}oݰPݧM5]jOfSiq{9G6Z0|Dw(zXMygPua֡ބ~V=u0.S{ʔa%HT={{s-bͪFo^< ija6Y]T}I/}Hؘge-X "5T^Xc80K9c0e}|M+yo.é]a]% ,7>|E)=XV(d g-2y1dv2-p )R8o?Oy^rJ8߻k Bq}qגՅ^T{G\^l,񖥾}Am0Pn}]mۢܮeUZ:4cQ6vPΛ/6FeyEĶ-tǹ}Oyuz_[734|;fP?//yѵE>BF1$}e_9޲unCTA<=QYA"e?.C nT|ϫcAԹz۟g:@[I\Un+/:>L|OEkߟgC}e`_\ W{=c[t?e%_2YyLB{ {+62ehq΋Q$n,Kf|A} 1L^^~Qi^sOP˺Dd<  C A"f^xg̀T,U Q jBD@=:^xg̀T,U Q j}S,w!1v+x]{?. d-`A^/>eYXGyj*ՠ*c mcbkј6ZOMĥD9ܙ;;8o981l4ʦUlL|s:kC+l{* X{~=|=/`k;A}|NI"OOޞ֮|1m ƶǽYgN[`?O|74 ?P-=S*\0Éa ?ܿb0BdJ{1C'"m-|0 I7&PQ,]##A aD{z %0?3r.ݿ+Jೣ_튬hNʮ`V(vJפ]&[N}ؕۃYSkQؕtgD7ʮ^FP|CƷ(u6X^)u춙uϽ+]cV1ɮ͗Ϭfs#1 {zocM{'&lW3n|ݒ<چq2ڡ/%lx3\u?_)GGTSV׭peQwΑOq ۅe>|+w ۫aZzxa 9g1-pYg1}EL3~ *+p_23x;K4iƗ"X[L3c4/IfN_䟡䟡oQ3b;4]H*|!,ӌ?af1xIɷP4㝁 (Zwv)F%?Ӳm3_ ,?ӌ++OW+f| gZJJ?GǴ커~L3^R~Jf_үSOʿY4)f(gJJ%gZowG j%H?_{;ϑWbՖ7(ݳϓҺ?j_camPX;ǑWkcO|]!O>& Q?N0V,.ґWb@|LwC|e>hMa0R>bY\>"l#ύyYL##tWcB怲C|,|?0c>;X[+1G?T!O>n>hǍS&k)j D'{S#oG4Keq.G^s=,g(;G<瓅73ÖQ\=1x9Z'[>j{/K#壊|!1xGovȓx.4 < ͣ,eV,.-y%W{#?5<6گw42c;5w]\0L\`(yԅ | LG]x}ç`?yԅb|иڋ t͏ϴmhu5..&nT^Ka0>ɣ.$65?yԅٸv潛GP=y^0ᕍHDyԏq}]NVAzGxڧ`=W#8&:ϣ~}02[vYQDyԯ.~l3Ŷ꽭HWTBO[~E``uTGB0ڬ~BkQ?WӏwXwe}dY0}ɭneqFϵo@xM7z[,a)Seq4y6FO,<g#ZCf5X:\-ez}{MkHlG,G:/ݪ-x#og-iPGs^0x?>w a1l5tc|_6zWV>X1+ҍX/Js O_qPz~%˃OY>~L߱,. Ew7yL˺';Yx',.W1~qi|_Jg,|<-)Ǘ,RH5>σ/oNsc~77 +eqMO;KSm|YÎo{RoY-e|jK5؃/Ju.ߡ=a=t {PXR7ke/7(-a]>Ӯ̬tEtiǴaܗۜ@a(C..4N֒ utot>40ssKd* _E>rO<3I}{`u:f*<cTOVC:hvUFw3>aW/cu1|OGOzz{Ug_F,{3N8=ϣ`dnRY|啾! 4;|ֈJ<~hB1Xv?g Ii2(<;^#QAVVUX7ozFm<Yt]6[UΣ2sOCAҁz p!}$k rnr@!O}u!K'YqՃw0ݮtv)/r_󏉆LL Uoʔ7eK$no~.˲|Ԗ=gmӇW Ǖ9L[۱?Njj8]T:n ,I;rwҵQqqo.ݴ\=_6?ߵ`e4cGgl|`BwbaRb hY\gye,B ۃKEӘ~Y= Ձtԯ*K},%_G \Y:I $S\G0q >LMe{Wh-U9W3mxz`:W&:fJ;'?F&Yt>9&Ae|Sޱ*ݤN6ˇwCVGDd<  C A" O&EoXS$΁ĶX:@= O&EoXS$΁ĶXloQ"u0x*Yx]}l^UwmineLźee[[vF'2@7a0_BqNV۲ьu`5ΰ#  #K4~#DB}g}szM=}q>syO"I6\--h`*6ox@}Wabl3l|xxlaz G5}(2dٲvﳁ}-;Rїy "8' .:A[맭 OX+ə6*$a<:e2xᦨǙ@/J?6Nц [J>ɗ7Jo@fx^#`u2' +ii&;^Yjx/HS,}} W0}dW}hR4)|7)|{ޫ q,r\ҳ>00lCgPN8 A;LR~HOIޫ^π6:s1QTAW_YXh oU~*1iTu6U>[[(%(8Ӓ_Mצ+)8-?M/Ei_0C׬TuVU?N3S"kP-Q-Qu;#\eHRXWbR/e9_+kc6Wg=$x$w/vکZ1/.2DWmAxwClco62qpS؈yqوՎ, >v<و,l_Q Ma#e#.t!*=Ffapq 1/.IG^_ACl,lt3Oa:J<وbYLy)lļlDXّW+b6C!O6p6jsOXya];=e<و(QmS6b^\6"l#K1xWjG!O6u#f嚟kN]aaLztr}_dJ0Qr* d!ပ)OY( d<;Q^BfKgT^N2_SYx=n?Ù}ibs1}>bWyPl+1x>h'ʻ]Aϣ|u~+Z^ʻ0]BTQ6O_ޏ`\V`1k(G}%G6+_)X6*<| Ʒ_d[4czb*<)WVs5|1C5e#{#/AxCWz,<ڈgaKB5e!<5?h#K v[=RK?6=EY؈/=~m{۲4Ưc^|.G^;k=zu ژOfam`[!_ȼlL{92 ~Ʒ{]$K9k_2?+wy~_ox迖o|ژ1gaY֏hI2/.Q~@x7'rjcދүe^\6^ZV/%}WE9G~q/—'ޖ0kޖ~d!Րo;,vJ~d|-`ȩ,(,v.u¿BL0}ܜɒ^w—>#^¼ Dw!G-v<cNVC-htQtKtJ|9IΨv KE~gޣelqї-cr2:1Ֆ1QDe8^tMdLʋ7V&iw_~A1_hwD~K) wҘaB~ K/~7yCۏ0qS=qZ`ph lcX?nC?lp3 Kwom|#>߈O a-֓kF}^csF㜞9M'Y#]X#;Gl:7W;t`ڄUToNF)sSiUʋ7]uJ>O7.WeYw7ԗ ous;>ً(WhM}]`Fcw ]ZxԻu"XyXO}Yzv|{GUȦrtz|ЃzF#>z%vy{=oO?E ?t>0z ztKc4%i_@}$>lS׀ꟃ~5> c$c\o 9^DWVڵ29>S5S:eѻ.֘Yj曍|U(I=N:K}DyK _Ref437058009}DyK _Ref437058436}DyK _Ref437846537}DyK _Ref437846540}DyK _Ref437058009}DyK _Ref437058436}DyK _Ref437409379}DyK _Ref437058894Dd SB  S A? 2 Q?X'2 i`! Q?X'2YrM h h`7 x\olٝ=&c@iRN9qI0$ҒEn4A&P OUpzMVR4b!$|qbW\ ڪ_)W=|3߼{}{ jr;^L7u'T_HtyO=9ߠ!ݨmJ/3} ~ /WlIHG_SB#=R9F 35"Qblέ{۶{g.me >DLUs. frv0XȀGF탖3i☿8['ڽYm%DN,0K2/ω?o:6f0wEl,wCT=gy>&MUwm 'Fr=>Zm~Np('R|uڪbL4U1sydcX]G2}YFɣ, -?h)&"mtoDse=QYYGIF7 FGsH,f}|!n,:q1ƛ7;ŧeݝ`UX$bؗ2%ǨQΨ,dA\c1.xXklʉB;yVfR +B-!8g$U]њUݐݚ쏈KXy " 4aC sGl^Esn0'{:ט-06??ؗ{=TRYlLKAWȸ9TrYrR)6AxeOq2:ek~r pa30?k*>owtz4_HϢNs$PF?߱#LwTAYE1+XS&z9`+l٧B Jn3 W oѤ#Al쵂5@Ϩ$YQR 9WU0am;/^tAc),믿F9s@ɫ6Z9AA7T1T9¥*+KPl'i\U>GFx@q JSE*જ4*.qPN h+}c;LU*81`Uʪ92ƚUWv4ت|Ăruvv\AF ѯ0Uy[bds;u1w^dw/2)|O,b7X|^ ,Oswf /f},V؃ cWbqށCy3X/i:m/kK] DWc\hUr|4ϫ ΰ$gm K93N|~K/qYKb/kM218F{u=[7zPn7 KM93ܲemR0r=/\ ;} jkar&釤U#b&rmn]ۻ31^c0Y1>K>$Gʌv[ l@͠e~olU*7٪[jz n`fF׭XI3(u@f|c;*k蛰>6R5㽆EsХW@]C_g~u՛jݩỹ'f֦0u1Gs}ؗUkvX[|&1=*6e/jWFc}]Yiװ3gZ^-xF^ʿO, ^ʿOgrFp8Nr8f԰5Fk,2okX`_.KbQBgӝOw!/}R[uv {x5Z j1;Zu Z١].\Y#b7L +vc{UYUla-Xݡ0X)aL(S (X@UnR")ʨ0Ɔ¾b<`$Y "e%c=bcS *2Ƹcb 1ᣬ,+#< )P}E{P?c*/ƋǃO8DrGb\'GF&]a? dk cl> (X@} *WvX߾* *H,ځ[#u g~ol BU? dmpd(S}QN,@Tѯ0UYiY$'YpkS}QN,@Tѯ0U}WJ}WI<5m BDS 4*LV??T?7-~h`"RPL^+j){UIUcl1^X|x "eV?HA3L>bc1^Xb<[yjT?SO #ʋ";CTDbuy}8^q1>d1ԉ@X+S})YX@{Cw*UiU ^X,x;pkS~e5 )~TxٴTDfbWD_;bU ^Xn.Z "5kH JߩTT%xcȮi|LAD j)6,~UA4S!V?gkOV],fLwM/C s|oO$`${"d3(S}"QN'J9UV0`?cl'"1[jO!"6ƹr:aۘsZ"+}꤆]dwxW1,>ga!2"eĖ23=" /={H9=a{XaTJ,;8_bu,&hFIDdB   S A ?  2-Mt?gy,jh@`!-Mt?gy,jh@@e UxNAƿ=88I$"6F6vZh6>,,xV+Kńsgw(e7!}"dβXLdqZ2^F*/;EUbkkV{'尾nt:XBF?׃*"9~>YL÷Dd@=UǷ=>!-sSuu΢]~؜{@LʟLO&r8$|JHpIMn~ivy_Ḁj #`etHvX}DyK _Ref437149562kDd B  S A? 2#zzC",N`!#zzC",N @hwxRJQymY_Dp $VlJ$ JDL@ _,,,l,R\LDݝsfsv3 F %EdV ΒQr'&y,D xt+l5z /AC\q4Ud4ţ*.ӆ[ } Si^m8[6Z !eEm3ƛسn)5ch-۸֫.c1ss$ cW2ɻ)oA4fn,8?} !on祻e4H oGTy["[4Dm"Q =?u_Qte0Dd{ <  C A"/Aw!T͕ T`/"@=X/Aw!T͕ T\F&/x Yt'!DD 1]WR]յvukﭻگqAQ!jTl38kf9]OKu+!w99yN,k+/_y)>}k#gewKYȲe{,;Q^7+/_>+#*/T^_^s~}}ڿCʳw+m~tq.[e1_Vn_9=﷝;{盶[>a*E?Keǥޮ<{_+og[Xwl3~Nv']-/v}||TY^pv?m7/^ܷʾ*sre]sx{~>Tz?y:~?prOOo}]w??[*?Y>_4cI/c9^q9Y=}{~=Uxտg~ _ǯ7M?|o=]~?{oS?=8wX/p*׿_{o?x_|=]}ğw`odϗ7 x&"bʹn r6 yY{xwS) ~e|?ws9 ^~% xR)G?ī*|x??1+xa0~CяGm|~ŏxe$xs<ǏG`^3<9Sx^p|)G?z|s;}s<ǟǟ/&)xe0<9//x ނOSp|Y-Wx+ފOx{|+cX)G?ïvg_G__o7Ng2֌)Gƻ.|s<ǟ2딣Wx7ލsxa0~߽Y9_ɏx^qK9zSS1~x?GBxUxވ`V}_s<ǟßO'u o >w)G_0~?o?Vjqr!|_''#xUz=x+ފx??2<< x5^>/Kx_ rq~ k2^r77NDz/Uq~ra~ «:x2+^H92x??g3u<\8?Rލw89Q<~U=7xހ=>p~R?q8~2׌5Mxއ$9_e)G?/jo[~49_e|(xяGY~ k6 hr5| ?ϿX|owxށC >p~S44""~?_/[x=?Z産,>kx%<_*ۊ5 xޅw0>kgM9ssQ(~?_x5ބ7Ȋ#>xSxlf]яs9 ko{8ʊs:x-x/og9|_s<s;Yq|rE~V1<>Yx1<~??_S~ox=ގx?>of/Ro9q9~?Ux$+産7x'މ>/ _oK9ss++I$~ׇ*^~ro›. I|_[/9?_폕W ~_o7Zo۲;0>O"o9O//O9~?_ů8x}$x+ރ0>OK;x}S((44~?OYbѫjovG8YO9ox!_m8?O9 ~ o5x ވٟ̊GSޏ(>2o9_Ί󯔣OW+M&^-x'ޏc>x|}4os<c1?LV|O9z^owx ނw]gߓ)Gge|·x|ެrE:~ƫzo[ns[YS~?GI$~?_DzbO9z ^7 xކ=>O\V|}_-x񔣯+x???+1+R22~?_/kNϊߟo;NG|KY{Ro9x5^/gU;NG| y|8)G  ?o%+R~?WM&^ x5+Sލw>4/x|w&Go6 Ao1||_ŷm/oxg)Ga|'Y|_—'69,,~fVO ~cDV)Go6 ƻ~oe}gY| _u|s<8I'I|×%|_ǷmM9zށ= >/O92x}_u|s<'?;//G#I$~_O9U*~uxވ7x~>}x>c>Ox\b}}_w4>/ o>+Os<|_79_R~???//G1+S~?Kx^cS^ xނxރxrVߦ}g|_W|wX_(+WW|w<;//I"9SlSlSlSlSlS ȊraeeUU~?qObO9z^ox5^ xނ+Yq|rn!|)<^//*ox**W33a4>yV~+*o;x;OO//G#Qh*+wOY~_ƯxuV)Gkoƛv»^<}ٿ̊#>O<>/K=+J7M|s<şc}:+~rWWq$*+S~?_/W ~౿7Yo[nLJmVߧ}g|Ǘe| eO9.x????'i4~?_ȊR~ ox5^x~̊=mxމw=x>0>gb}|_5| }ٿΊrAyyEEe<^|G|i|x}?+ [9᱾X)G?Gq$~?)G_įW* o<++}mo6{8Yq~r!|G |Ƨ9|_cVVx Kxgy__O'iuuOV)G_ů[-kZYov {^|Tߧ} 'I|y| _WXRSo.922~ JyOY<~_į౿?\*^K9M&~5x^7 x3{JrNƻ>|g|Ǘ%|_7wS9//cq8~/+)G?/e oqRkZFo߿T)G{~‡Q|)<^@x}/ /*oxrQ8~?O8~R~ _ůMW=uxހ7MxފxލU>>(>O4>j?2oxR)G?OY~/)G« 6~ƫZc>O>/?D} _7 |w]0>x3rY|E|_W5| c'= >c>OxS>KkoxǨx ^8=[^ux^D8O9z ނmxށwx/ދ,)GG1| 'i|c?U*^K9+:o6S~?_/U*~ g)GƫZ o ~rv;|c*)GI|Ƨ9|_%|){)G_M|Ʒ=|Xϕ_/W+x^o[<)Gzofocr. {~a|cS>O3 > /xo{xEc>?3 >"/*?J}=#>O4"/*r=|_*:R6~ƫ77]oJr6 ;. {>c.)GGq|'i|cS/2o;xs<ǯWk5~zS^x-^x#ތ7xJrNƻ^A|cS>$>O,R^W| _7 | w|O9z^_ǯ7m6^~T)Gzo›o<˥bO9zރ}>C>q|Tߧ} g|| _ ~O9o;x*{o7[-~kZRq|r& o[6 ;.C>c>A}9|_%|O9o[{x <-;w;x5^ux=^7q|TߧovĻn;> >(>$>}u8O9>/ +뿆O9;xo8~N9z ^].ހ7Mxނ^KO9zށw]xރ}x?뿎O90>8>O4>R/2ko[xz?{9~ xRzoěfoKr. {>!|(xS8O9>O$>O,>/*o[뿅O9zm6^W5x ^Z*7 xބ-xކx'뿭Tߧ~|ć!|N})|9|XWU|_7M| w|I~k77:c*{ћfo6.O9z?ޏ0>8=ѧ)|9|_E|K}_7M|w|s<_S^x-~7 xO9z+ފx'މwxރq|?P*S>0>8>OxR)G|_—e|_cQ)G7m|w=|c}=ux^x#ބ7-x#bO9zށwx7ލx?ޏG#>$>O,>|O9/K :O96;x5x-DSހ7x#ތ7x+ގ>I {~|ćߧc>OS4><ї%|_5|_7X3w]|s<:}O9zބ-x+ފx'މw㱿Q)G|a|~O9>OS ><>/q~@}_5|_7M|H}s/ "/ O9o6xRFo[ }O9z'މwxރ}>wK}G| ' |ħX{>s/"/*O9o.{x]<^*7Mx3ތxކw౿R{^|‡XR*S>>O4>1TableU(%CompObj<?%hObjInfo'ObjectPool>Adb]㼾db]㼾 [$@$NormalmH <A@<Default Paragraph FontYgsnU:rstuwYgs   8@F (  l : 0: XN %0 'x  ; N2 < 3 %0 "&x  N2 = 3 &0 &x  N2 > 3 t'0 'x  N !#%$ ? Z @ S ?|!#e"$ Z A S ?|v"##$ Z B S ?|###$ Z C S ?|##L$$ Z D S ?|]$#$$ Z E S ?|$#%$ N !#%$ F Z G S ?|!#e"$ Z H S ?|v"##$ Z I S ?|###$ Z J S ?|##L$$ Z K S ?|]$#$$ Z L S ?|$#%$ N !#%$ M Z N S ?|!#e"$ Z O S ?|v"##$ Z P S ?|###$ Z Q S ?|##L$$ Z R S ?|]$#$$ Z S S ?|$#%$ 6 T    @ #13 x U 0U^1{2 dZ %0 'x  V s2U2N2 W 3 %0 "&x N2 X 3 &0 &x N2 Y 3 t'0 'x Z Z S ?|RN2O3` [ c $?|N2O3` \ c $?|N2!O3` ] c $?|9N2O3` ^ c $?|N2hO3` _ c $?|yN2 O3Z ` S ?|pb2c3Z a S ?|b2c3Z b S ?|b2?c3Z c S ?|Wb2c3` d c $?|b2c3` e c $?|b2&c3Z f S ?| Z2( [3Z g S ?|9 Z2 [3Z h S ?| Z2h [3` i c $?| Z2 [3` j c $?| Z2 [3` k c $?| Z2O [3B l  #13N m S ?|l n 0n TB o c $DjJNB p S DjJ TB q@ c $DjJl r 0r l s 0s l t 0t l u 0u  l w 0 w  Z | s *?| r  6   <  # r  6   T  c $?|TB @ c $DjJ 6   B S  ? n h 4w4qS 4 S 4m 4^ 47TM4#b 4s4|U4](g|4TO4u,;:4p%4t#,]:4s%&4rd4oSS4m  4M{'1(4FR /04?44;U |7 4:=  @4 Cqq@`&@@GTimes New Roman5Symbol3& Arial"1h44>0dy Jim Gemmell Jim GemmellWordDocumentiSummaryInformation(@BqDocumentSummaryInformation8z_991036663E F@2z]㼾@2z]㼾Y bjbjWW ==]JJJzzzzz  z(" !!!!!!!$"$V"J  "!M!!! <J!^l !!!!|J! `pzz}!p! while the other bucket is written to the next empty slot in the group area at receiver Receive file Send file block (encoded or original) from the group group group group bucket bucket is stored in one of the buckets pr5 jUmHqr$qr N N!"C5#$X %Oh+'0\   $ 0<DLTss Jim Gemmellim  Normal.dot Jim Gemmell2m Microsoft Word 8.0@@X>p@*p՜.+,D՜.+,4 hp   Microsoft-  Title 6> _PID_GUIDAN{CE0965F5-8AFB-11D2-BAEB-00E0291ABD56}1Tablen<CompObjDG(hObjInfo*ObjectPoolFI@2z]㼾@2z]㼾 [$@$NormalmH <A@<Default Paragraph Font2B@2 Body Text $xnH 2"@2Caption xx5nH .P`. Body Text 255=Iu|'wxyzn:rs5=Iu|'wxyz   !8@.zPF.(  l : 0:# N m S ?|l n 0n TB o c $DjJNB p S DjJl r 0r @ R! x%Z !#%$ ?  !Z @ S ?|!#e"$Z A S ?|v"##$Z B S ?|###$Z C S ?|##L$$Z D S ?|]$#$$Z E S ?|$#%$Z !#%$ F  !Z G S ?|!#e"$Z H S ?|v"##$Z I S ?|###$Z J S ?|##L$$Z K S ?|]$#$$Z L S ?|$#%$B T  R!dZ %0 'x  ;  ;!N2 < 3 %0 "&x N2 = 3 &0 &x N2 > 3 t'0 'x x s 0s   XN %0 'x  t "N2 u 3 %0 "&x N2 v 3 &0 &x N2 w 3 t'0 'x N R! y $Z !#%$ z  !Z { S ?|!#e"$ Z | S ?|v"##$ Z } S ?|###$ Z ~ S ?|##L$$ Z  S ?|]$#$$ Z  S ?|$#%$ Z !#%$   !Z  S ?|!#e"$ Z  S ?|v"##$ Z  S ?|###$ Z  S ?|##L$$ Z  S ?|]$#$$ Z  S ?|$#%$ B   R! dZ %0 'x    ;!N2  3 %0 "&x  N2  3 &0 &x  N2  3 t'0 'x  x  0   6   !l  0  l  0 l  0   l  0   @ =%9( Z g S ?|&x'Z h S ?|&'` i c $?|0&'` j c $?|&_'B   =%9_(x  0 '{(  @  & ( H  #  & }(~  6 s ' (  Z  S ?|( & ' Z  S ?| &W ' Z  S ?|h & ' Z  S ?| & ' TB q@ c $DjJ l  0   l  0 XN %0 'x   N2  3 %0 "&x  N2  3 &0 &x  N2  3 t'0 'x  6    @ _-f/ `  c $?|.u/`  c $?|. /`  c $?|& . /`  c $?| .\ /H  # _-f/j` %0 'x  #  .-/N2  3 %0 "&x N2  3 &0 &x N2  3 t'0 'x ~  6 s-r. ` [ c $?|z . /` \ c $?| . /` ] c $?| .P /`  c $?|./` ^ c $?|a . /` _ c $?|9./TB  c $DjJ T  c $?|T  c $?|<  # ^T %0 'x  #  N2  3 %0 "&x N2  3 &0 &x N2  3 t'0 'x r  6  Z  s *?| Z  s *?| Z  s *?| Z  s *?|  Z  s *?| Z  s *?|  T  c $?|  T  c $?| N =%9(  Z  S ?|&x'Z  S ?|&'`  c $?|0&'`  c $?|&_'B   =%9_(x  0'{( l  0 B S  ?  !"#$% K 41N- 4a OF4} ' 44644`4O4Q4b4)44A"#j4Q:4 44^ :4dl4 Y 4^ ) ;4 : 4mS  4q  l4rzXw45:1 4ns A4o  (4p x 4;u4I4 44PR4t ? 4:J  !4y$ 4xJ 4'\\ccN'(*\bpu[@'J@GTimes New Roman5Symbol3& Arial"0h˂6f˂6f>0y Jim Gemmell Jim Gemmell  FMicrosoft Word Picture MSWordDocWord.Picture.89q  FMicrosoft Word Picture MSWordDocWord.Picture.89q  FMicrosoft Word Picture MSWordDocWord.Picture.89qWordDocumentSummaryInformation(HJDocumentSummaryInformation8_990969705M FԊ]㼾E]㼾Y bjbjWW ==']****&&&VVVVV bVn9 8 8 839595959595959$$:<VY9& 83x 8 8 8Y939** /393939 8p*&&39:H**** 839393939P&39v ɸ#VV{839 is stored in next empty slot in one of the buckets bucket Send file block (encoded or original) from the crowd crowd crowd group group group group bucket bucket When a bucket is full, or a new crowd is received, the bucket is written to the next empty space in the crowd area Third bucket is used for a crowd split up to be sent first and last in a round crowd crowd Receive file &'Z\bdopL5 jUmH"'[\cdnop$'[\cdnopMN(MN$N N!"J.#$%Oh+'0\   $ 0<DLTss Jim Gemmellim  Normal.dot Jim Gemmell2m Microsoft Word 8.0@@Rl#@Rl#՜.+,D՜.+,4 hp   Microsoft-  Title 6> _PID_GUIDAN{CE0965F5-8AFB-11D2-BAEB-00E0291ABD56}1Table:CompObjLO+hObjInfo-ObjectPoolNQԊ]㼾Ԋ]㼾 [$@$NormalmH <A@<Default Paragraph Font2B@2 Body Text $xnH 2"@2Caption xx5nH 12>jqxghijkryn :rs 12>jqxghijkry   !8@-w P-(  l : 0:  N m S ?|-l n 0n- TB o c $DjJ,NB p S DjJl r 0r @ R! x"Z !#%$ ?  !Z @ S ?|!#e"$Z A S ?|v"##$Z B S ?|###$Z C S ?|##L$$Z D S ?|]$#$$Z E S ?|$#%$Z !#%$ F  !Z G S ?|!#e"$Z H S ?|v"##$Z I S ?|###$Z J S ?|##L$$Z K S ?|]$#$$Z L S ?|$#%$B T  R!dZ %0 'x  ;  ;!N2 < 3 %0 "&x N2 = 3 &0 &x N2 > 3 t'0 'x x s 0s   XN %0 'x  t N2 u 3 %0 "&x N2 v 3 &0 &x N2 w 3 t'0 'x N R! y !Z !#%$ z  !Z { S ?|!#e"$Z | S ?|v"##$Z } S ?|###$Z ~ S ?|##L$$Z  S ?|]$#$$Z  S ?|$#%$Z !#%$   !Z  S ?|!#e"$Z  S ?|v"##$Z  S ?|###$Z  S ?|##L$$Z  S ?|]$#$$Z  S ?|$#%$B   R!dZ %0 'x    ;!N2  3 %0 "&x N2  3 &0 &x N2  3 t'0 'x x  0   6   l  0 l  0 l  0   l  0   l  0 ,  l  0 XN %0 'x   N2  3 %0 "&x N2  3 &0 &x N2  3 t'0 'x 6   @ _-f/  `  c $?|.u/%`  c $?|. /%`  c $?|& . /%`  c $?| .\ /%H  # _-f/%j` %0 'x  #  .-/N2  3 %0 "&x )N2  3 &0 &x )N2  3 t'0 'x )~  6 s-r.' ` [ c $?|z . /2` \ c $?| . /2` ] c $?| .P /2`  c $?|./` ^ c $?|a . /2` _ c $?|9./2TB @ c $DjJ$T  c $?| T  c $?| <  #  ^T %0 'x  #  N2  3 %0 "&x N2  3 &0 &x N2  3 t'0 'x r  6 Z  s *?|!Z  s *?|!Z  s *?|!Z  s *?|Z  s *?|!Z  s *?|T  c $?|T  c $?|@  )0p, ` g c $?| 1*[ 2+4` h c $?|l 1* 2+4f i s *?| 1* 2+4f j s *?| 1*B 2+4H  #  )0,-~  6  P+p,.  `  c $?| 0*1+`  c $?|(0*1+f  s *?|0*^1+f  s *?|o0*1+`  c $?|@0*1+ `  c $?|0*o1+ f  s *?|0*1+ f  s *?|'0*1+ dZ %0 'x   7**N2  3 %0 "&x N2  3 &0 &x N2  3 t'0 'x TB q@ c $DjJ6B S  ?  !"l- I44 4o4b4@4(44Wcb4z\4O94Y4H4O 4H4  T4 D4*4(M ]4}(M tql4n 4o (4m;4rzXw4p x 4;u4I4 44PR4t ? 4:J  !4y$ 4xJ 4$$%'bg@p@GTimes New Roman5Symbol3& Arial"h+|6F,|6F!>0y Jim Gemmell Jim GemmellWordDocumentSummaryInformation(PRDocumentSummaryInformation8_991023154`CU FW]㼾Ȣ]㼾Y bjbjWW ==$]&&&&& 2&7RVVVV666G7I7I7I7I7I7I7$88,:Vm76y2666m7G7VV#.RG7G7G76&VVG7 6G7G7G7G7 G7VF _&&6G7 is stored in an empty block in the buffer pool Send file block (encoded or original) from the crowd crowd crowd group group group group buffer pool When a crowd has at least b blocks in the pool, b blocks are written to the next empty space in the crowd area. If no crowd has at least b, then any crowd is chosen to have its blocks written crowd crowd receive file #$SVab5 jUmH$TUV`ab$     #$TUV`ab >$N N!".#$% Oh+'0\   $ 0<DLTss Jim Gemmellim  Normal.dot Jim Gemmell2m Microsoft Word 8.0@F#@ZA͈@񈷾 ՜.+,D՜.+,4 hp   Microsoft-  Title 6> _PID_GUIDAN{CE0965F5-8AFB-11D2-BAEB-00E0291ABD56}1Table=CompObjTW.hObjInfo0ObjectPoolVYȢ]㼾Ȣ]㼾     20!"#$%&')*+,-./1345769:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwyz{|}~ [$@$NormalmH <A@<Default Paragraph Font2B2 Body Text $xnH 2"2Caption xx5nH 1?Kw~n:rs  1?Kw~   !8@ 1$ ~0(  l : 0:"! N m S ?|.l n 0n. TB o c $DjJ-NB p S DjJ l r 0r @ R! x$Z !#%$ ?  !Z @ S ?|!#e"$Z A S ?|v"##$Z B S ?|###$Z C S ?|##L$$Z D S ?|]$#$$Z E S ?|$#%$Z !#%$ F  !Z G S ?|!#e"$Z H S ?|v"##$Z I S ?|###$Z J S ?|##L$$Z K S ?|]$#$$Z L S ?|$#%$B T  R!dZ %0 'x  ;  ;!N2 < 3 %0 "&x N2 = 3 &0 &x N2 > 3 t'0 'x x s 0s   XN %0 'x  t !N2 u 3 %0 "&x N2 v 3 &0 &x N2 w 3 t'0 'x N R! y #Z !#%$ z  !Z { S ?|!#e"$Z | S ?|v"##$Z } S ?|###$Z ~ S ?|##L$$Z  S ?|]$#$$Z  S ?|$#%$Z !#%$   !Z  S ?|!#e"$Z  S ?|v"##$Z  S ?|###$Z  S ?|##L$$Z  S ?|]$#$$Z  S ?|$#%$B   R!dZ %0 'x    ;!N2  3 %0 "&x N2  3 &0 &x N2  3 t'0 'x x  0   6    l  0 l  0 l  0   l  0   l  0 3  l  0 XN %0 'x   N2  3 %0 "&x  N2  3 &0 &x  N2  3 t'0 'x  6    @ _-f/ `  c $?|.u/)`  c $?|. /)`  c $?|& . /)`  c $?| .\ /)H  # _-f/)j` %0 'x  #  .-/N2  3 %0 "&x -N2  3 &0 &x -N2  3 t'0 'x -~  6 s-r.+ ` [ c $?|z . /6` \ c $?| . /6` ] c $?| .P /6`  c $?|./` ^ c $?|a . /6` _ c $?|9./6TB @ c $DjJ*T  c $?| T  c $?| <  #  ^T %0 'x  # N2  3 %0 "&x  N2  3 &0 &x  N2  3 t'0 'x  r  6  Z  s *?| %Z  s *?| %Z  s *?| %Z  s *?| "Z  s *?|%Z  s *?|"T  c $?|!T  c $?| @  )0p, ` g c $?| 1*[ 2+9` h c $?|l 1* 2+9f i s *?| 1* 2+9f j s *?| 1*B 2+9H  #  )0,2~  6  P+p,3  `  c $?| 0*1+`  c $?|(0*1+f  s *?|0*^1+f  s *?|o0*1+`  c $?|@0*1+%`  c $?|0*o1+%f  s *?|0*1+%f  s *?|'0*1+%dZ %0 'x   7**N2  3 %0 "&x $N2  3 &0 &x $N2  3 t'0 'x $TB q@ c $DjJ:@ p) p, `  c $?|  1* 2+`  c $?|  1*K 2+f  s *?| c 1* 2+f  s *?|  1* 2+H  #  p) ,~  6 pP+ p, TB  c $DjJB S  ?  !"#$ 8}4h x t ]48-  4q4( t4 4o4b4@4(44Wcb4z\4O94Y4H4O 4H4  T4 D4*4n 4o (4m;4rzXw4p x 4;u4I4 44PR4t ? 4:J  !4y$ 4xJ 4&&')W\qv@Q`@GTimes New Roman5Symbol3& Arial"hځ6f6f!>0y Jim Gemmell Jim Gemmell FMicrosoft Equation 3.0 DS Equation Equation.39qϜII c="(b+1)+ (b+1) 2 +4S(b"1)  2(b"1)WordDocumentSummaryInformation(XZ DocumentSummaryInformation8(_990625443]F]㼾]㼾Y bjbjWW ==&]&&&&& 2&:RVVVV::::::::::$;=V::5Z:::::VVU1R::::&VV: ::::: :VF &&:: is stored in an empty block in the buffer pool write buffer Send file block (encoded or original) from the crowd crowd crowd group group group group buffer pool When a crowd has at least b blocks in the pool, b blocks are copied to the write buffer, from which they are written to the next empty space in the crowd area. If no crowd has at least b, then any crowd is chosen to have its blocks written crowd crowd receive file %&UWcepq5 jUmH &VWdeopq$     %&VWdeopq C$N N!".#$% Oh+'0\   $ 0<DLTss Jim Gemmellim  Normal.dot Jim Gemmell2m Microsoft Word 8.0@@'@p_ ՜.+,D՜.+,4 hp   Microsoft-  Title 6> _PID_GUIDAN{CE0965F5-8AFB-11D2-BAEB-00E0291ABD56}Ole 1CompObj\^2fObjInfo_4Equation Native 5_990939182wHw(P`[ebFp8]㼾p8]㼾OleX0x'[YWThQki ywXuq8CompObj0s p"88hacYWThQk9fwObjInfo0`Phw wwHwd P<=M; FMicrosoft Equation 3.0 DS Equation Equation.39q˄@yII m=b+12+ (b+1) 2 4+S(b"1) Equation Native <_990973022KjgFP]㼾P]㼾Ole ?CompObjfh@f FMicrosoft Equation 3.0 DS Equation Equation.39q˴TyII g=2S(b"1)"(b+1)+ (b+1) 2 +4S(b"1)  ()kObjInfoiBEquation Native C_990973701lF 2]㼾 2]㼾Ole GCompObjkmHfObjInfonJEquation Native K`1TableO FMicrosoft Equation 3.0 DS Equation Equation.39qDIyI c=Sg c kOh+'0 $ @ L X dpxV? /2kѷm|=#>>>O3 >C>c8J}ѧ)|gY|| _ 'K}WU|_7 | ·XM}s<F o[Jr»n{><.{A|G| ' |gJ}g|y|_ė%|=u|-|wXK=soěfo6}w]xރx?ޏ,=0>c>O$>r9|E|_—|_c9?o6{x?O o›fo6;XT)G{>A|‡C>#>xS)G§|gy|_cRq|re|_W5| _M|c ?.&&9ނx+ގRĻn>#bO9>(>c>OT)GgY||_—rU|_u|7-| c8r77ovc}DSލwx/އ>G|q|'I| ?s> /xE} _7 |ķ-|wX?I=so6;N SbO9z/ދ>0OS)Gq|')| ƧYC0>Ɀ=?8>OS>O,>bO9"/K oO96;.xOSގx'ޅwx7ދ}xS>C>(>O>3,>sR)G_—|_Wu|7Mчa|GQ|'XD}g|y|_X\*S*^(/_VxIp+yg˷o*|Xpa?^u7Vr^}ۧ TnGֿP׏ʒr ۡrsy5k]WFwgyW}u]>SϾN}=}Ͼ}z#z>Ȼz_p}};=?*/Ϧw:w<,wdǏ$+kSYP^SvoUl3vk_6~>Oϳg>>Zc߹dqCټ>><'>_!?[~|"^G+ tq}|oԔs_U[S}ߘlywm|xL߶L}cz[o{RU{}My9teUv5VFV>m޺am<cxTޗ|1scGoM;Ҿ+^?/VR yKLJ8Sv:efBH8v*1`ˏ!H ֖~Ϲ;]|{sgｻ{W 6xʇYu2^.ߟL5MՉT=))G.R|ZD|/l]{GEIRb\#=IieT%"剖x{&[loǾ#r}RTIJӿ).<%Zg8m"V8/]o 븇k#>/7M)[n?2'=˩vg쫓*n'D*Zom5'qnKax/_aBD3._!zPWL+~.%Z"=i,a3d*MV^~ң7踩eˤ̦n *[DuLMK`S5P9Ȏ"c+RlX6V8HMei *%S,AnKJQtA THq>R! k}"D*'q^WQpN݋h/L*^AqX/f'5R4TZTDe%"[ȞCnyBa/Y=rXTl*lGdՇCTH)Rid1D*/Tf T"HUR!ū4e+QyՃWC2hSy(yj^Dn+=S!KBTʕjDmGn=S!E%U~TzMRLJw3w?E]T Ȏat[t>-VC>ٿv3-en7o72{uHip]|Ye{̳1S]+xc<moR+_C2'/ݑWd'+\i=ތs]BZux}f0HRU)ߌWrX*TƠҋzU?rwQP!EU#T b?*}&w_T> Dȳʍ>yB4Y )/ }_ JDe "[z[g* g_*7jTJMl *!v3R`}K%j}BDHlנ~so3'[ݰsAx GA/jTJM *LgV#jTHqLg_*D*pEfքgP,A;q⼱ǜͪ.3 }S9,*󥦲="K  )XV_aQYmSDe7"ۍN!S Ric5վB3<'DU`=+Oc_vߺW"TVr*nV{rKxBOi/R~*ɯiTnQʞ@T:Y'"ۍv{B[amKVV_Wvx&ZnNK->W`;[Ntufʹjꆝ3NX3f:cI~o*eζ8c6DwKdb{J~ :]~o>wwzXavףXǣqPTs^72W㽁Q4$b 5w ߇\Rߒ?n;T#HR oӋEsoȽ5Xc]}mseJ{(ƈۿߔ$Z)#cmo+<}[Rzu|)NuWקXJ_^ދoiw7c^ 'BBL_W%^1?ˠf:,l nA's %ʇ\qzؘu4: * GQ`MrY BL}=/TMUlV>̇ԗ`G-YlrW#ec0Mwᆵ5dS)L+yҪu虤דq{̜ǏEQQP]{ M%I֯-5-4+yCW4Mz>OœP劇#k+R;!=m=Nc2Ȳf;s^2S2[F9~FO/̌toE р9:#2zJweF?v+yiz{Qz{kQS Wdk^5n}z߫Dh D*5U]3)>dUg?jvƯR;o}v+7 FX=I/0~殎Ti^XM*VjTkv"h[ Z4XjEeސFwFf;UzY8jdcT}DyK _Ref437753034 DdnvB  S A? 2wŰ|Ƅi&1J Sy`!KŰ|Ƅi&1J da G?HP+x\tTՙϼfJhc(P tIn!d0cC&MBpŞc@Xkm-,Enn# x0Aj#R,zS8[~w$o0s߼cw}޻܋‚iP+T)Rʕ"-ؖI7!фr "d˹QI We'UVgCZDL![Uy97ReP'U!~iUQ PnU%4rZUyHWe<8*؋ NF^ν׃*T:r3߳N5/*jJǾdUD*\+r""WscٯܚqU~Iz<{b{PZD\VK(\GhXK;*xR< iUK(D ;*!T{Qܪ r >oۉ8U6bV`QBU˹=Ȍ2sPW;j͠ |6/$iQ뉺LS0MM(ʳa~,grϱOilshSmrv"Z9yNȼ'd .p<OpJM<};y0@n e#A3Gq߀c#&=b"˹۸oqߓ*mYx uJy`Mrb[! "'[Uvy9Tw_B+{9|2r<%s;Oqu]r-;rȪfc*<Umd@x9)@NWߥWʣ,Pv)},M/ɭ+ѴnHۛh-̌+ hɬKrDʧl-r&wD/ZjD甹F#[Ds9&wD/UFjDыٛVxhGuQx A1 h0VOcA`G-B[ m$QP!ݽ˹ýBO<"x"x1*߄rvB#/*/ Ur455ePe6R_-C`CtMYTAīA!Ujkk%TArW}T@lJl%xb" " VBB#/Ʋ5ٟTS4%)P_wiYc&x|@1l xFJm\*Gd GeihکZhti3ҞؓmdԚHWkF`8Xuo Z , Z%G_D` t9F^΍eƙ/ UʽٽSSҪ bwVeF^νGUMrɓ*''Ҫ bVF^νGU*K / ZUr "˹}T$(]dl-]IxcM-Q'@9'ja3y}N7߮>j{^xQ:F[ÍZ-Ȏ764\gG1ڱӃ JEl"u½cHI,e] ٝ<l4[~6ׅ#mۚ~h]LT"!GA?(9 "FS~-ɷM&<,͸kL/oWNN s4\ag,S院n_Lkq"^;{D=r)R3ľ)rwi8pG|hzo5Ns7ò蜱ޝo'%Cg\YP]= Y[_{ f8Ί82X !w?F*f!4rn,u?P*ŋ*'%& "{N!UPړ*W+J b[% "NB,VDd˹O4r'Uցg8V3ʭ*3;Y}Tzzz-tn} ݰ-~øA6&i 9{jf6x"v&4/.);Օy2{Օ}Q_j꒛Ìy9wՕcBkT/΂WVc` {JT9@h|T#Jē*bseClҪ "2PnUAEy9EU?rE9z9G2"z LVD\@BVEC4rn, ]<)W|3)+ʭ*F^΍eTй*+w ~8s Z VF^΍eTܦF@@ٹx`+0^kEF=L׸xЍ|B:wsFyeedC1싄r:˹׹O#ᡪN `cq~+(ǵf,[r5 "L/z.B#/Ʋ_-eؕޅJg鰜,{cK^h}oR%ܭaR|3;H oՆpckҺ'[}+kɊ,B){_R[ini6 kG5G76ֱ:6y4Sl-/(w2T jDd*B  S A? 2 b!]./`! b!].[Y?-xpU՝Ϲ=$BH* O-geYhI; $O $;qPud ;RGHΈE-誈QS* yݼ{d~?>wN)Ob+k(_)+Rrd}:՚jl~KROh%~:Ǻ|kSd"vb)v#Ro)E|N_FҿŐ9ʼnV%8*%{~m#C}Cϝ(C2b9 "iqQ;VkQȪBa;ۨQ89eӏ8ۘ6cH۹5Wݔhi&*0|+zIdʼV\Er1ߕyYO[ns3R"ēPzX9Ϝ'K?bk*"ސ3Br^n:ޞ좪U>y*q#)guTWKuN^@9sMsFm3\CZJG_W3UO5˜ O17T{PQo%F0a83k֮ra' kkN1,IQk*xU~<0T'7$r;iMO/Yq}?" {;StjaTH3YJTbuVTN*'kSTk*8\Y )ȌLTwrqߩLCd\6ך )F`_*#Xq}~XrO?xJG~i `6خrsߋᑕblRǾhgb4y=cnbw9^Ttkn{fػl;r:x k޻GpA=WhgCv^豝?uB6s;)sRd9_e`yPe;ǐ fjVyiu23n3T2 MCd7#b VyYq}~XT*Q.".ZܖZS!U[YUθ @d+zޚ )Vgu Cw<AT g.FVr3B}ATo#QYʣθ @7JE4¿5 B1ĊH-̖")fKq3o#Bdfٚ )aw/fVg\!RYe<c1DBհGYjVg\߫C C@T^Fd/#5R<{U~<l1"Ql؇ZV 3WBg6;h$ 1THq `_*<ɸOcm~B\jطSiBhθHOؾE-D}d[}-a-m!扮oMTQW[;*Dk`AG7I5Ų$ё/# xVz5ŲX U"rKN,6*fx,Z#_F+9Oke5s e1#b^s%kmExk[NkuXYCU*I)t5Uکgx=`)̭Ǫ]Uxs$9ݲ NĖmmȵ-ٴ$勭K '8Jo$hL{.zbPe;bUqsV_{N3DPu *QmCn۬U~j!RYk)l'zjMÞd_*jH툦2<vu6ҡE0[*8<g?*XM~oNS+V>Ej]+{U~b5վwX+LSZEXCMCOR8Ka5վi?,*oZru}UPBw`SqVɯNrP< 1/ĸ ]fM_ /R~ȯET`n"Ky8/:?&cb_tN{aGD'+e5վi?,j с#Dn(k*8\KվHeTRxM@dL6C#El rTFXɯMaQ`4RjUrkBIX$V_{R*|OZҥޟkGTާċ<{J<.q?WPS")jܟ 3ղAgeer+z_YH1nt>?f5վi?1Py*l=ځvXS!ElR`5վ;BP9hI̲FT3 )6v̲W"݆QyN!STH,Yʳ&aRq4{>9G!g Ax6XM~o!CBPGP[fK#N'+Q!վ4RxFdt6]َ RDa1VAQV_â2PY D6Q}}ߚ )j`װ/V_&D*#ŋF}pP^㫁eYv{lY ߰A?mRn_kMr}>)lSr\-pes w (Dd*B   S A ?  2avCn;A`!favCbY?-4x ՙf0Q`H+j:&Y.z8{CV9".49"̮( "z@v=KdwoWtߚ}~uvKQ;!:i~zv*k x݌BÚx}!Bal/HAuSE2ok#jbua5A%(f{͒n=&̎Փ&ZG)cGl#+q&¼ Ɉz_g-[<`):&iu*:,l,q%Gt+MOvR[BΔ~c3z" Hnɥ]8U%jeͬXߢVVAڵnZJZb,~7"G9$my<"Kq^ɣWZ -T]oaYc.JDR-ɯM-N'+$A㬴jޡNVWS$dttζVG} kW"]X ПIG=ZX׻5x]lF6fiX) DcC~K5 Opbl==fj+u>ue8c-=1FcJ-sYE<=w /i'~; :TOcgXkYj Y_w>h-]"y:K:Q9X:1"[Ēo溞"mlu}|9&[]^6:muXmE|3^Xor"0=SwUs]s񺚪!ʺl?NGpRZZTEm +\=ˤ#zWXh}m zmw*.UrQ{Td;:cwJUQJ#~uc(oZ7swi*}QAd5''TH1V*T&: MW Qm@nb6짬Je6RyBSFDQCnRifu Y_T THGVy ѸT. @LsQJoT:>J.J RQ޿2b1ER4–+FV'ߴTmTEe+"ۊ TH$l3Ry R٪|DvQ]@n5!VyrTSgr ]BTEV̔ )eFcRʷJFn r)aW*"+RJ2Ed"{/Vyҗ 7tj ]?N[rc^?CEw(lˏy; Sv&َٳ_PѵU+gp}LgvRw]y83w-oXd͇/ŋhgMF;{l'=z0<)e=3_]o1 F^cm:Ɛ FVyyi+>ƘV#LEe,"CnS!E_-<:T "{QCn󌩐6Vyr2MSY"DQFn" kbW*QV',T~3Dm7B`kYcN8 3vj4n?]l:܎S!ų7XʳN8A%;Cp׬zC~(B XX*R$E),*KYp|zPTEe "[#THQ {U^T:Me/*!.˘ )žeW*KYp|/ "{ QFn%XKN8_ [J^s.R!۰OCeFmV'oHk4n?.J Bnp|AO!n]lsl֐ק؍]-?t 5k7hgHvLBTSi"4D):)i,J4K.;׉}R#eld2{ξ.8Gs%2hZݚ!5들lYTiOh7ߕY+qlYLC*|3Y)T.f:+[f:&{,CD׬[yּuuL,:c({9 WchHu>m̊E"j^_}DOt#bkU'<Ӊl)<05+ ,i1'O+sT{Ƹ{-c\ uHE|NMlF!̫iH&mͫ Rv,8F5{X'>{f}lDnke\+r$)tβ66AѬ%R6:dS2,noJ߲?U<iOrƹҖ]]g, M]wG* EWc/έȸr;Je-٬)5|{dis=-\yWGꓧo'g>m=t وzd2 r{ߘ )^gW*YM~>_;H{5 rB=ϣ9vvg1TdWf11ٮhK,vs1gΜ ))T׹QVV ؇JV_{O#)MCŖ/۶lr)RF.D9+Q!iA~R IE{ Ddvc*ȇgW*&7ET,_T,Df,c*P3V_2PJZ)EqblRj| VZ_wfg )dW*XM~a F4g+7-ݟڜ/?s)˒,? KuJ mVzLb)DLYkv; 3V$EwpVE=^+vg5Ui=QS=D54BQ+Q&(T̯i[: !uM7{zԞ{r _1?lmFWà-^1ߣυeB1XZ|m:bUQc$V_{R#D_TV jrdLfVyj|7HerW٫1R<*Tb5U ;fjL$Pިd5Ui=(*Z_ru}u=~ѸVH vU^lc5UX+tZ7ۑp==>ָVHa+W|k$eeU1΅)Re7*'XM~eMf_Tz rcL_#o+R~m_lsl6j^>'N_7U?#3YJ{17UFOD#+]g5Ui=(jg4˽2_6ȭ1RE.aVyBʳ*gQ**wR| Cdg)*E j|zPTi*վ!2DUܪbnVy2W჊ڟ ~Dnh^|kGV*]blw!;tH[ x=*Uj{d]-+a=G͗ BFVyY*ߴ94_SyՈl5ڊܶS!ElRib5UFSyߐJe"ہ".*GRmcבeɯ.@*;4!"Q]Bnb'XNV_{gT,EA'\jAxvU^Ϡ7YM~oZIM퇊Ja/ۍ0S*\Y )?ȯqT,[Q;C*Ϡl"٦g)°AaV_փ2@SD6Q=2B+&Cw`.oWe.4N.7K=OoM].or.j&])X }~opO?wb\cw[&VYD(-F=RaKYUjy&7U4lBd>Ϙ )a/+fV_9@*T>3y;"s휋JQ[`ɪQo ɯ%@*5BEDvQu0S*8 ;/JYaV_*j{r5E{A6}OlO[ ->]ӻ?O:$Kտ# ,ܯǸSvQfqs\zuPۓwgDdp B   S A ?  2(D~azd4(qqcT`!D~azd4(qqS!`\x=KAgKNs~UE#(6&F $FTA,Hv;66zrLwn6XZr#[,B0 ef{df0RsѮ"OdB6'QDwbM&L:Ҹ0zQ^]>1z7b.@iMj5Q-;fG-“rs=~TNHj4>W, NyuXu#hϱ԰}A.ky,O]qŎ? o/1N{KD_'b= dfM}{$n/_)wU~KO+Ҝ~NOۙ4MJ󚗚v5HEg+%ϟܒh$%=D}A <]K~܇xDd B   S A ?  2렀*Svcg!W`!렀*Svcg@xKP.MӨ ҡ:" bAXAAUG]⢃SsGSM!$g0'Al!DA}_zƱOz& uPG7I ) 0+$˛G;A 2+*[ia]BߢR\ΩڪbPBh:kC[!KB})'UU3#p^0R:έ}U)A)haԜf1m晀xlobno2t܎) CUw-TP8oN]id;}Ir2x_"<gg `KFsA\ZM#f噐#B\ҍZ' #q}8Y`!0>Z' #q}@h $(+xKA߼Yyj!QȏJHa(xBUKH4t"e b\! Y.;k|~}no| ,(-ⴑV81YaEL~YD.ƾ~{j  "xO꘨(b\˕p 3 ܢr1,8Tz/~M<~v3jBeaIeF_W+_]f͢xP!s ғc21Yg >fPQ-oUţCQWi =l-fWO4շ Z2 v%M۳gkC`S'1?| Bk_ gl Ϲ:=>_gp3We+㯞v ?uo ?l-_|+busf'uܯߌNM6Mk פW^W柯~|ף]X'+دi"7_g>V%qKƸc[师y&!q~v~GFo O%o"fEE}\+rjmߠ|NB/udm***2xG%{=aT/z_g}>r\G?3W8 l~.qS>x^J+\>XE /Rx[U1 PoT? Tx9Ŏ&&| f;1ǫ1y:^]L.@9e'|D8َ[d?1øӎPVgBx/(>8SP( }G}}K }Ʊg)3> Jg|&!g*(>P8@O3~g P}ƷB)pgtW>(> &(Pn8g_o1[G}vԟ!smP&HںAcI"~~w*#x1PmeNwPNDNw@M'[R`sޭTۮ9uBMw[R`sV~z=#rI99NWŽW"rȩ?T,r5ŶNTH#r>Ӄ`ӃP3ؖÔ?4"퐈PN%"!PSbK tN%*C/1sc⌊3Jm$q#1Ns>҈JUG"rzr*9=5eNTW~yDNc9=F9M9=5mIiOij;9"ɔSi2Tؒ;SE4M}""'("'f-)9MWq9TmiʩR4Tڒ;S;WU9Us"rC99́N4_]ꈜUۅ9-B[R`sZ.W~MDN59=K99= 5+lIiFu9թ#rZM99uNN}^"rڠڮi=Ij6ْ;&o2scTq["m!n;-PÖin;TUv;#rI99턚ݶN[7ijJDNPN{EN@^[R`sګR"rڧھPsT7#rzr:$rzjْ;!W?aޡށ#NtDj^DNQN'DNA [R`s:#rjTm?9iK tN'UO*$]d2ζ }9wٗsg }9w^˹ug_Ν8rlٗsgξ;s˹Z/jξ;{V˹eg_Ν-8rlٗsgξ;8rLΝ/}9w6_˹yg_Ν8rJ˹9g_Ν6ǀ&sL d?M#"){)|(|*|‡*|G)T /Wx§(|§)|g*|«^jW+F5 Sx7(|·*|w)|(|)|ޠ ?c ?F7*;伴 _|n'ϷIs;iK]ZG 4]{Lo^?(hȏu%47j})L0SP^ >]F@e4 oԌo}BK♴`ì#?^׾xk񫂚y͆xMM:3i- `#?^sGYįjj[muuמ%Im_6>5i.~ϙZúm=m:? LM)i~oz[G~&E\ { j^E(h1jqImgnkȏdfuM0W ~XG~ &cr{sLM0ǔ]emXM]ꏤݶhm^&C=6w jw >k4`)ƇP5B͇mlCD>q..q sq1^c2 MwqyKyL.ZxljTz~%Vcm}q.22s ewg}.E i>-H8s>w>w!K[bm}qHzs߷g}.ޟݤ 5 e%?b"]cKw>wՀU[G~܄8sܹ/l}}>ϕI`}n [`m5.q}I`}6>nYa%涌wWj_Uc~U>4FQc%Lc~^W_>*~q_5\4G~ZP8bG1p_5CbxHs.a߯X?7oP;cj<4"G1ր2^4ԸaGUc~d>4.!Qc%LTWQj!>T WYx4i<.G90eJC1}TQ25\4cnD':}՘'O1$YJCOrSbjE·Ƹ5Ƶh̹i5s4x?-l|h~.s.aP}]4 ^?3||h\I/Qc%LYs+ 5>ˁwį1?c>#1@?Pz m:;x i*G90>ֿoBi|#~M W x}s.aT}m_4J.{x-i9G90wF6) 5@Q7}՘s%o"w1 oPjk WwQ9j̹i5ඌVj\4KƜKƿP}wPp}ո!'Qc%LcePz m!;ri|4G90R}Po9#cj̿1U0<4 Gc1p_5ṇIQc%LcePz m1>r.g. \mcT7>ގE죛1a2_&rbnY#BbNBbNƐsrH1ۇ,%!1cļYxH1{8bĽ{]?[Hq0V޷~kc&x;J.dNAy[&11!*Ǖc+!K:ⷳfu5a皯wA:o7<j5\WW{}500Fssן͌?c_z?:YfR'y]=vbBZkPF$.ߤ> u>^^C{ Ƈ977t9V`qb1)9^\; >'m`Y[k>/D0{u,! lǒO.#x8n|< V)X4&× c qa"_qCoY늡%^oL瘔u\Grmmcx~zT؇|5>_*3s3s |nKӱ>WpXcd"$zjXDf*VKZj qZt*V+XlǏl~9KzXט \Ê$>_$Ǭ.yy >c( U/%K c9\\kqf~̐ &:Amsg $r'6z9@LC^L=ۻֻ[ vc/:KeTok#~r5 1MT (yTF8ͱ{_M|aγ<6+M]?qXT\IuhwX&!׿,+IN+s%r˕dY*]N&pz~ ۨV yDnʖ lϹ瞨_?F?\~jsO' dI$.&/sC|>5~98ƽN l_7mz-| Ez&IHtW!뱄כ SP^C+~3³BaS?uIY_a%ef1<{E9UUU?U'TGTGTUUUUJUVUUUH_/TTHn;Xz:; ?!9Ym[xelv.xicӽj.5޴=¸iSp #x9G fNLw6`nw. ?]288X@e-"-yྟ{Kw܊:lF?/W ƎױG"+uBA~vҐNb_*;5=GL(A.8l\,$$}yͯoG!]wRT^{Jpv~oxX ͞_^tH:騮k= ytbnQquZb y8 l79إ Z6]39.3ɯopI'^Z#Ce~"A&8*)}3<TƼaT_og5Iblm=zmsGz OBGz!zY#L48K_NGWp$t.GWd<0$׷K/]_T3}J$j^ g ?_؅]Џy!T4])~([j[mms _yZԟ Ae~!i]>Dc@_vttEځjډ@2J~} W^dy%(~L퇓70q΄'Hr9i3~LcܶghzOP>r {,Hg{*Qᶹzx >b ]s;-zX^|.}(~_g3>?c}l tF_i JI7Sۺ̥[Y~(Óv#/!+xͯop/yl>[Jb/@ {G;ÆG#ØF %'LA[N)s==6(~!#S=:=$tH:9F}JgEI,+2y5l9ud~ jƠAzg\{/` _cmͯow,9p8Dc@_Ƃt:"@ 芌y^ہpNA eml%_+]/$'H3‡P LMq;0I>n33:mMA2ψ{w, =]Iã|$&a^C9Aͯow2sCΫy]>{ >q|<'}$ʡ@_&t6 JQ~y-,a pnsC,!g鹟׷KǗܯZpfgOp{oG; q#8 B9Aͯo4yfcOPf?2iߐ8=$tX_s Bz2Oځ4¼HfY[ɯop_f JḰk/lqBx 8_kF9Aͯo9%9( L_ H^lTÞE1DK/A:]v녙sj,kc+-^z!=6/BPڼSwa,>' &.C:ːn[n[S'uNp;v}%9F)6W;ǜ8(Ϝ7s_o9AŴ|Y-na|6z?xNQd+O?='W䳄61Oۍpފ@2s?ͯop90;{At/`GTS<~V7yGuNP[L),uTُ-%~iI‡l>vtttEځ4js*@2J~} BE5c=ޙqBY.+]^ۃs_oWJs}/w栜32~l# Sn (KWNGWza&;ż l9d~ t8=W+/%yS~_9އ39w39g39W39G39~ȹs$]Z^:-So'2jg5DsvZ@昺sL!Q>ՕhzCa44WbxxB4nAc 1h,Ac# 1hFC! 1hŠ34Yhbи)F4nAcqƒ4n6e[qe44pyi _R2-߫[K"@~|}@TmSuhLg{}o˜o3 Q[h}ܸ8lxn)A(|P?Hꠠz5RlVZz:e[HN)wݪ U*܋.˷-\: x8b*2~c XpW,ml7iimv6ohFe\å{ׯO#kB/'ee ȀZ!Z m؆VALosM?/٘Z()﹤iҠt0I&<e#1wAlcL~KkRk \d$q{q%oMf1}_He-7 >x G ۊ!ysLPgA'9rǃszU)/>s=j)Nηm(pַjoKʶG)y=r9م/ |?F\-Pl#xh}-pd'zqb{P]mlڄRƎiO-m.gRw~I.$mtϤ*e$>T&!RM MX 6Jل3`> NqB9Kr /F'vcĵ `z( TVj-W= q[{j s|gj$ .=cOw]FMyo{nܤ$F`ڡF&Ddb<  C A" 28˙oƀzr Ž@=j 28˙oƀzT`G7j'8 xQlGq&NjC)5Xi" I&qiL!NR(qKAIDL]BRUA)4@T`ɉFHT84Vd U*BKP fnon{Ώ4{|@#_~x@ۖޭy^9L؈n@XfU5Gh@@-m)7zC-0 V/PK4n1(C-5&25GzmiOU*5,܄fouLt&2|}PER05o݌t1著u#MWX:twk K;a7_<*7oo9Wqj[҈>71̹]w8۵kn:j7-=@^U^\^Q4ۭz4WI^ўQ+2MP˻p.?H >(|)o9k ǨG+1x.՛'Q35EF<9NE]tn[.#G/^[e,'dDNignԉXDO43I˦<@Vo2u E4NJp.0y}FgLL_|*F?ʟP只GUGT}>U~***aU~*FoUUFHwll58D8ǓgӸu%MWz,_9>_zbtYڷ&q=<3 bpӞG[)sΛ]fZAXpB<,~~a?,t~BjholkyCԮrv}'"+ms_mv~zL+r搝6!#ck]6pӞD.W?|kJIi8i+6z_m@[vȼ+ѷ=wNowJ落F!s4DxI+֞W!wrUpfx`/CrG/m_kmx'-~c8c-hlAodj R^"/Ѳ{2V >pk Daxqd>1p8?(E5Tߒ#i-^HJȐ&q&#gq&[6D{{ lleBBKCW{@8C U[Jy}DBmׄrׄ,똁 ocYLC$6rwᬩ=IL `&ms(kk?oZm?;?F`Y)f M*SmN'!'@MNbdk?X%2VE a\ד-fҷ~lo;T>f/pfr,ڊe~W ImKA~p >@:.'x-oh[O[}' >~)#4bSpӞ@(oA-Ne4?q$k8Ǒ #%Ԗ{ 8BUpfs#Lx6"@KWG@8&HgַR^"/Ѷt}a[Zĭfpv8,´gZ?{k?.um )S?{+:L@N>> k?~WDOͷ=lk,K5쵐]ި~mz^(cٞ7Љik[*])cU[%ZSbmٳF^J|I'Pm<+;{!;Wk?7*\Eߘ89wӈZ^"/Ѷz߭>du~DނD e^đf_ͨv~3ڃ׷e3cGҷ8đy½JY [669؊,xb\ᘪG U[Jy}DBVgAY.Ka]w^@| M\o;ӎv0жlm8XjBv1;˱2݃bڳuS[99 J+ַMfb6wOncO '̧ͩ4m=.1GF8B WәO-oh[OC6˳:?4=HM7ZXۭuotءi{`ohhFjCMSߣ:|>䕖/ u:=`Emogǫ y_ y*A8AznP0~2ׇ0hxphc3*SwTL+=h,$L~uj҈^wއ`j腇0 *> o7u p#[.}>m9f cD^UGU*Eʋ-=&_4Q"_]pW.h>eeN%NIF^ f{)l{Oi=Z?'pЋ+i(Hso@8>h_as'~b Be}J" E䳆WN%¥O yw:M@]JB/ 4G$ }* ok2gVy cB+y{98޸o{hI=C%JSummaryInformation(qMDocumentSummaryInformation8TCompObjhj#Fcast multicast file distribution:scas Jim Gemmellim  Normal.dot Jim Gemmell12 Microsoft Word 8.0e@vA@1>㼾@.uv@1>㼾"՜.+,D՜.+,X hp   Microsoftec #Fcast multicast file distribution: Title(RZ _PID_GUID _PID_HLINKSAN{56CD91A5-2309-11D2-BAD1-00E0291ABD56}A$L *http://www.iet.unipi.it/~luigi/softfec.psS%http://msdn.microsoft.com/scripting/B[)http://www.microsoft.com/com/activex.aspPc mailto:Jgemmell@microsoft.com)Rmailto:Schooler@cs.caltech.eduPcmailto:Jgemmell@microsoft.com& [(@(NormalxmH T@T Heading 1$ & F&<@&5CJKHOJQJnH N@N Heading 2$ & F&@&56CJOJQJnH RR Heading 3$$ & F&@&56B*OJQJhnH NN Heading 4$ & F&x@&56CJOJQJnH << Heading 5 & F&<@&CJ@@ Heading 6 & F&<@&6CJ@@ Heading 7 & F&<@&OJQJDD Heading 8 & F&<@& 6OJQJJ J Heading 9 & F&<@&56CJOJQJ<A@<Default Paragraph Font(U@( Hyperlink>*B*2B@2 Body Text $xnH 6@6 Footnote TextxnH 8&@!8Footnote ReferenceH*8O28AbstractxCJnH 2"@2Caption xx5nH ,@R,Header  !,/@b,ListhxnH DRrDBody Text Indent 2 xnH 2O2BibitemxnH $O$Citation68O8Code$@ CJOJQJ@>@@Title$<@&5CJ KHOJQJ4O4Abstract TitleCJ*O* Ref Heading, @,Footer  !&)@& Page Number8V@8FollowedHyperlink>*B* 8Y8 Document Map!-D OJQJ6'@!6Comment ReferenceCJ,@2, Comment Text#(L@B(Date $$CJ0O0Style1%@& CJOJQJ MBYkQt~֪]q ;d(^.:   ddddd(^^^^^:: qJim GrayqJGq!                "g([1(?IhT9V\Kck=zׅdz$q    I |c"H (s5JI TCZP]dh ms|#6Ib|q:MP[hi}?u$`6yoqy&Hgar?nqia 37P^r$$$%%%H)c)e),-!-c0{0}0000[1s1u1~111f777777:::;;;4?K?M?3EKETELLLOOO{QQQ]SSSqTTTxUUUBVYV[V W!W$WWWWWXXXXXXXXY)Y2Y8Y`YiYvZZZ\___````aabbbb ccddde f fgggdk{k~kL}d}n}À*BL14Ԕ#;=F]`$;>Ƨڧܧ]qsګ 1Yc}+c;oMg~F^hRilH_b>Y[.8-DGq'XXX'': t: t: :  t t:tt t   ttttt: t:t t: t: t: t: t: :::: t XXX       !!!`2$bP{;0"$28˙oƀzr 2$ j2 p "$Bp#yզ!"$XVuN;wZ]̱"$ O&EoXS$΁ĶX"$hYBq&d.d "$^xg̀T,U Q jB 0e0e     @  5% 8c8c     ?A)BCD|E||@0(  B S  ?qX _Ref440254743 _977298866 _977298926 _977299288 _Ref440356186 _977298886 _958224318 _958224506 _958224900 _975945372 _975945559 _975945803 _975945827 _975945925 _975945934 _975945958 _975945966 _975945972 _975946185 _975946292 _975946611 _975946677 _975946686 _976475245 _976475301 _Ref422796808 _958224574 _958224889 _958224926 _975946401 _975946717 _976475275 _976475319 _Hlt439071947 _Ref437408653 _Ref436467013 _Ref436467019 _Ref437389861 _Ref437058009 _Ref437846532 _Ref437846537 _Ref437058436 _Ref437846540 _972915818 _972915922 _972916570 _972916702 _974110887 _Ref437058894 _Ref437149562 _Ref440268038 _Ref437409379 _974198964 _974199523 _975952080 _975952145 _975952159 _986891213 _986891245 _Ref437753060 _974199195 _974199612 _975952709 _986891225 _991036495 _991036663 _Ref437753034 _974204936 _975953166 _990969705 _Ref437752929 _991023154 _Ref454152643 _Ref437835847 _Ref437835852 _Ref437835388 _Ref438965982cla90birman91chang84 crowcroft88flo95 _Hlt445021931pau97ram87 _Ref440444617 _Ref441462613 _Ref441462616g${0{0{0{0{0{0{0{0{0{0{0{0{0{0{0{0{0{0{00s1s1s1s1s1s1s17-?LLLjTqUqU;VW``````d]kk;;;?vm (tK&yr@@@@@@@ @ @ @ @ @@@@@@@@@@@@@@@@@@ @!"$#%&(')*+@,@-@.@/@01234@5@6@7@8@9@:@;<@=@>@?@@@A@BC@D@E@FG@HJIKLMNOPQRSTUVW${0{0{0{0{0{0{0{0{0{0{0{0{0{0{0{0{0{0{00s1s1s1s1s1s1s17N?LLLTU7V\V%W`````adkkĀ5;;;a?٫b  /{mHrj7_r$$%%H)f),"-c0~000[1v1~11f7777::;;4?N?3EUELLOO{QQ]SSqTTxUUBV\V W%WWWWXXXXXY3Y8YjYvZZ\__`abcddggdkkL}o}Ā*M5Ԕ#>Fa$?Ƨݧ]tګ 1d}%bb+;gFiRmHc>\:-H !!Z_#JJbf tuklorNQb msoqyz)+bd..001!1779!9;;M<S<<<E=G=BB1F8FKK`KgKcLeLrLLNNPPS-V.V\\P]V]kataKcNccccccc&d(dDdJdXdZdvd|dddee i iiili#j6jttttvvƀAC7U0Wȑ̑ %c%Ay LO/3]uxǩɩګV1oyOUn|ci'(x+!dg";r~RT>@AsQS `f~MQk+2*<H>D U` "QWbgr{ !%i#OPCH !ulorschooler&C:\TEMP\AutoRecovery save of Fcast.asdschooler"C:\Schooler\readings\Fcast.v23.docschooler&C:\TEMP\AutoRecovery save of Fcast.asdschooler"C:\Schooler\readings\Fcast.v23.docschooler"C:\Schooler\readings\Fcast.v23.docschooler"C:\Schooler\readings\Fcast.v23.docschooler"C:\Schooler\readings\Fcast.v23.docschooler"C:\Schooler\readings\Fcast.v24.doca-vtakaC:\infected\Fcast.v24.doc Jim GemmellC:\djg\Docs\FcastTR-99-14.doc%|O}m~nXc,h|o?o ;~># e AwW- 9d8X@ C~ i !5;5q8 V,!%  m! $! }5" K&`VcSI9vJ+7p=vJo? C[G $QJ 4{QH(dOqW IY (i =8Eu+^1Pw`Vc..88.. OJQJo( OJQJo( 88OJQJo( OJQJo(hh. hhOJQJo(P@@.0..``...  ....  .....  ...... `....... 00........*P@@.0..``...  ....  .....  ...... `....... 00........ OJQJo(hh. POJQJo(hh. hhOJQJo(hh.hhCJ(OJQJo(hh.P@@.0..``...  ....  .....  ...... `....... 00........ hhOJQJo( hhOJQJo(hh. hOJQJo( OJQJo( OJQJo( hhOJQJo(hho(. OJQJo( OJQJo(hh. hhOJQJo( hhOJQJo(0o(. hOJQJo(&C~-IY!5;(io?$!K&1Pw9d$QJ+7p=SI9{Q~}|C[G8 ei}5"q8=8EuOqWm!V,!D @CJ0OJQJo( @CJ(OJQJo(X%@q@@GTimes New Roman5Symbol3& Arial71Courier;Wingdings?5 Courier New5& zTahoma?& Arial Black"1h3f 6F 6F "c$0d