IPR2022-00368
`Advanced CORBA —
`
`Zynga Ex. 1012, p. 1
`Zynga v. IGT
`
`S)
`yy
`‘eass
`ral
`
`-=m
`
`e
`a)
`pul
`
`m a n
`
`°
`re
`e
`aa
`TUR
`WN
`Py
`
`ae
`
`_o
`
`e
`rdi
`Pa
`
`a -
`
`_ x - a
`
`an
`
`ra
`ap
`ep
`
`m am N
`
`Y
`
`Zynga Ex. 1012, p. 1
`Zynga v. IGT
`IPR2022-00368
`
`

`

`Advanced CORBA®
`Programming with C++
`
`Michi Henning
`
`Steve Vinoski
`
`A v
`
`v
`
`ADDISON-WESLEY
`
`An imprint of Addison Wesley Longman,Inc.
`Reading, Massachusetts * Harlow, England ¢ Menlo Park, California
`Berkeley, California * Don Mills, Ontario * Sydney
`Bonn * Amsterdam * Tokyo * Mexico City
`
`Zynga Ex. 1012, p. 2
`Zynga v. IGT
`IPR2022-00368
`
`Zynga Ex. 1012, p. 2
`Zynga v. IGT
`IPR2022-00368
`
`

`

`Kurt &. Wendt Library
`University of Wisconsin - Madisor
`215 N. Randali Avenue
`@adison. W! 53706-1688
`
`Manyofthe designations used by manufacturersand sellers to distinguish their products are claimed as
`trademarks. Where those designations appear in this book and Addison-Wesley was aware of the
`trademark claim, the designations have been printedin initial caps orall caps.
`
`The authors and publisher have taken care in the preparation ofthis book, but make no expressed or
`implied warranty of any kind and assumeno responsibility for errors or omissions. No liability is
`assumedfor incidental or consequential damages in connection with or arising out of the use of the
`information or programs contained herein.
`
`The publisher offers discounts on this book when ordered in quantity for special sales. For more
`information, please contact:
`
`Corporate, Government, and Special Sales
`Addison Wesley Longman, Inc.
`One Jacob Way
`Reading, Massachusetts 01867
`(781) 944-3700
`
`Library of Congress Catalog-in-Publication Data
`
`Henning, Michi
`Advanced CORBA®Programming with C++ / Michi Henning, Steve Vinoski.
`p.
`cm.— (Addison-Wesley professional computing series)
`Includes bibliographical references and index.
`ISBN 0-201-37927-9
`1. C++ (Computer program language)
`I. Vinoski, Steve.
`II. Title.
`III. Series.
`QA76.73.C153 H458
`1999
`005.13’3—dc21
`
`2. CORBA (Computerarchitecture)
`
`9849077
`CIP
`
`Copyright © 1999 by Addison Wesley Longman,Inc.
`
`All rights reserved. No part of this publication may be reproduced,storedin a retrieval system, or
`transmitted, in any form, or by any means, electronic, mechanical, photocopying, recording, or
`otherwise, withoutthe prior consentofthe publisher. Printed in the United States of America.
`Published simultaneously in Canada.
`
`ISBN 0-201-37927-9
`Text printed on recycled and acid-free paper.
`3456789 10O—CRS—0302010099
`Third printing, August 1999
`
`Zynga Ex. 1012, p. 3
`Zynga v. IGT
`IPR2022-00368
`
`Zynga Ex. 1012, p. 3
`Zynga v. IGT
`IPR2022-00368
`
`

`

`Advanced CORBA Programmingwit)
`
`B90b49L4beS
`
`
`UT
`
`‘It's positively ereat. We tinally have something that actually covers the topic
`|
`5
`4
`}
`view of the standard,
`rather than a proprietary implementation
`fete be
`_lon Biggar, Floorboard Software
`
`Henning and Vinoski have written the book on CORBA with ¢
`Douglas C.
`Schmidt, Washington University, St. Louis
`
`ti
`
`B89064914625A
`
`
`
`(
`
`the CORBA book that every
`Here is
`software engineer has been waiting for.
`Advanced CORBA Programming with ¢
`provides designers and developers with the tools
`
`required to understand CORBA technology at the architectural, design, and source code levels.
`This book offers hands-on explanations tor building efficient applications, as well as lucid
`examples that provide practical advice on avoiding costly mistakes. With this book as a guide
`
`programmers will
`find the support
`they need to successtully undertake industrial-strength
`CORBA development projects.
`
`The content is systematically arranged and presented so the book may be used as both a tutorial
`and a reference. The rich example programs in this detinitive text show CORBA developers how
`to write clearer code that
`is more maintainable, portable, and efficient. The authors’ compre
`hensive coverage of
`the IDL-to-¢
`mapping moves beyond the mechanics of
`the APIs to
`discuss topics such as potential pitfalls and efficiency. An in-depth presentation of
`the new
`Portable Object Adapter
`(POA) explains how to take advantage of
`its numerous teatures to
`create scalable and high-pertormane e servers.
`In addition, detailed discussion of advanced
`topics, such as garbage collection and multithreading, provides developers with the knowledge
`they need to write commercial applications
`
`Other highlights
`
`including common idioms and design trade-offs
`IDL,
`* In-depth coverage of
`- Complete and detailed explanations of the Life Cycle, Naming, Trading, and Event Services
`* Discussion of HOP and implementation repositories
`
`t into the dynamic aspects of CORBA, such as dynamic typing and the new DynAny
`ntertaces
`
`* Advice on selecting appropriate application architectures anc designs
`* Detailed, portable, and vendor-independent source code
`
` rere he is responsible tor
`Michi Henning is chief scientist for Object Oriented Concepts,
`Inc., w
`
`research, as well as CORBA consulting and training for
`international
`ongoing CORBA-relatec
`customers. He has contributed to a number of OMG specifications and is a member of
`the
`OMG'’s Core,
`Interoperability, and C++ Revision
`Task Forces
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Inc., where he guides the development
`Steve Vinoski is chief architect for IONA Techno ogies,
`of advanced CORBA-based products. He frequently presents CORBA C++ tutorials at technical
`conferences around the globe.
`In addition, Steve has coauthored several
`important OMG
`
`specifications, and is the chair ot the OMG'’s ( Centalelain ekale aen
`
`
`
`>
`MI
`9 780201 379273
`
`vw ADDISON-WESLEY
`$54.95 UsyngavsdQianaDa
`\ddison-Wesley is an imprint ot
`Addison Wesley Longman,
`Inc
`
`
`
`ttp://www.awl.com/cseng
`
`Cover design by Jovce C. Weston
`Cover
`illustration by John Vinoski
`i) Om bnaemelamie vcled paper
`
`
`
`495
`
`Zynga Ex. 1012, p. 4
`Zynga v. IGT
`IPR2022-00368
`
`

`

`
`
`To Anni and Harry, for setting me on the path.
`To Jocelyn, for letting me followit.
`
`—Michi
`
`To Cindy, my wife and bestfriend—for yoursacrifices, your
`support, your patience, and yourlove.
`
`— Steve
`
`Zynga Ex. 1012, p. 5
`Zynga v. IGT
`IPR2022-00368
`
`Zynga Ex. 1012, p. 5
`Zynga v. IGT
`IPR2022-00368
`
`

`

`
`
`Contents
`
`
`
`Preface
`
`Chapter1 Introduction
`1.1
`Introduction
`1.2
`Organization of the Book
`1.3.
`CORBA Version
`1.4
`Typographical Conventions
`1.5
`Source Code Examples
`1.6
`Vendor Dependencies
`1.7
`Contacting the Authors
`
`PartI Introduction to CORBA
`
`Chapter 2
`
`An Overview of CORBA
`2.1.
`‘Introduction
`2.2.
`The Object Management Group
`2.3.
`Concepts and Terminology
`2.4
`CORBAFeatures
`2.5
`Request Invocation
`2.6
`General CORBA Application Development
`2.7
`Summary
`
`xvii
`
`1
`l
`3
`4
`5
`5
`6
`6
`
`a
`
`9
`9
`11
`14
`15
`23
`33
`35
`
`Chapter3=A Minimal CORBA Application 37
`
`3.1
`Chapter Overview
`37
`3.2. Writing and Compiling an IDL Definition
`37
`3.3. Writing and Compiling a Server
`39
`3.4 Writing and Compiling a Client
`44
`3.5
`Running Client and Server
`47
`3.6
`Summary
`48
`
`Zynga Ex. 1012, p. 6 vii
`Zynga v. IGT
`IPR2022-00368
`
`Zynga Ex. 1012, p. 6
`Zynga v. IGT
`IPR2022-00368
`
`

`

`viii
`
`Contents
`
`
`
` Part II Core CORBA 49
`
`Chapter 4
`
`The OMGInterface Definition Language
`4.1
`Chapter Overview
`4.2
`Introduction
`4.3
`Compilation
`4.4
`Source Files
`4.5
`Lexical Rules
`4.6
`Basic IDL Types
`4.7
`User-Defined Types
`4.8
`Interfaces and Operations
`4.9
`User Exceptions
`4.10
`System Exceptions
`4.11
`System Exceptions or User Exceptions?
`4.12
` Oneway Operations
`4.13 Contexts
`4.14 Attributes
`4.15 Modules
`4.16
`Forward Declarations
`4.17
`Inheritance
`4.18 Names and Scoping
`4.19 Repository Identifiers and pragma Directives
`4.20
`Standard Include Files
`4.21
`Recent IDL Extensions
`4.22
`Summary
`
`Chapter5
`
`IDL for a Climate Control System
`5.1
`Chapter Overview
`5.2.
`The Climate Control System
`5.3
`IDL for the Climate Control System
`5.4
`The Complete Specification
`
`51
`51
`51
`52
`56
`57
`59
`62
`77
`88
`91
`94
`95
`97
`98
`100
`102
`103
`112
`116
`120
`121
`125
`
`127
`127
`127
`130
`136
`
`Zynga Ex. 1012, p. 7
`Zyngav. IGT
`IPR2022-00368
`
`Zynga Ex. 1012, p. 7
`Zynga v. IGT
`IPR2022-00368
`
`

`

`Contents
`
`
`Basic IDL-to-C++ Mapping
`6.1
`Chapter Overview
`6.2
`Introduction
`6.3
`MappingforIdentifiers
`6.4
`Mapping for Modules
`6.5
`The CORBA Module
`6.6
`Mappingfor Basic Types
`6.7
`Mappingfor Constants
`6.8
`Mapping for Enumerated Types
`6.9
`Variable-Length Types and _var Types
`6.10
`The String_var Wrapper Class
`6.11
`Mappingfor Wide Strings
`6.12
`Mapping for Fixed-Point Types
`6.13
`Mappingfor Structures
`6.14
`Mapping for Sequences
`6.15
`Mapping for Arrays
`6.16
`Mapping for Unions
`6.17
`Mappingfor Recursive Structures and Unions
`6.18
`Mapping for Type Definitions
`6.19
`User-Defined Types and _var Classes
`6.20
`Summary
`
`225
`227
`234
`241
`242
`245
`249
`251
`259
`271
`274
`307
`322
`323
`
`Zynga Ex. 1012, p. 8
`Zyngav. IGT
`IPR2022-00368
`
`Client-Side C++ Mapping
`Chapter Overview
`Introduction
`MappingforInterfaces
`Object Reference Types
`Life Cycle of Object References
`Semantics of _ptr References
`Pseudo-Objects
`ORB Initialization
`Initial References
`Stringified References
`The Object Pseudo-Interface
`_var References
`Mapping for Operations and Attributes
`Parameter Passing Rules
`Mapping for Exceptions
`Mappingfor Contexts
`Summary
`
`d
`7.3
`7.4
`7.5
`7.6
`Td
`7.8
`7.9
`7.10
`7.11
`7.12
`7.13
`7.14
`7.15
`7.16
`FAT
`
`| T
`
`Chapter 6
`
`Chapter 7
`
`Zynga Ex. 1012, p. 8
`Zynga v. IGT
`IPR2022-00368
`
`

`

`Contents
`
`
`Chapter8
`
`Chapter9
`
`Developing a Client for the Climate Control System
`8.1
`Chapter Overview
`8.2
`Introduction
`8.3.
`Overall Client Structure
`8.4
`Included Files
`8.5
`Helper Functions
`8.6
`The main Program
`8.7
`The Complete Client Code
`8.8
`Summary
`Server-Side C++ Mapping
`9.1.
`Chapter Overview
`9.2
`Introduction
`9.3.
`Mappingfor Interfaces
`94
`Servant Classes
`9.5
`Object Incarnation
`9.6
` Servermain
`9.7
`Parameter Passing Rules
`9.8
`Raising Exceptions
`9.9
`Tie Classes
`9.10
`Summary
`Chapter 10 Developing a Server for the Climate Control System
`10.1 Chapter Overview
`10.2
`Introduction
`10.3.
`The Instrument Control Protocol API
`10.4 Designing the Thermometer Servant Class
`10.5
`Implementing the ThermometerServant Class
`10.6 Designing the Thermostat Servant Class
`10.7
`Implementing the Thermostat Servant Class
`10.8 Designing the Controller Servant Class
`10.9
`Implementing the Controller Servant Class
`10.10 Implementing the Server main Function
`10.11 The Complete Server Code
`10.12 Summary
`
`325
`325
`325
`326
`327
`328
`333
`341
`346
`349
`349
`349
`351
`353
`355
`356
`358
`376
`382
`387
`389
`389
`389
`390
`393
`396
`399
`402
`405
`407
`413
`414
`427
`
`Zynga Ex. 1012, p. 9
`Zyngav. IGT
`IPR2022-00368
`
`Zynga Ex. 1012, p. 9
`Zynga v. IGT
`IPR2022-00368
`
`

`

`xi
`Contents
`
`
`Chapter 11
`
`The Portable Object Adapter
`11.1 Chapter Overview
`11.2
`Introduction
`11.3
`POA Fundamentals
`11.4
`POAPolicies
`11.5
`POA Creation
`11.6 Servant IDL Type
`11.7 Object Creation and Activation
`11.8 Reference, ObjectId, and Servant
`11.9 Object Deactivation
`11.10 Request Flow Control
`11.11 ORB Event Handling
`11.12 POA Activation
`11.13 POA Destruction
`11.14 Applying POA Policies
`11.15 Summary
`Chapter 12 Object Life Cycle
`12.1 Chapter Overview
`12.2
`Introduction
`12.3. Object Factories
`12.4 Destroying, Copying, and Moving Objects
`12.5 A Critique of the Life Cycle Service
`12.6
`The Evictor Pattern
`12.7. Garbage Collection of Servants
`12.8 Garbage Collection of CORBA Objects
`12.9
`Summary
`
`429
`429
`430
`430
`434
`447
`451
`455
`496
`499
`502
`506
`514
`520
`522
`531
`533
`533
`533
`534
`548
`564
`570
`589
`598
`600
`
`603
`Part III CORBA Mechanisms
`
`
`Chapter 13. GIOP, IIOP, and IORs
`13.1 Chapter Overview
`13.2 An Overview of GIOP
`13.3 Common Data Representation
`13.4 GIOP Message Formats
`13.5 GIOP Connection Management
`13.6 Detecting Disorderly Shutdown
`13.7. An Overview of IIOP
`13.8
`Structure of an IOR
`13.9 Bidirectional IIOP
`13.10 Summary
`
`605
`605
`606
`607
`612
`621
`623
`624
`626
`629
`630
`
`Zynga Ex. 1012, p. 10
`Zyngav. IGT
`IPR2022-00368
`
`Zynga Ex. 1012, p. 10
`Zynga v. IGT
`IPR2022-00368
`
`

`

`Contents
`xii
`
`
`Chapter 14
`
`Implementation Repositories and Binding
`14.1 Chapter Overview
`14.2 Binding Modes
`14.3. Direct Binding
`14.4
`Indirect Binding via an Implementation Repository
`14.5 Migration, Reliability, Performance, and Scalability
`14.6 Activation Modes
`14.7. Race Conditions
`14.8
`Security Considerations
`14.9
`Summary
`Part IV Dynamic CORBA
`Chapter 15
`C++ Mapping for Type any
`15.1 Chapter Overview
`15.2
`Introduction
`15.3.
`Type any C++ Mapping
`15.4
`Pitfalls in Type Definitions
`15.5
`Summary
`Type Codes
`16.1 Chapter Overview
`16.2
`Introduction
`16.3 The TypeCode Pseudo-Object
`16.4 C++ Mapping for the TypeCode Pseudo-Object
`16.5
`Type Code Comparisons
`16.6 Type Code Constants
`16.7
`Type Code Comparison for Type any
`16.8 Creating Type Codes Dynamically
`16.9
`Summary
`Type DynAny
`17.1 Chapter Overview
`17.2
`Introduction
`17.3. The DynAnyInterface
`17.4. C++ Mapping for DynAny
`17.5 Using DynAnyfor Generic Display
`17.6 Obtaining Type Information
`17.7
`Summary
`
`Chapter 16
`
`Chapter 17
`
`631
`631
`631
`632
`636
`648
`652
`653
`656
`659
`661
`663
`663
`663
`667
`689
`690
`691
`691
`692
`692
`703
`715
`721
`725
`72d
`736
`737
`737
`737
`738
`753
`764
`766
`768
`
`Zynga Ex. 1012, p. 11
`Zyngav. IGT
`IPR2022-00368
`
`Zynga Ex. 1012, p. 11
`Zynga v. IGT
`IPR2022-00368
`
`

`

`xiii
`Contents
`
`
`769
`Part V CORBAservices
`
`
`Chapter 18
`
`Chapter 19
`
`The OMG Naming Service
`18.1
`Chapter Overview
`18.2
`Introduction
`18.3. Basic Concepts
`18.4
`Structure of the Naming Service IDL
`18.5
`Semantics of Names
`18.6 Naming Context IDL
`18.7
`Iterators
`18.8
`Pitfalls in the Naming Service
`18.9 The Names Library
`18.10 Naming Service Tools
`18.11 What to Advertise
`18.12 When to Advertise
`18.13 Federated Naming
`18.14 Adding Namingto the Climate Control System
`18.15 Summary
`
`The OMGTrading Service
`19.1 Chapter Overview
`19.2.
`Introduction
`19.3.
`Trading Concepts and Terminology
`19.4
`IDL Overview
`19.5
`The Service Type Repository
`19.6 The Trader Interfaces
`19.7 Exporting Service Offers
`19.8 Withdrawing Service Offers
`19.9 Modifying Service Offers
`19.10 The Trader Constraint Language
`19.11 Importing Service Offers
`19.12 Bulk Withdrawal
`19.13 The Admin Interface
`19.14 Inspecting Service Offers
`19.15 Exporting Dynamic Properties
`19.16 Trader Federation
`19.17 Trader Tools
`19.18 Architectural Considerations
`19.19 What to Advertise
`19.20 Avoiding Duplicate Service Offers
`19.21 Adding Trading to the Climate Control System
`19.22 Summary
`
`771
`771
`771
`7712
`774
`TIS
`780
`800
`808
`810
`810
`811
`812
`813
`817
`824
`
`827
`827
`828
`828
`834
`835
`854
`860
`866
`867
`869
`873
`890
`891
`894
`894
`898
`911
`911
`913
`914
`915
`920
`
`Zynga Ex. 1012, p. 12
`Zyngav. IGT
`IPR2022-00368
`
`Zynga Ex. 1012, p. 12
`Zynga v. IGT
`IPR2022-00368
`
`

`

`Contents
`xiv
`
`Chapter 20
`
`The OMG Event Service
`20.1 Chapter Overview
`20.2
`Introduction
`20.3 Distributed Callbacks
`20.4
`Event Service Basics
`20.5
`Event Service Interfaces
`20.6
`Implementing Consumers and Suppliers
`20.7 Choosing an Event Model
`20.8
`Event Service Limitations
`20.9
`Summary
`
`923
`923
`923
`924
`931
`936
`945
`958
`961
`963
`
`Part VI Power CORBA
`965
`
`
`Chapter 21 Multithreaded Applications
`21.1 Chapter Overview
`21.2
`Introduction
`21.3 Motivation for Multithreaded Programs
`21.4
`Fundamentals of Multithreaded Servers
`21.5 Multithreading Strategies
`21.6
`Implementing a Multithreaded Server
`21.7
`Servant Activators and the Evictor Pattern
`21.8
`Summary
`
`Chapter 22
`
`Performance, Scalability, and Maintainability
`22.1 Chapter Overview
`22.2
`Introduction
`22.3 Reducing Messaging Overhead
`22.4 Optimizing Server Implementations
`22.5
`Federating Services
`22.6
`Improving Physical Design
`22.7
`Summary
`
`Appendix A Source Code for the ICP Simulator
`A.l
`Overview
`A.2
`Transient Simulator Code
`A.3
`Persistent Simulator Code
`
`967
`967
`967
`968
`972
`980
`981
`996
`997
`
`999
`999
`999
`1000
`1011
`1013
`1014
`1017
`
`1019
`1019
`1019
`1026
`
`Zynga Ex. 1012, p. 13
`Zynga v. IGT
`IPR2022-00368
`
`Zynga Ex. 1012, p. 13
`Zynga v. IGT
`IPR2022-00368
`
`

`

`Contents
`
`Appendix B CORBAResources
`B.1 World Wide Web
`B.2.
`Newsgroups
`B.3. Mailing Lists
`B.4 Magazines
`
`Bibliography
`
`Index
`
`XV
`
`1031
`1031
`1032
`1032
`1033
`
`1035
`
`1043
`
`Zynga Ex. 1012, p. 14
`Zyngav. IGT
`IPR2022-00368
`
`Zynga Ex. 1012, p. 14
`Zynga v. IGT
`IPR2022-00368
`
`

`

`Zynga Ex. 1012, p. 15
`Zynga v. IGT
`IPR2022-00368
`
`
`
`This material may be protected by Copyright law (Title 17 U.S. Code)
`
`

`

`14
`
`An Overview of CORBA
`
`2.3 Concepts and Terminology
`
`CORBAprovides platform-independent programming interfaces and models for
`portable distributed object-oriented computing applications. Its independence
`from programming languages, computing platforms, and networking protocols
`makesit highly suitable for the developmentof new applicationsandtheir integra-
`tion into existing distributed systems.
`Like all technologies, CORBA has unique terminologyassociated with it.
`Although someof the concepts and terms are borrowed from similar technologies,
`others are new or different. Understanding these terms and the concepts behind
`them is key to having a firm grasp of CORBAitself. The most important terms in
`CORBAareexplained in the followinglist.
`A CORBAobjectis a “virtual” entity capable of being located by an ORB and
`having client requests invokedonit. It is virtual in the sense that it does not
`really exist unless it is made concrete by an implementation written in a
`programming language. Therealization of a CORBA object by programming
`language constructs is analogous to the way virtual memory doesnot exist in
`an operating system butis simulated using physical memory.
`A target object, within the context of a CORBArequest invocation, is the
`CORBAobjectthatis the target of that request. The CORBA object modelis a
`single-dispatching modelin whichthetarget object for a request is determined
`solely by the object reference used to invoke the request.
`A client is an entity that invokes a request on a CORBA object. A client may
`exist in an address space that is completely separate from the CORBA object,
`or the client and the CORBA object may exist within the same application.
`The term client is meaningful only within the context ofa particular request
`because the application that is the client for one request maybe the server for
`another request.
`A serveris an application in which one or more CORBA objects exist. As
`withclients, this term is meaningful only in the context of a particular request.
`
`Zynga Ex. 1012, p. 16
`Zyngav. IGT
`IPR2022-00368
`
`Zynga Ex. 1012, p. 16
`Zynga v. IGT
`IPR2022-00368
`
`

`

`
`
`21.3 Motivation for Multithreaded Programs 969
`
`connections. For example, ORB implementations often use the UNIX select
`system call to watch for events occurring onthesetoffile descriptors corre-
`spondingto the server’s network connections. When a requestarrives, the ORB
`reacts by dispatching the request to the application so that it can be carried out.
`For event handling to occur properly, the ORB mustbe able to gain the thread
`of control from time to time. Unfortunately, if a long-running request ties up the
`single thread doing other things, such as performing a complicated calculation, it
`denies the ORBtheability to wait for requests; the server cannot read incoming
`messages from its network connections. Whenthis occurs, it can cause the
`network transport to apply flow control to makethe clients’ network transports
`stop sending messages. If each client ORB continuesto attempt to send requests
`under these conditions, it will start getting errors from its own networktransport
`layer and thus each client also may have to buffer requests. Thus, a single long-
`running request can deny service to numerous clients.
`One way to prevent these conditionsis to ensure that no requests take a long
`time to complete. If the nature of a request is such thatit will take a while to
`process, the request can be broken up in two ways.
`* Break the IDL operation into twoparts: one to start the request and the other to
`obtain the results. For example, assumethat an interface has one operation that
`we know will take a long time to execute.
`interface Rocket
`{
`typedef sequence<octet> Telemetry;
`
`Telemetry get_all_telemetry();
`
`};
`
`If the target Rocket object is being flown only for a few minutes, it might be
`practical to have the implementation of get_al]1_telemetry simply wait for
`its flight to complete and then return all the telemetry data in one chunk. If the
`rocket is heading for the moon, however, this approach is clearly not practical.
`Breaking the operation into two parts might yield an interface that looks like
`this:
`
`{
`interface Rocket
`typedef sequence<octet> Telemetry;
`
`void start_gathering_telemetry();
`
`Zynga Ex. 1012, p. 17
`Zynga v. IGT
`IPR2022-00368
`
`Zynga Ex. 1012, p. 17
`Zynga v. IGT
`IPR2022-00368
`
`

`

`Multithreaded Applications
`970
`
`Telemetry get_telemetry (out boolean no_more_data);
`};Wefirst invoke start_gather1 ng_telemetry to tell the target Rocket that
`weintendto start requesting telemetry data. When we want data we invoke
`get_telemetry, whichreturns the data if there are any andsets the
`no_more_data argumentto true if telemetry collection has completed.
`This approachlets the implementation ofthe start_gathering_telemetry
`operation set a flag or create a work item thatindicates that telemetry should
`be collected; then it immediately returns. Whenourclient invokesthe
`get_telemetry method,its implementation can return whatever data have
`been collected to that point, setting no_more_dataappropriately. The server
`application can thus switch between gathering telemetry and allowing the
`ORBtolisten for requests (by invoking ORB: : perform_workas describedin
`Section 11.11.2) without allowing either activity to block the other.
`Break the interface into two parts instead ofsplitting the operation:
`typedef sequence<octet> Telemetry;
`
`interface TelemetrySubscriber {
`void new_telemetry(in Telemetry data);
`void telemetry_complete();
`
`ye
`
`hs
`
`IPR2022-00368
`
`interface Rocket f
`void start_gathering_telemet ry(
`in TelemetrySubscriber subscriber
`
`3
`
`This approach,usually referred to as publish/subscribe, relies on the server
`publishing information in acallback to the subscribing client. A client that
`wants to receive telemetry implements an object that supports the
`TelemetrySubscriber interface andpassesits reference to the
`start_gathering_telemetry operation. The server then calls back to the
`TelemetrySubscriber object’s new_telemetry operation in the client
`
`Zynga Ex. 1012, p. 18
`Zyngav. IGT
`
`Zynga Ex. 1012, p. 18
`Zynga v. IGT
`IPR2022-00368
`
`

`

`971
`21.3 Motivation for Multithreaded Programs
`
`
`wheneverit has data to send. When there is no moretelemetry, the server
`informsthe client by invoking telemetry_complete on the
`TelemetrySubscriber object.
`Unfortunately, these two approachesshare a common problem: the implementa-
`tion of the system dictatesits interface. Our implementation of the telemetry-
`fetching operation suffers from problemsbecauseitis single-threaded and takes a
`long time to complete, but that should not force us to redesign ourinterfaces to
`accommodateit.
`Another problem with our redesigned interfacesis that they rely on callbacks.
`Distributed callbacks are fraught with problems, as we describe in Section 20.3.
`Furthermore, unless a single-threaded ORB is careful to use non-blocking I/O
`when waiting forreplies, distributed callbacks can easily cause deadlock. For
`example, supposethat a single-threadedclient sends a request to a server and then
`blocks reading its network port waiting for the reply. If the server attempts to call
`back to the client, deadlockwill occur. That’s because the serveris trying to talk to
`the client to carry outthe original request, but the client is busy waiting for the
`server to reply to the original request. Eachoneis preventing the other from
`proceeding.It is possible to design single-threaded ORBsto avoid this kind of
`deadlock, but you should be awarethat not all ORBsprovide this capability.
`
`21.3.3
`
`Evaluating Single-Threaded Servers
`Redesigning our telemetryretrieval interfaces to avoid problems dueto single-
`threaded operation indicates that we have a problem.Specifically,it indicates the
`application convolution that results from attempting to write reactive systems
`without multiple threads. As the complexity of the application increases, it
`becomes more and moredifficult to ensure thatall tasks in the system are getting
`their share ofthe single thread.Artificial boundaries begin to appear where one
`task explicitly yields the single thread to other tasks. Preventing task starvation
`becomes more and moredifficult, and maintenance becomes complicated because
`each modification of the program requires analysis to ensure that it does not intro-
`duce task starvation.
`All in all, single-threaded operationis fine for servers that are used by only a
`few clients for short-duration requests. Pure client applications, which contain no
`CORBAobjects, also work well when single-threaded, especially when they
`perform only synchronousrequest invocations. High-performance servers, on the
`other hand,are usually multithreaded.
`
`Zynga Ex. 1012, p. 19
`Zynga v. IGT
`IPR2022-00368
`
`Zynga Ex. 1012, p. 19
`Zynga v. IGT
`IPR2022-00368
`
`