**5.1.2 Initial offset placement based on buffer width**

Instead of offset lag, a host can use *Wp*(*t*) for its initial offset placement, where peer *p* is its first neighbor. We name such a placement scheme as the PP scheme based on buffer width, i.e., *=fp*(*t*0)+*Wp*(*t*0). The advantage of this scheme is that, the initial chunk is always available in its neighbor peer. However, the system under this scheme may be not always stable, i.e., this scheme can't guarantee a bounded *offset lag Ln*=*s*(*t*)*fn*(*t*) as *n*. In theory, lemmas 1,2 and 3 in (Li & Chen, 2008a) give the offset lag's variant boundaries under certain assumed conditions in line with real situation. According to the lemmas, the measured *E(W)/r=*208.3, and the measured *placement coefficient =*0.34, then we can deduce the *offset setup time s*=70.82s. The deduced *<sup>s</sup>* is very close our measurement result. Hence, the placement scheme used in PPLive is stable.

## **5.2 The system design concerns based on the TB piecewise line model**

Recall the normalized piecewise line design model (Li & Chen, 2008b) of peer startup progress in PPLive. Assuming each stable peer has a offset curve *f*(*t*)=*t* and scope curve *(t)=s*(*t*)=*t*+*W\** ,when peer *p* arrives at time 0, he has to choose an *initial offset <sup>p</sup>* relative to a *neighbor's offset* equals as *p*=*<sup>s</sup>*, which has been confirmed in previous sections as both of them equal 70s. Besides, because the stable peer's buffer width *W\** is 210s, thus we see that *<sup>p</sup>* is just equal to *W\**/3.

Offset setup time *<sup>s</sup>* is roughly the startup latency and the buffer width *W\** is the playback lag to the seeder. Usually, people would like to use large buffers to ensure playback continuity. In our model, *p* is totally decided by *s*. So why do not people choose a smaller *s* for shorter startup latency? Smaller *s* leads to smaller *<sup>p</sup>*. A starting peer must ensure to download *p* within time *s*, otherwise, it will miss out it. Thus smaller *<sup>s</sup>* means larger download rate *p* requirement. In fact, for a given *<sup>s</sup>*, the minimal *p* required for fetching all initial *B* chunks (chunks ID from *<sup>p</sup>* to *p*+*B*-1) is about *rmin*=*B*/(*<sup>s</sup>* +*B*) since no one chunk can 110 Reverse Engineering – Recent Advances and Applications

width is an important design parameter involving playback performance. Larger buffer can improve playback continuity, but does no good to a tracker for consuming more memories. Thus, FP can't fulfill two design goals at same time: large buffer of peer but small buffer of

Let's consider a more practical scheme named as *proportional placement* (PP) *based on offset* 

neighbor's offset lag. Since the first neighbor must have been a new peer when it entered the system, we can refer to a very familiar formula *xn*+1=*bxn*+*c*, which is a contraction mapping when the Lipschitz condition satisfies *b*<1. One can easily concludes that such a system has a

, which is independent of any specific initial offset. Self-stabilizing is the most attractive property of *proportional placement* scheme. However, in certain extreme conditions, it may lead to a poor performance. For example, the first neighbor has an offset lag of *Lp*=1000 but only contains 50 chunks in his buffer. With a

Instead of offset lag, a host can use *Wp*(*t*) for its initial offset placement, where peer *p* is its first neighbor. We name such a placement scheme as the PP scheme based on buffer width,

available in its neighbor peer. However, the system under this scheme may be not always stable, i.e., this scheme can't guarantee a bounded *offset lag Ln*=*s*(*t*)*fn*(*t*) as *n*. In theory, lemmas 1,2 and 3 in (Li & Chen, 2008a) give the offset lag's variant boundaries under certain assumed conditions in line with real situation. According to the lemmas, the measured

Recall the normalized piecewise line design model (Li & Chen, 2008b) of peer startup progress in PPLive. Assuming each stable peer has a offset curve *f*(*t*)=*t* and scope curve

them equal 70s. Besides, because the stable peer's buffer width *W\** is 210s, thus we see that

lag to the seeder. Usually, people would like to use large buffers to ensure playback

*s* leads to smaller

*s*, otherwise, it will miss out it. Thus smaller

*p*+*B*-1) is about *rmin*=*B*/(

*Wp*(*t*0). The advantage of this scheme is that, the initial chunk is always

is constant placement coefficient less than 1, and *Lp* is the first

*h=fp*(*t*0)+300, and the host doesn't have any available

*<sup>s</sup>* is very close our measurement result. Hence, the

*<sup>s</sup>*, which has been confirmed in previous sections as both of

*s*. So why do not people choose a smaller

*<sup>s</sup>*, the minimal *p* required for fetching all

*<sup>p</sup>*. A starting peer must ensure to

*<sup>s</sup>* +*B*) since no one chunk can

*<sup>s</sup>* is roughly the startup latency and the buffer width *W\** is the playback

*=*0.34, then we can deduce the *offset* 

*<sup>p</sup>* relative to a

*<sup>s</sup>* means larger

*s*

*Wtk*. Buffer

One can easily find that all peers in such a system will have the same *offset lag L*

tracker.

*lag*, i.e.,

i.e., *=fp*(*t*0)+

*setup time* 

*neighbor's offset* equals as

*<sup>p</sup>* is just equal to *W\**/3.

continuity. In our model,

for shorter startup latency? Smaller

initial *B* chunks (chunks ID from

*p* within time

Offset setup time

download

*=fp*(*t*0)+

stable point *L*\*=*r*

placement coefficient

chunk for download.

*Lp*, where

*s*/ *=*0.3, the host's

**5.1.2 Initial offset placement based on buffer width** 

*E(W)/r=*208.3, and the measured *placement coefficient*

*p*=

download rate *p* requirement. In fact, for a given

*s*=70.82s. The deduced

placement scheme used in PPLive is stable.

**5.2 The system design concerns based on the TB piecewise line model** 

*(t)=s*(*t*)=*t*+*W\** ,when peer *p* arrives at time 0, he has to choose an *initial offset*

*p* is totally decided by

*<sup>p</sup>* to  survivor after *s+B* seconds. if one wants to decrease the *<sup>s</sup>* from 70s to 35s, the peer needs a faster *rmin* , which will impact the startup performance.

There is a physical explanation for the turnover threshold *csch*(*t*) in PPLive. We have *csch(t)=t+β for t≥<sup>s</sup>*, which happens to be *the seeder offset ftk*(*t*) (reported by tracker) since *ftk(t)=t+W\*-120=t+90=t+β.* Intuitionally, chunks below *ftk*(*t*) may can only be buffered by peers, but those above *ftk*(*t*) are cached by both seeder and peers. Designers would like to see a system where peer caches as many as useful chunks while seeder doesn't, and make use of stable peers' resources to help startup peers. Thus *β* has a lower limit as *β*≥90.

On the other side, let *vq*(*t*)=*Vq*(*t*)+*t* be the playable video of a neighbor peer *q*. All chunks below *vq*(*t*) are already fetched by peer *q* at time *t*, but chunk *vq(t)+1* definitely is not. If we set *csch*(*t*)>*vq*(*t*) and assume *q* is the only neighbor for host *p*, then after peer *p* gets chunk *vq*(*t*), he has to idly wait for peer *q* to fetch chunk *vq(t)+1* according to the TB protocol. If we design *csch*(*t*)*<vq*(*t*), peer *p* will not waste its time. Substituting model parameters into it, we have *β<Vq(t)+t-s*, for *0≤t<<sup>s</sup>*. If any possible download rates are considered, the right side of the inequality has a minimal value *Vq*(*t*)-*<sup>s</sup>*. If further assuming *Vq*(*t*) for any peer *q* has the same distribution with a mean *V*\* and stand deviation σ*V*, then we deduced another design rule (Li & Chen, 2010) for the upper limit of *β* as *β<V\*-*σ*V*-*s* for *0≤t<s*, where coefficient is introduced to guarantee the switch threshold is below the playable video of his neighbor with larger probability. Based on our measurement in PPLive, *V*\* is about 196 and σ*V* is about 18. For a threshold of 90, is 2. Through the discussion of system design considerations, we hope to support the claim that PPLive is a well-engineered system.

#### **5.3 VoD network sharing environment**

In P2P-based file sharing systems, the number of copies is an important indication to the availability of data blocks. We define the number of copies of chunk in the network at a given time *t* as *availability N(,t)*, which equals the number of online peers having this chunk at this time. Our statistics shows that chunks with larger IDs have less availability. Moreover, if we normalize *N(,t)* by the total number of online peers *N(t)*, or the total number of copies *C(t)=*Σ *N(,t)* at time t, then both the results of *(,t)= N(,t)/ N(t)*≈*()*  and *(,t)= N(,t)/C(t)*≈*()*, can be observed independent of time *t*. We named these normalized availabilities as the *sharing profile* (SP) *()*, and *sharing distribution* (SD) *()*. *()* is a probability distribution as ∑ *()=1*, while *()* is not. Both SP and SD are shown in Fig.15. In each subfigure there are 86 curves in light color, which correspond to*(,t)* or *(,t)* calculated at 1, 2, . . . ,86 minutes of our trace time. Clearly, all the light color curves in each subfigure are very similar. This indicates that the SP and SD are well defined in a practical P2P VoD system.

The user watching behavior will affect the network sharing environment, and an inherent connection does exist between user behavior and VoD network sharing, i.e. the SP and SD can be analytically deduced from the distribution of WI. The theorems 1 and 2 in (Li & Chen, 2010) further verify the time-invariant property of SP and SD. yIn Fig.15, the thick black curve is the result theorem 1 in (Li & Chen, 2010). Clearly, the thick curves match the measured light color curves quite well in all subfigures. Equation 3 in theorem 1 says that the average number of copies is related to the second moment of WI. It indicates that the diversity in users' behaviors can promote network sharing, and this provides twofold

Reverse Engineering the Peer to Peer Streaming Media System 113

behavior. With the help of measurable parameter of WI, we reveal that although majority peers are smoothers, jumpers tend to be the real valuable file-sharing contributor. On system level, the systematic problems and design concerns on performance, scalability and stability are discussed. Based on the live peer's startup models (PP models and piecewise line model of TB protocol) driven by our trace, we analyze P2P live system's design goals such as the large buffer in peer/small buffer in seeder and self-stability on offset lags, and confirm PPLive tends to really reach those goals. VoD network sharing environment is analyzed in terms of network sharing profile and sharing distribution, and we find the

In addition, we will further our study on following issues. We believe live peer chooses its initial offset base on good neighbour, but the evaluation principle of good peer is not answered; The playback rate change has been found in a system designed for CBR video. It needs to be analyzed whether the system can keep in good health when playing a VBR video and how to improve the performance. Besides, we will continue to study what have

Ali, S.; Mathur, A. & Zhang, H. (2006). Measurement of commercial peer-to-peer live video

Cheng, B.; Liu, X.Z.; Zhang, Z.Y. & Jin, H. (2007). A measurement study of a peer-to-peer

Hei, X.; Liang, C.; Liang,J.; Liu Y. & Ross ,K.W. (2007a). A measurement study of a large-

Hei, X.J.; Liu, Y. & Ross, K. (2007b). Inferring Network-Wide Quality in P2P Live Streaming

Huang, C.; Li, J. & Ross, K.W. (2007). Can internet video-on-demand be profitable?

Li, C.X. & Chen C.J. (2008b). Fetching Strategy in the Startup Stage of P2P Live Streaming Available from http://arxiv.org/ftp/arxiv/papers/0810/0810.2134.pdf Li, C.X. & Chen C.J. (2008a). Initial Offset Placement in P2P Live Streaming Systems

Li, C.X. & Chen C.J. (2009). Inferring Playback Rate and Rate Resets of P2P Video Streaming

Lou, D.F.; Mao, Y.Y. & Yeap T.H. (2007). The production of peer-to-peer video-streaming

*Post and Telecom.*, Vol.16, Issue 2, (April 2009), pp. 58-61, ISSN 1005-8885 Li, C.X. & Chen C.J. (2010). Measurement-based study on the relation between users'

*Networks*, Vol.54, Issue 1, (Jan. 2010), pp. 13-27, ISSN 1389-1286

346-351,ISBN 978-1-59593-789-6, Kyoto, Japan, 31 Aug. 2007

*Peer Systems (IPTPS'07),* Washington, USA, Feb. 26-27, 2007

Volume 9, Issue 8, (Dec. 2007), pp. 1672-1687, ISSN 1520-9210

http://arxiv.org/ftp/arxiv/papers/0810/0810.2063.pdf

streaming, *In Proceedings of ICST Workshop on Recent Advances in Peer-to-Peer* 

video-on-demand system, *Proceedings of the 6th International Workshop on Peer-to-*

scale P2P IPTV system, *Journal of IEEE Transactions on Multimedia*, Oct. 2007,

Systems, *IEEE Journal on Selected Areas in Communications*, Vol. 25, No. 10, (Dec.

*Proceedings of ACM Sigcomm 2007*. pp. 133-144, ISBN 978-1-59593-713-1, Kyoto,

Transmissions by Piecewise Line Envelope Approximation. *Journal of China Univ. of* 

watching behavior and network sharing in P2P VoD systems. *Journal of Computer* 

networks, *Proceedings of the 2007 workshop on Peer-to-peer streaming and IP-TV*, pp.

sharing environment is heavily affected by user viewing behavior.

changed in the continually updated systems.

*Streaming (2006),* Aug. 2006.

2007), pp. 1640-1654, ISSN : 0733-8716

Japan, 27-31 Aug., 2007

**7. References** 

insights: *i).* the system design should facilitate any kinds of viewing habits, such as watching from the middle, watching by skipping and even watching backward. *ii).* a movie should be designed to lure its viewers to present different behaviors, e.g., guiding viewers go to different sections by properly designed previews. In addition, the network sharing research based on the jumpers' WI has a similar result. In short, a good VoD system should be welldesigned on both protocols and contents to accommodate any kind of audience.

Fig. 15. Sharing profiles (SP) and sharing distributions (SD) in three channels

#### **6. Conclusion**

In this chapter, we presented the study of a P2P streaming media system at different levels of detail. The aim of the study is to illustrate different types of analyses and measurements which can be correlated to reverse-engineer, and further give guidelines to optimizing the behavior of such a system in practice. On signaling message level, we tell about our system crack procedure and reveal the protocol flow and message format. Following that, largescale measurements are carried out with our network crawlers and mass raw data is captured. On peer behavior level, the startup process of live peer is analyzed in two aspects including initial offset placement and chunk fetch strategies. We discover that the initial offset is the only decision factor to a peer's offset lag (playback delay), and the initial offset selection follows certain proportional placement models based on first neighbor's buffer width or offset lag in PPLive. Once the initial offset is determined, a peer downloads wanted chunks following a TB protocol, which can be depicted by a model of a bunch of piecewise lines. Our measurement proofs that in PPLive most live peers (more than 90%) have seemingly good performance. Moreover, VoD peer's behavior is discussed in user (person) behavior. With the help of measurable parameter of WI, we reveal that although majority peers are smoothers, jumpers tend to be the real valuable file-sharing contributor. On system level, the systematic problems and design concerns on performance, scalability and stability are discussed. Based on the live peer's startup models (PP models and piecewise line model of TB protocol) driven by our trace, we analyze P2P live system's design goals such as the large buffer in peer/small buffer in seeder and self-stability on offset lags, and confirm PPLive tends to really reach those goals. VoD network sharing environment is analyzed in terms of network sharing profile and sharing distribution, and we find the sharing environment is heavily affected by user viewing behavior.

In addition, we will further our study on following issues. We believe live peer chooses its initial offset base on good neighbour, but the evaluation principle of good peer is not answered; The playback rate change has been found in a system designed for CBR video. It needs to be analyzed whether the system can keep in good health when playing a VBR video and how to improve the performance. Besides, we will continue to study what have changed in the continually updated systems.

#### **7. References**

112 Reverse Engineering – Recent Advances and Applications

insights: *i).* the system design should facilitate any kinds of viewing habits, such as watching from the middle, watching by skipping and even watching backward. *ii).* a movie should be designed to lure its viewers to present different behaviors, e.g., guiding viewers go to different sections by properly designed previews. In addition, the network sharing research based on the jumpers' WI has a similar result. In short, a good VoD system should be well-

designed on both protocols and contents to accommodate any kind of audience.

Fig. 15. Sharing profiles (SP) and sharing distributions (SD) in three channels

In this chapter, we presented the study of a P2P streaming media system at different levels of detail. The aim of the study is to illustrate different types of analyses and measurements which can be correlated to reverse-engineer, and further give guidelines to optimizing the behavior of such a system in practice. On signaling message level, we tell about our system crack procedure and reveal the protocol flow and message format. Following that, largescale measurements are carried out with our network crawlers and mass raw data is captured. On peer behavior level, the startup process of live peer is analyzed in two aspects including initial offset placement and chunk fetch strategies. We discover that the initial offset is the only decision factor to a peer's offset lag (playback delay), and the initial offset selection follows certain proportional placement models based on first neighbor's buffer width or offset lag in PPLive. Once the initial offset is determined, a peer downloads wanted chunks following a TB protocol, which can be depicted by a model of a bunch of piecewise lines. Our measurement proofs that in PPLive most live peers (more than 90%) have seemingly good performance. Moreover, VoD peer's behavior is discussed in user (person)

**6. Conclusion** 


**Part 2** 

**Reverse Engineering Shapes** 


**Part 2** 

**Reverse Engineering Shapes** 

114 Reverse Engineering – Recent Advances and Applications

Small, T.; Liang, B. & Li, B. (2006). Scaling laws and tradeoffs of peer-to-peer live multimedia

Tu, Y.C.; Sun, J.Z.; Hefeeda, M. & Prabhakar, S. (2005). An analytical study of peer-to-peer

*Communications, and Applications,* Vol.1, Issue 4, (Nov. 2005), ISSN 1551-6857 Vlavianos,A.; Iliofotou,M.; Faloutsos,M. & Faloutsos, M. (2006). BiToS: Enhancing BitTorrent

Vu, L.; Gupta, I.; Liang, J. & Nahrstedt, K. (2006). Mapping the PPLive Network: Studying the Impacts of Media Streaming on P2P Overlays, *UIUC Tech report*, August 2006 Xu, D.Y.; Chai, H.K.; Rosenberg, C. & Kulkarni, S. (2003). Analysis of a Hybrid Architecture

*Multimedia Computing and Networking (MMCN'03)*, San Jose, CA, Jan. 2003. Yu, H.L.; Zheng, D.D.; Zhao, B.Y. & Zheng, W.M. (2006). Understanding user behavior in

Zhang, L.; Liu, Z. & Xia, C.H. (2002). Clock Synchronization Algorithms for Network

Zhang, X.;Liu, J.;Li, B. & Yum, T.-S.P. (2005). Coolstreaming/donet: A data-driven overlay

Zhou,Y.P.; Chiu, D.M. & Lui, J.C.S. (2007). A Simple Model for Analyzing P2P Streaming

3, pp.2102-2111, ISBN 0743-166X, Miami, FL, USA, 13-17 March 2005 Zheng, C.X.; Shen, G.B. & Li, S.P. (2005). Distributed pre-fetching scheme for random seek

Santa Barbara, CA, USA, 23-27 Oct. 2006

0743-166X, Barcelona, 23-29 April 2006

59593-322-0 Leuven,Belgium, April 18-21, 2006.

7803-7477-0, New York, USA, June 23-27, 2002,

ISBN 978-1-4244-1588-5, Beijing, China,5 Nov. 2007

59593-248-8, Singapore, Nov. 11, 2005

streaming. Proceedings of ACM Multimedia 2006, pp.539-548, ISBN 1595934472,

media streaming systems, *Journal of ACM Transactions on Multimedia Computing,* 

for Supporting Streaming Applications, *Proceedings of INFOCOM 2006*, pp.1-6, ISSN

for Cost-Effective Streaming Media Distribution, *Proceedings SPIE/ACM Conf. on* 

large-scale video-on-demand systems, *Proceedings of the 1st ACM SIGOPS/EuroSys European Conference on Computer Systems 2006 (Eurosys'06)*, pp. 333-344, ISBN 1-

Measurements, *Proceedings of the IEEE INFOCOM 2002*, Vol.1, pp. 160-169, ISBN 0-

network for Peer-to-Peer live media streaming,. *Proceedings of INFOCOM 2005*, vol.

support in peer-to-peer streaming applications, *Proceedings of the ACM Workshop on Advances in Peer-to-Peer Multimedia Streaming (P2PMMS'05)*, pp. 29-38, ISBN 1-

Protocols, *Proceedings of international conference on network procotols 2007*,pp.226–235,

**0**

**6**

*Germany*

**Surface Reconstruction from Unorganized 3D Point Clouds**

<sup>1</sup>*University of Kaiserslautern*

<sup>3</sup>*University of Kaiserslautern*

<sup>2</sup>*University of Applied Sciences Bremen*

Patric Keller1, Martin Hering-Bertram2 and Hans Hagen<sup>3</sup>

Computer-based surface models are indispensable in several fields of science and engineering. For example, the design and manufacturing of vehicles, such as cars and aircrafts, would not be possible without sophisticated CAD and simulation tools predicting the behavior of the product. On the other hand, designers often do not like working on virtual models, though sophisticated tools, like immersive VR-environments are available. Hence, a designer may produce a physical prototype made from materials of his choice that can be easily assembled and shaped like clay models. Reverse engineering is the process of reconstructing digital representations from physical models. The overall reverse-engineering framework mainly is composed of four steps (see Figure 1): data acquisition, pre-processing, surface reconstruction,

The point cloud acquisition generally is performed by stationary scanning devices, like laser-range or computer-tomography scanners. In the case of a 3D laser scanner, the surface is sampled by one or more laser beams. The distance to the surface is typically measured by the time delay or by the reflection angle of the beam. After taking multiple scans from various sides or by rotating the object, the sampled points are combined into a single point cloud, from

Pre-processing of the data may be necessary, due to sampling errors, varying sampling density, and registration errors. Regions covered by multiple scans, for example, may result in noisy surfaces since tangential distances between nearest samples may be much smaller than the sampling error orthogonal to the surface. In this case, it is necessary to remove redundant points introduced by combining different points from multiple scans. In other regions, the density may be lower due to cavities and highly non-orthogonal scanning. If additional information, like a parametrization originating from each scan is available, interpolation can

In the present chapter, a powerful algorithm for multi-resolution surface extraction and -fairing, based on hybrid-meshes Guskov et al. (2002), from unorganized 3D point clouds is proposed (cf. Keller et al. (2005) and Keller et al. (2007)). The method uses an octree-based voxel hierarchy computed from the original points in an initial *hierarchical space partitioning* (HSP) process. At each octree level, the *hybrid mesh wrapping* (HMW) extracts the outer

**1. Introduction**

and post-processing;

be used to fill these gaps.

which the surface needs to be reconstructed.
