E81 CSE 532S: Advanced Multi-Paradigm Software Development

1. E81 CSE 532S: Advanced Multi-Paradigm Software Development Event Handling Pattern Languages Chris Gill Department of Computer Science and Engineering Washington University, St. Louis cdgill@cse.wustl.edu 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)

2. 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”

3. 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 http://www.cs.wustl.edu/~schmidt/patterns-ace.html

4. 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

5. Pattern Language I: Logging Server ACT ACT Reactor Handler ACT • 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

6. Pattern Language I: Logging Server ACT Acceptor ACT Reactor Handler ACT Connector • 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

7. 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)

8. () 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

9. Pattern Language II: Simulation Server Listening port Listening port Server Client 2 Client 1 • 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

10. Pattern Language II: Simulation Server data structure Timer ACT Handler Code that schedules Timer Timer Queue • 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

11. () 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

12. 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)