DocuSign Envelope ID: 28821 B90-467D-42DD-87AC-3C58569FA723
`
`• IEEE
`
`Advancing Technology
`for Humanity
`
`DECLARATION OF GORDON MACPHERSON
`
`I, Gordon MacPherson, am over twenty-one (21) years of age. I have never been
`convicted of a felony, and I am fully competent to make this declaration. I declare the following
`to be true to the best of my knowledge, information and belief:
`
`1.
`
`I am Director Board Governance & IP Operations of The Institute of Electrical and
`Electronics Engineers, Incorporated (“IEEE”).
`
`2.
`
`IEEE is a neutral third party in this dispute.
`
`3.
`
`I am not being compensated for this declaration and IEEE is only being reimbursed
`for the cost of the article I am certifying.
`
`4. Among my responsibilities as Director Board Governance & IP Operations, I act as a
`custodian of certain records for IEEE.
`
`5.
`
`I make this declaration based on my personal knowledge and information contained
`in the business records of IEEE.
`
`6. As part of its ordinary course of business, IEEE publishes and makes available
`technical articles and standards. These publications are made available for public
`download through the IEEE digital library, IEEE Xplore.
`
`7.
`
`It is the regular practice of IEEE to publish articles and other writings including
`article abstracts and make them available to the public through IEEE Xplore. IEEE
`maintains copies of publications in the ordinary course of its regularly conducted
`activities.
`
`8. The article below has been attached as Exhibit A to this declaration:
`
`A. Ali E. El-Desoky; Hisham A. Ali; Abdulrahman A. Azab, “A Pure Peer-
`To-Peer Desktop Grid framework with efficient fault tolerance”, published
`in 2007 International Conference on Computer Engineering & Systems,
`November 27 – 29, 2007.
`
`9.
`
`I obtained a copy of Exhibit A through IEEE Xplore, where it is maintained in the
`ordinary course of IEEE’s business. Exhibit A is a true and correct copy of the
`Exhibit, as it existed on or about August 10, 2021.
`
`445 Hoes Lane Piscataway, NJ 08854
`
`Netflix, Inc. - Ex. 1025, Page 000001
`IPR2022-00322 (Netflix, Inc. v. CA, Inc.)
`
`

`

`DocuSign Envelope ID: 28821 B90-467D-42DD-87AC-3C58569FA723
`
`10. The article and abstract from IEEE Xplore show the date of publication. IEEE
`Xplore populates this information using the metadata associated with the publication.
`
`11. Ali E. El-Desoky; Hisham A. Ali; Abdulrahman A. Azab, “A Pure Peer-To-Peer
`Desktop Grid framework with efficient fault tolerance” was published in the 2007
`International Conference on Computer Engineering & Systems. The 2007
`International Conference on Computer Engineering & Systems was held from
`November 27 – 29, 2007. Copies of this publication was made available no later than
`the last day of the conference. The article is currently available for public download
`from the IEEE digital library, IEEE Xplore.
`
`12. I hereby declare that all statements made herein of my own knowledge are true and
`that all statements made on information and belief are believed to be true, and further
`that these statements were made with the knowledge that willful false statements and
`the like are punishable by fine or imprisonment, or both, under 18 U.S.C. § 1001.
`
`I declare under penalty of perjury that the foregoing statements are true and correct.
`DocuSigned by:
`
`Executed on:
`
`8/12/2021
`
`bfJVJlt>1& fu_odknb1&
`
`E768DB210F4E4EF ...
`
`Netflix, Inc. - Ex. 1025, Page 000002
`
`

`

`DocuSign Envelope ID: 28821 B90-467D-42DD-87AC-3C58569FA723
`
`EXHIBIT A
`
`Netflix, Inc. - Ex. 1025, Page 000003
`
`

`

`8/10/2021
`
`A Pure Peer-To-Peer Desktop Grid framework with efficient fault tolerance I IEEE Conference Publication I IEEE Xplore
`
`IEEE.org
`
`---
`
`IEEE Xplore
`
`IEEE-SA
`
`IEEE Spectrum More Sites
`
`SUBSCRIBE
`
`SUBSCRIBECart Create Account
`
`Personal Sign In +J
`
`Browse v My Settings v Help v
`
`Institutional Sign In
`
`Institutional Sign In
`
`All
`
`ADVANCED SEARCH
`
`Conferences > 2007 International Conference... @
`
`A Pure Peer-To-Peer Desktop Grid framework with efficient fault
`tolerance
`
`Publisher: IEEE
`
`I CiteThis I
`
`~ PDF
`
`More Like This
`
`ANG-based searching and
`broadcasting algorithms over
`Internet graphs and peer-to-peer
`computing systems
`The 3rd ACS/IEEE International
`Conference onComputer Systems
`and Applications, 2005.
`Published: 2005
`
`LMST-based searching and
`broadcasting algorithms over
`Internet graphs and peer-to-peer
`computing systems
`2007 IEEE International
`Conference on Signal Processing
`and Communications
`Published: 2007
`
`Show More
`
`Ali E. EI-Desoky ; Hisham A. Ali ; Abdulrahman A. Azab All Authors
`
`15
`Paper
`Citations
`
`128
`Full
`Text Views
`
`Abstract
`
`Document Sections
`
`Downl
`PDF
`
`O<©~ •
`Alerts
`
`Manage Content Alerts
`
`Add to Citation Alerts
`
`I. Introduction
`
`II. System Model
`
`Ill. Interaction
`between Client
`and Worker(s)
`
`IV. Client and
`Worker
`Architecture
`
`V. Performance
`Evaluation
`
`Show Full OuUine •
`
`Authors
`
`Figures
`
`References
`
`Abstract:P2P computing is the sharing of computer resources by direct exchange. P2P
`desktop grid is a P2P computing environment with desktop resources and usually built
`on the Int... View more
`(cid:141) Metadata
`Abstract:
`P2P computing is the sharing of computer resources by direct exchange. P2P desktop
`grid is a P2P computing environment with desktop resources and usually built on the
`Internet infrastructure. The most important challenges for a P2P desktop grid involve: 1)
`minimizing reliance on central servers to achieve decentralization, 2) providing
`interoperability with other platforms, 3) providing interaction methodologies between grid
`nodes that overcome connectivity problems in the Internet environment, and 4)
`providing efficient fault tolerance to maintain performance with frequent faults. The main
`objective of this paper is to introduce a pure P2P desktop grid framework that built on
`Microsoft's .Net technology. The proposed framework composed of the following
`components, 1) a communication protocol based on both FTP and HTTP, for interaction
`between grid nodes to provide interoperability, 2) An efficient checkpointing approach to
`provide fault tolerance, and 3) Four interaction models for implementing connectivity for
`both serial and parallel execution. No reliance on central servers involved in the
`
`https://ieeexplore.ieee.org/documenU4447070
`
`1/3
`
`Netflix, Inc. - Ex. 1025, Page 000004
`
`

`

`8/10/2021
`
`Citations
`
`Keywords
`
`Metrics
`
`More Like This
`
`Footnotes
`
`A Pure Peer-To-Peer Desktop Grid framework with efficient fault tolerance I IEEE Conference Publication I IEEE Xplore
`framework. Such framework will help in overcoming the problems associated to
`decentralization, interoperability, connectivity and fault tolerance. Performance
`evaluation has been implemented by running an application code built on variable
`dimensions' matrix multiplication on a desktop grid based on the proposed framework.
`Performed experiments have been focused on measuring the impact of failures on the
`execution time for different connectivity models. Experimental results show that using
`the proposed framework as an infrastructure for running distributed applications has a
`great impact on improving fault tolerance, beside achieving full decentralization,
`interoperability and solving connectivity problems.
`
`Published in: 2007 International Conference on Computer Engineering & Systems
`
`Date of Conference: 27-29 Nov. 2007
`
`INSPEC Accession Number: 9833156
`
`Date Added to IEEE Xplore: 07 February DOI: 10.1109/ICCES.2007.4447070
`2008
`
`Publisher: IEEE
`
`Print ISBN:978-1-4244-1365-2
`
`Conference Location: Cairo, Egypt
`
`:_ Contents
`
`I. Introduction
`The world's computing power and disk space is no longer primarily
`concentrated in supercomputer centers and machine rooms. Instead it is
`distributed in hundreds of millions of personal desktop and mobile
`computer systems be ono.inQ to ~he_gen~ral 1WblicJ&,I· characteristic of
`S1QT1 in o l,.,l)(cid:143) tinue·Reaa1t'l
`.
`.
`these systems 1s that he are re at1vel resource n
`terms of CPU
`I
`power, memory, and disk capacity) but are utilized only for a fraction of
`the time during a day. Even during the time they are in use, their
`average utilization is much less than their peak capacity [1 ].
`
`Authors
`
`Figures
`
`References
`
`Citations
`
`Keywords
`
`Metrics
`
`Footnotes
`
`V
`
`V
`
`V
`
`V
`
`V
`
`V
`
`V
`
`IEEE Personal Account
`
`Purchase Details
`
`Profile Information
`
`Need Help?
`
`CHANGEUSERNAME/PASSWORD
`
`PAYMENT OPTIONS
`
`COMMUNICATIONS PREFERENCES
`
`US & CANADA: +1 800 678 4333
`
`VIEW PURCHASED DOCUMENTS
`
`PROFESSION AND EDUCATION
`
`WORLDWIDE: +1 732 981 0060
`
`TECHNICAL INTERESTS
`
`CONTACT & SUPPORT
`
`https://ieeexplore.ieee.org/documenU4447070
`
`Follow
`f in "#
`
`2/3
`
`Netflix, Inc. - Ex. 1025, Page 000005
`
`

`

`8/10/2021
`
`A Pure Peer-To-Peer Desktop Grid framework with efficient fault tolerance I IEEE Conference Publication I IEEE Xplore
`
`About IEEE Xplore I Contact Us I Help I Accessibility I Terms of Use I Nondiscrimination Policy I IEEE Ethics Reporting ~ I Sitemap I Privacy & Opting Out of Cookies
`A not-for-profit organization, IEEE is the wor1d's largest technical professional organization dedicated to advancing technology for the benefit of humanity.
`
`© Copyright 2021 IEEE - All rights reserved. Use of this web site signifies your agreement to the terms and conditions.
`
`IEEE Account
`
`Purchase Details
`
`Profile Information
`
`Need Help?
`
`» Change Username/Password
`
`» Payment Options
`
`» Communications Preferences
`
`» US & Canada: +1800678 4333
`
`» Update Address
`
`» Order History
`
`» Profession and Education
`
`» Worldwide: +1732981 0060
`
`» View Purchased Documents
`
`» Technical Interests
`
`» Contact & Support
`
`About IEEE Xplore I Contact Us I Help I Accessibility I Terms of Use I Nondiscrimination Policy I Sitemap I Privacy & Opting Out of Cookies
`
`A not-for-profit organization, IEEE is the wor1d's largest technical professional organization dedicated to advancing technology for the benefit of humanity.
`© Copyright 2021 IEEE - All rights reserved. Use of this web site signifies your agreement to the terms and conditions.
`
`https://ieeexplore.ieee.org/documenU4447070
`
`3/3
`
`Netflix, Inc. - Ex. 1025, Page 000006
`
`

`

`A Pure Peer-to-Peer Desktop Grid Framework with
`Efficient Fault Tolerance
`
`Ali E. El-Desoky
`Dept. of Computer Engineering
`Mansoura University, Egypt
`
`Hisham A. Ali
`Dept. of Computer Engineering
`Mansoura University, Egypt
`h_arafat_ali@mans.edu.eg
`
`Abdulrahman A. Azab
`Dept. of Computer Engineering
`Mansoura University, Egypt
`aazab@mans.edu.eg
`
`
`
`Abstract- P2P computing
`is the sharing of computer
`resources by direct exchange. P2P Desktop Grid is a P2P
`computing environment with Desktop resources and usually
`built on the Internet infrastructure. The most important
`challenges for a P2P Desktop Grid involve: 1) minimizing
`reliance on central servers to achieve decentralization, 2)
`providing interoperability with other platforms, 3) providing
`interaction methodologies between grid nodes that overcome
`connectivity problems in the Internet environment, and 4)
`providing efficient fault tolerance to maintain performance with
`frequent faults. The main objective of this paper is to introduce
`a Pure P2P Desktop Grid
`framework
`that built on
`Microsoft's .Net technology. The proposed framework composed
`of the following components, 1) a communication protocol based
`on both FTP and HTTP, for interaction between grid nodes to
`provide Interoperability, 2) An efficient checkpointing approach
`to provide fault tolerance, and 3) Four interaction models for
`implementing connectivity for both serial and parallel execution.
`No reliance on central servers involved in the framework. Such
`framework will help in overcoming the problems associated to
`Decentralization,
`Interoperability, Connectivity and
`fault
`tolerance. Performance evaluation has been implemented by
`running an application code built on variable dimensions'
`matrix multiplication on a Desktop Grid based on the proposed
`framework. Performed experiments have been focused on
`measuring the impact of failures on the execution time for
`different connectivity models. Experimental results show that
`using the proposed framework as an infrastructure for running
`distributed applications has a great impact on improving fault
`tolerance, beside achieving full decentralization, Interoperability
`and solving connectivity problems.
`
`INTRODUCTION
`I.
`The world's computing power and disk space is no longer
`primarily concentrated in supercomputer centers and machine
`rooms. Instead it is distributed in hundreds of millions of
`personal desktop and mobile computer systems belonging to
`the general public [6]. A characteristic of these systems is
`that they are relatively resource rich (in terms of CPU power,
`memory, and disk capacity) but are utilized only for a
`fraction of the time during a day. Even during the time they
`are in use, their average utilization is much less than their
`peak capacity [1].
`A Desktop Grid*
`the Internet
`is usually built on
`infrastructure
`in which resources are unreliable and
`frequently turned off or disconnected [2]. The idea of desktop
`grid is to harvest the idle time of Internet connected
`computers, to run very large and distributed applications [3].
`The aim of the researchers in the field of Desktop Grid was
`that anyone could offer resources for a Grid system, and
`anyone can claim resources dynamically, according to the
`actual needs, in order to solve a computationally intensive
`
`* The usage of the concept "Desktop Grid" in this paper refers to:
`Computational Desktop Grid.
`
`task [4]. To achieve this twofold aim, two trends are involved
`in the development and research fields of Desktop Grid.
`Researchers and developers in the first trend consider a
`Desktop Grid as a Global Computing environment. The key
`idea of Global Computing is to harvest the idle time of
`Internet connected computers (e.g. Desktops) which may be
`widely distributed across the world, to run a very large and
`distributed application
`[3].
`In a Global Computing
`environment, resources (i.e. Desktops) can be involved into
`the Grid system as working volunteer nodes for the common
`goal of that Grid. Nonetheless, only one or few nodes (i.e.
`centralized servers) can benefit from those resources for
`computation [4]. This model is also known as Volunteer
`Computing [5]. BOINK [6], SZTAKI [4], and XtremWeb [3]
`are popular Global Computing solutions.
`In the other trend, a Desktop Grid is considered as a P2P
`(i.e. peer-to-peer) computing environment [7], where each
`node acts as a peer, so that, it can act as a resource provider
`(i.e. Grid Worker) or as a resource consumer (i.e. Grid
`Client). P2P Desktop Grid can be defined as: "P2P computing
`environment built on Desktop resources". In P2P computing
`environment, execution of both simple serial and large
`parallel applications can be carried out. A serial application
`needs a single Grid thread [8] to run on a single worker. In a
`parallel application, the task is partitioned into multiple Grid
`threads to run on multiple workers in parallel fashion. To the
`best of our knowledge, Condor [9], Alchemi [8], Harmony
`[1], Entropia2000 (Internet version of Entropia) [10] and
`some implementations of XtremWeb [3] are the most
`efficient P2P Computing solutions.
`In this work, P2P computing trend is being focused on.
`Decentralization, Interoperability, Connectivity and fault
`tolerance are important issues to be addressed in peer-to-peer
`computing [2, 3].
`
`Decentralization
`To achieve decentralization, reliance on central servers can
`be completely eliminated, what so called: "pure P2P
`computing" model, or minimized to performing required
`functions, what so called: "hybrid P2P computing" model
`[11]. To the best of our knowledge, all of the existing
`solutions implement hybrid P2P computing.
`
`Interoperability
`To achieve Interoperability, it must be able for a peer node
`in a specific P2P Desktop Grid to interact with peers in other
`P2P Desktop Grids which are built on different Grid
`platforms (i.e. cross platform integration), [8]. In Alchemi
`and recently, in Condor [12] Cross-platform interaction is
`enabled,
`through XML web
`service,
`to
`support
`communication with any Grid platform that supports web
`
`Authorized licensed use limited to: IEEE Publications Operations Staff. Downloaded on August 10,2021 at 20:55:08 UTC from IEEE Xplore. Restrictions apply.
`
`Netflix, Inc. - Ex. 1025, Page 000007
`
`

`

`services. In other solutions, cross-platform integration is not
`supported or enabled only with other specific platforms
`according to some contract or agreement.
`
`Connectivity
`As Desktop Grids are usually built on the Internet
`infrastructure, firewalls may block incoming requests from a
`Grid client located outside of the local network of a Grid
`worker. This problem can be solved by selecting the suitable
`interaction mode between clients and workers. There are two
`possible modes for such interaction: Push mode, where the
`client can send work to the worker and Pull mode and, where
`the worker can ask for work from the client [2]. Pull mode
`can be applicable in the Internet environment where all
`connections are initiated by the worker. In Condor and
`Harmony, implement push mode. While in Entropia2000,
`XtremWeb implement pull mode. Alchemi implement both
`push and pull modes. In the three previous groups, interaction
`(i.e. push/pull mode) is not implemented directly between a
`Client and a Worker. It is done across other management
`nodes (e.g. servers), as all of the previous solutions are built
`on the hybrid P2P model.
`
`Fault tolerance
`A fault-tolerant Grid model must accept very frequent
`faults while maintaining performance [3]. This can be
`implemented in P2P Desktop Grid model through providing
`the ability for system to continue working with frequent
`failures of peers. A common method for ensuring task
`execution progress on Worker peers is to checkpoint
`periodically its state, so that, in case of a failure, the
`application can be rolled back and restarted on another
`Worker from its last checkpoint [13]. If there is no support
`for checkpointing, the application will restart execution from
`scratch. There are
`two
`fundamental
`checkpointing
`approaches: (1) System-level checkpointing (SLC), (2)
`Application-level checkpointing (ALC) [14]. In SLC, the
`whole application's system state is captured and saved, while
`in ALC, only the critical program variables and data
`structures are saved. ALC can be implemented as full or
`incremental checkpointing. In incremental ALC, at each
`checkpoint, only that part of the application's state is saved
`that has changed since the previous checkpoint, instead of
`saving all checkpoint data (i.e. in full ALC) [16]. This would
`considerably reduce the checkpoint file size, so that, it can be
`transmitted between nodes on the Internet. In P2P Desktop
`Grid environment, the checkpoint data can be saved at the
`Client, the worker, or at a dedicated server [2]. It can also be
`partitioned and distributed on a number of peers [15].
`Condor implements full ALC, and the checkpoint data can
`be saved at the worker or on a checkpoint server. Harmony
`implements full SLC [1] storing checkpoint data locally at the
`Worker. No checkpointing approach
`is provided by
`XtremWeb package, Entropia2000 or Alchemi.
`From the previous discussion, it is clear that although,
`several techniques had been developed concerning previous
`issues and they are quite successful, there still remain lacks to
`achieve
`the promised performance especially
`in fault
`tolerance and decentralization. None of them implemented
`incremental checkpointing. This simply will prevent using
`
`their checkpointing approaches on the Internet. None of them
`implemented full decentralization. Interoperability is rarely
`implemented. In this paper, a novel pure P2P Desktop Grid
`framework is proposed, where, decentralization is completely
`achieved.
`Interoperability
`is achieved by providing
`communication through XML web service. An efficient fault-
`tolerance technique is provided through implementing an
`incremental ALC approach [16].
`II. SYSTEM MODEL
`The proposed framework is designed for building a pure
`P2P Desktop Grid system for resolving both serial and
`parallel applications. Two major components are involved:
`The Worker (W), which is responsible for task execution, and
`the Client (C), which is responsible for task allocation and
`task submission to a suitable worker, in case of serial task
`execution, or the suitable workers, in case of parallel task
`execution. A Grid node (i.e. peer) will have both client and
`worker components installed and can act as a client or as a
`worker. The proposed model is presented in Fig.1.
`
`Peer
`
`Peer
`
`Peer
`
`Peer
`
`Peer
`
`Peer
`
`
`
`Peer
`Peer
`Figure 1. Pure P2P Desktop Grid model
`
`
`As shown in Fig. 1, the P2P model is unstructured. Any
`message from a Grid node to all other nodes will be sent
`through broadcasting. Using broadcasting, as the number of
`nodes increases, network traffic will increase with a large
`scale. This may limit the scalability of the system. In our
`future work, a structured P2P model with efficient routing
`algorithm will be implemented to overcome this problem.
`Each node periodically sends IamAlive messages to all
`other nodes (through broadcasting). A timeout mechanism is
`used to specify which nodes are failed. To register a new
`node in the Grid, this can be performed from any existing (i.e.
`registered) Grid node. Once a new node is registered, the
`node in which the registration has been performed sends
`registration information (e.g. Node ID) of the new node to all
`existing nodes (through broadcasting). Each node will store
`information about all registered nodes.
`III. INTERACTION BETWEEN CLIENT AND WORKER(S)
`In our recent paper, Ref. [2], a fault-tolerant remote task
`execution model based on incremental ALC using four
`approaches: FCST, FCMT, ICST, and ICMT, has been
`presented. The most efficient one is ICMT (Incremental
`Checkpointing with a Multiple Threaded Process). Two
`
`Authorized licensed use limited to: IEEE Publications Operations Staff. Downloaded on August 10,2021 at 20:55:08 UTC from IEEE Xplore . Restrictions apply.
`
`Netflix, Inc. - Ex. 1025, Page 000008
`
`

`

`modifications have been made to that previous model
`version, presented in Ref. [2]. First, this version is pure P2P,
`while the previous version has been built with reliance on a
`directory server (i.e. hybrid P2P). Second, in this version,
`during task execution, the worker periodically sends the
`checkpoint to the client, while in the previous version; the
`client has been responsible for periodically capturing the
`checkpoint file from the worker. Four interaction modes can
`be implemented based on the task execution model: Push
`mode for Serial execution (PsS), Pull mode for Serial
`execution (PlS), Push mode for Parallel execution (PsP), and
`Pull mode for Parallel execution (PlP) (see section I). These
`modes can be implemented through four algorithms, which
`steps are described in the following subsections, A - D. The
`aim of each algorithm is to carryout the execution of one of
`the two application types (i.e. serial and parallel), using one
`of the two interaction modes (i.e. push and pull).
`A. Push mode for serial execution (PsS) Algorithm
`When a client (C) has a task (T) to be executed, the
`following steps are included:
`1. C sends a GetWorkerSpecifications request to all online
`workers.
`2. Each worker reply will provide a description of its
`capabilities (e.g. free CPU and free Memory).
`3. When replays from all online workers are received, C
`performs a matchmaking* process between the resource
`requirements of T and the capabilities of each replied
`worker. Then, an efficient scheduling* algorithm is
`applied to generate an ordered list of online workers
`putting the most suitable worker for T at the top of the
`list.
`4. C pushes task files of T to the first worker in the list (W).
`Once receiving files, W starts execution of T and C will
`start monitoring W using a separate monitoring thread
`(Th).
`5. W periodically sends checkpoint files to C. The fault-
`tolerance mechanism applied to deal with unexpected
`failure of W is described in Ref. [2]. If W failed, C
`removes W from the worker list, go to step 4.
`6. When task execution is completed, W sends the result file
`to C, then C reports end of execution to the user.
`B. Pull mode for serial execution (PlS) Algorithm
`To enable pull mode execution, some/all workers in the
`Grid must be configured to work in pull mode. The following
`steps are included:
`1. All workers (i.e. in pull mode) in the Grid periodically
`sends IsTaskAvailable request to all online clients. Each
`client always replies NoTaskAvailable when there is no
`task to be executed.
`2. When a client (C) has a task (T) to execute, T is
`published, so that, C replies TaskIsAvailable to all
`requesting workers containing information about resource
`requirements of T.
`3. Once a worker W receives that response, it performs
`matchmaking between the capabilities of W and the
`requirements of T. The matchmaking result will be:
`
`* Description of the matchmaking and scheduling algorithms will be
`published in another paper because of space limitations.
`
`
`SuitableTask, if W can execute T without overloading
`local resources, or NotSuitableTask otherwise.
`4. If the matchmaking process resulted in SuitableTask, W
`sends another IsTaskAvailable request to C, to find out if
`another worker pulled the task.
`5. If C replied TaskIsAvailable, W sends IamPullingTheTask
`message to C and starts pulling task files of T. When C
`receives IamPullingTheTask from a worker W, T will be
`reserved for W, and C will reply NoTaskAvailable to all
`other workers.
`6. When all task files are pulled, W sends TaskCaptured
`message to C, and starts execution of T. Once C receives
`TaskCaptured from W, it starts monitoring W using a
`separate monitoring thread (Th).
`7. Step A.5 is performed. If W failed, go to Step 2.
`8. When task execution is completed, step A.6 is performed.
`C. Push mode for parallel execution (PsP) Algorithm
`When a client (C) has a parallel task (T) to execute, T will
`be executed in the following sequence:
`1. Task files for each subtask (Tpi) of T are stored in a
`separate directory (
`1, 2, ... N ,N: number of
`Vi
`subtasks), where i is the unique ID for the subtask Tpi.
`2. Steps A.1 through A.3 are performed.
`3. For i = 1 to N:
`C pushes task files of Tpi to the first worker in the list
`(Wi). Once receiving files, W starts execution of Tpi and
`C will start monitoring Wi using a separate monitoring
`thread (Thi).
`4. Step A.5 is performed for each Tpi (
`Vi= 1, 2, ... N).
`5. When execution of a subtask Tpi is completed, Wi sends
`the result file of Tpi to C, then, C stops the thread Thi.
`6. When all result files are received, C combines these files
`to construct the result file of T, then reports end of
`execution to the user.
`D. Pull mode for parallel execution (PlP) Algorithm
`When a client (C) has a parallel task (T) to execute, T will
`be executed in the following sequence:
`1. Steps C.1 and B.1 are performed.
`2. When T is ready for execution, T is published, so that, C
`replies SubTaskIsAvailable to all requesting workers
`containing information about resource requirements of T,
`and the ID (I) of the first available subtask of T (TpI).
`3. Step B.3 is performed.
`4. If the matchmaking process resulted in SuitableTask, W
`sends another IsSubTaskAvailable request, containing the
`value of I, to C, to find out if another worker pulled the
`subtask TpI.
`5. If C replied SubTaskIsAvailable for TpI, W sends
`IamPullingTheSubTask message, including I, to C and
`starts pulling task files of TpI. When C receives
`IamPullingTheSubTask from a worker W for TpI, TpI will
`be reserved for W.
`6. If I = N (all subtasks are pulled) then go to step 7.
`Else: C increments the value of I, to point at the next
`available subtask, go to step 2.
`7. When all task files are pulled for a subtask Tpi by a
`SubTaskCaptured
`worker Wi (
`Vi= 1, 2, ... N), Wi sends
`message for Tpi to C, and starts execution of Tpi. Once C
`receives SubTaskCaptured from Wi, it starts monitoring
`Wi using a separate monitoring thread (Thi).
`
`Authorized licensed use limited to: IEEE Publications Operations Staff. Downloaded on August 10,2021 at 20:55:08 UTC from IEEE Xplore. Restrictions apply.
`
`Netflix, Inc. - Ex. 1025, Page 000009
`
`

`

`"i/ i = 1, 2, ... N). ifa
`8. Step A.5 is performed for each Tpi (
`worker Wi failed, set I = i and go to step 2.
`9. Steps C.5 and C.6 are performed.
`IV. CLIENT AND WORKER ARCHITECTURE
`The Worker and the Client are the major components
`involved in the system. Each Grid node (i.e. Peer) has both
`components installed. Implementation of both components is
`mainly based on .Net Framework. All classes, associated with
`the client or the worker, are included in the GridLibrary
`namespace. The clients user may write his/her own code for
`the task in any language supported by .Net framework. An
`abstract class, GridBase, is included in the GridLibrary
`namespace as a base class for any user class. A user class
`inherited from GridBase must override the WorkingMethod()
`method in which the user code is written. Methods associated
`with the incremental ALC are also included in GridBase and
`can be optionally called in the user code. The code file of a
`Grid task [2] is the compiled version of the user class, as a
`.Net DLL assembly. In this section, the architecture of each
`component is briefly described.
`Worker Architecture
`The Grid worker has two main functionalities: executing
`Grid tasks, periodically requesting for task from available
`clients, in case of pull mode.
`
`D
`
`Monitor
`
`Computaion Layer
`Worker
`Execution
`Application
`Monitor
`
`tasks on workers and
`the execution of
`monitoring
`implementing the fault-tolerance mechanism. Fig. 3 shows
`the client architecture. User GUI is a windows application,
`runs in the user application domain, through which the client
`user can generate the task/subtask files and configure the
`execution process [2]. The Scheduler is a background process
`used when working in PsS or PsP modes (see section III). It
`is responsible for requesting worker specifications from
`the matchmaker
`online workers, calling
`to perform
`matchmaking, and generate the ordered worker list. The
`Distributor is responsible for allocating subtasks to workers
`in the worker list, and used in PsP mode only. Task/Subtask
`Manager is responsible for pushing task/subtask files to the
`worker, monitoring task/subtask execution on the worker,
`receiving checkpoint files and responding to worker failure.
`One Task Manager is generated in a separate thread in case of
`serial execution, while multiple Subtask Managers are
`generated each in separate thread in case of parallel execution.
`
`
`Distributor
`
`PsPPsP
`
`Scheduler
`
`Matchmaker
`
`PsSPsS
`
`Task
`Manager
`
`PsPPsP
`
`PlPPlP
`
`Subtask pool
`
`
`SubtaskSubtask
`
`SubtaskSubtask
`
`SubtaskSubtask
`
`ManagerManager
`
`ManagerManager
`
`PublisherPublisher
`
`Task
`Publisher
`
`Communication Layer
`
`(cid:143)
`
`
`SubtaskSubtask
`
`SubtaskSubtask
`
`SubtaskSubtask
`
`ManagerManager
`
`ManagerManager
`
`ManagerManager
`
`UserUser
`GUIGUI
`
`PsSPsS
`
`PsPPsP
`oror
`PlPPlP
`
`PlSPlS
`
`User Application Domain
`Grid Client Application Domain
`Figure 3. Architecture of the Client
`
`
`
`
`Task Publisher and Subtask Publisher are used when
`working in PlS and PlP respectively (see section III). It is
`responsible for setting a flag associated with the task/subtask
`through which it can be detected that the task /subtask is
`available or not when the worker sends IsTaskAvailable
`request. One Task publisher is generated in a separate thread
`when working in PlS mode, while multiple Subtask Managers
`are generated each in separate thread when working in PlP
`mode.
`Communication Layer
`The communication layer is responsible for providing
`communication channels to perform transmission of control
`commands and files between the client and the worker. Fig. 4
`shows the structure of the communication layer. Two
`alternative communication protocols can be implemented in
`the system: Tightly Coupled Communication Protocol
`(TCCP), and Loosely Coupled Communication Protocol
`(LCCP). TCCP is based on .Net Remoting with binary
`serialization [17] over TCP chann