E81 CSE 532S: Advanced Multi-Paradigm Software Development Chris Gill Department of Computer Science and Engineering Washington University, St. Louis Event Handling Pattern Languages Thanks to Carol Brickman for raising the UDP and simulation server issues covered here Thanks to Doug Schmidt for timer expiration example (ace-users post)

Review: What is a Pattern Language? A narrative that composes patterns –Not just a catalog of the patterns –Reconciles design forces among patterns –Provides an ordered outline for design steps Not necessarily a procedure (details may be unspecified) A generator for a complete design –Patterns may leave consequences –Other patterns can resolve them –Generative designs resolve all forces Internal tensions don ’ t “ pull design apart ”

Pattern Language I: Logging Server Want to collect and record system events –For example, printer out of paper, new clients, etc. Events from many clients to a central server Want to add event-specific processing –And add new processing flexibly From

Pattern Language I: Logging Server Design forces –Server needs to add/remove logging features dynamically –Logging actions are short lived, and event driven Solution –Apply Reactor to manage registration and dispatching Consequences –Need a way to match events to particular logging actions Reactor Handler

Pattern Language I: Logging Server Design forces –Need a way to match events to particular logging actions –Clients can specify what events they will report Solution –Apply ACT to identify the kinds of handlers to create Consequences –Need to define how ACT is handled –Need to create correct handlers for the ACT Reactor Handler ACT

Pattern Language I: Logging Server Design forces –Need to define how ACT is handled –Need to create correct handlers for the ACT –Clients (dynamic) need to tell server when they join Solution –Apply Acceptor/Connector with server taking passive role and clients taking active role in connection establishment Consequences –Reactive logging with dynamic connection establishment and dynamic identification/creation of events/handlers Reactor Acceptor Connector Handler ACT

Pattern Language I: Logging Server One subtle design/implementation issue remains –How to pass ACT to acceptor so it knows what kind of handler to create? Could use the new socket for additional handshaking between the connector and the acceptor –Like in lab 0 where client and server exchanged names –However, this lengthens the time spent in acceptor upcall Another option –Acceptor binds a separate UDP port –Client connectors can “ mail ” it ACTs via UDP –Need to add retry, etc. above UDP level (see Stevens UNP)

(  ) Pattern Language II: Simulation Server Scripted simulation server (physics, avionics, etc.) –Each simulation has (possibly distinct) set of clients –Clients may observe, provide control actions, inputs, etc. –Similar to previous pattern language, except last pattern

Pattern Language II: Simulation Server Design forces –Clients are static and passive (known set of simulation components) –Server is dynamic and active (runs different simulation scenarios) –Server (dynamic) needs to tell clients when to start, reset, run, etc. Solution –Apply Acceptor/Connector with clients taking passive role and server taking active role in connection establishment (reverse of lab 1 roles) Consequences –Similarly reactive simulation but with dynamic connection establishment triggered by server Client 2 Server Listening port Client 1 Listening port

Pattern Language II: Simulation Server Design forces –Simulation client or server logic may need to respond to passage of time –Reactor can dispatch handlers when timers expire –How can application pass data to handler, and vice versa? Solution –Apply ACT pattern (pass address: schedule call ’ s timer_act parameter); Consequences –Arbitrary data structure can pass between application and handler –Creates a critical section (access to data structure) if multi-threaded Code that schedules Timer Handler Timer Queue Timer ACT data structure

(  ) Pattern Language III: Data Streams Want to coordinate groups of different data streams –For example, display multiple streams consistently locally Water temperatures and flow rates across a river basin Video frames from multiple cameras tracking an animal Poker hands dealt from multiple games at once –Also, may pass-through streams to other endsystems Apply ACT to identify each stream ’ s source, id, etc. –Lets end-user switch among streams transiting endsystem –Lets end-user buffer/write related messages together Need high throughput for content rich data streams –Apply Proactor to manage registration and dispatching Need to update streaming topology dynamically –Apply Acceptor/Connector to set up remote connections –May involve both active and passive roles on an endsystem

Concluding Remarks A single pattern is often insufficient –May leave unresolved design consequences Understand how patterns fit together –How one may reconcile forces from another … – … and/or leave/introduce un-reconciled forces Successful pattern languages in a context can generate complete designs –Weave patterns together coherently There are many more pattern languages than patterns (cardinality argument)