Alma Mater Studiorum University of Bologna CdS Laurea Magistrale (MSc) in Computer Science Engineering

Transcription

1 Mobile Systems M Alma Mater Studiorum University of Bologna CdS Laurea Magistrale (MSc) in Computer Science Engineering Mobile Systems M course (8 ECTS) II Term Academic Year 2016/ Design Principles for Mobile Middleware and Applications Instructor: Paolo Bellavista paolo.bellavista@unibo.it 1

2 Mobile Systems and Services Evolution 1st generation ( ) Text messages (SMS) and limited forms of mobile access to data; maximum bandwidth around tens of Kbps 2nd generation ( ) Limited Web browsers, WAP, imode and MMS; maximum bandwidth up to 144Kbps 3rd generation ( ) Mobile platforms, so-called middleware services; terminals with Symbian Series 60, J2ME, Android, ios,...; maximum bandwidth up to several Mbps 4th generation ( ) Adaptive services, adaptive user interfaces, adaptive protocols; context awareness; continuous connectivity; maximum bandwidth up to hundreds of Mbps 2

3 Mobile Systems and Services Evolution Stores and Web pages Social sites, media portals revenue On-demand and streaming video Advanced browsers SMS ringtones, logos WAP Ringtones Java portals Full music and video streaming Full music streaming Music downloads Music clips Monophonic Polyphonic Master tones time 3

4 Mobile Middleware Managing many aspects (in particular mobility), not strictly application-specific, is a complex problem. For instance, mobility of: Nodes Networks Transport connections Session Objects (passive, active) Services Users Several solutions are needed, at multiple levels (link, network, transportation, application) and cross-layer Mobile middleware solutions to indicate all support solutions typically positioned from OSI level 4 to upper 4

5 Middleware Pop and largely employed term, sometimes also in a partially imprecise way A possible definition: A set of service elements above the operating system and the communications stack An alternative definition: Software that provides a programming model above the basic building blocks of processes and message passing (Colouris, Dollimore, Kindberg, 2001) We define it as support software stack, typically cross-layer and application-agnostic, which targets issues and challenges at OSI levels >= 4 5

6 Why the Need of Middleware? Development of distributed apps as complex and time-consuming process Any developer has to code from scratch his/her protocols for naming services, transactions,...? How to manage the unavoidable heterogeneity of execution ens? Need of middleware To reduce development time and to favour rapid prototyping To simplify application development and thus reducing the costs To support heterogeneous envs., by partially masking differences at hardware/os/app levels diverse applications divergence transport layer (TCP/IP) convergence diverse physical layers hourglass model 6

7 Who Benefits from Mobile Middleware? Final Users Even if the middleware goal is not to directly interact with final users, support to services and applications visible to users. Thus, middleware with mechanisms and APIs suitable for managing different types of failures and runtime errors, in addition to supporting enhanced usage experience Device Manufacturers Middleware to offer advanced and extended features that can interface, at lowest layers, with device drivers Internet Service Providers Middleware for network monitoring, management, and admin Providers of middleware platforms Development of middleware platforms that are integrated with different OSs Application Service Providers Middleware to facilitate development and deployment of applications in a rapid, scalable, and low-cost way 7

8 Objectives and Key Elements Accessibility and Reachability Resources have to be always available and accessible for final users independently of current location (of both resources and users). Nowadays full support to this? Do we really want complete transparency? Adaptiveness Mobile services and their usage occur in environments affected by runtime modifications; they must adapt themselves dynamically to the working deployment environment Appropriate level of confidence (trust) An adequate trust level has to be obtained among the interacting entities, so that operations are performed according to common agreements and expectations. Contracts? How to achieve decentralized trust? Universality Possibility of universal access to data such as in the case of the Web over the traditional Internet 8

9 Mobile Middleware Middleware is traditionally designed, implemented, and optimized for fixed network hosts Large bandwidth, low latency, reliable communications Persistent storage, good computing capabilities, no constraint associated with energy consumption No mobility Mobile systems call for novel middleware solutions Existing middleware is not suitable for resource-limited devices and sometimes exhibits limited scalability Mobile middleware goals: fault-tolerance, adaptiveness, heterogeneity support, scalability, resource sharing 9

10 Mobile Middleware Mobile middleware Context dynamically changes Need of decoupling in space and in time Asynchronous events, spaces for data sharing Basic approach in many cases of wireless computing Adoption of proxies In addition, provisioning of some level/degree of visibility of running conditions to lower layers (sometimes reflective middleware) Transparency to location in RPC/RMI In mobile envs, partial visibility of location change, modifications in the QoS levels currently available,... 10

11 Internet Principles End-to-End Principle In its origin expression, referred to the opportunity to maintain state and intelligence only on network borders (edges) Internet connects these edges without keeping state, in order to achieve maximum efficiency and simplicity Today in real scenarios: firewalls, Network Address Traversal, caches for Web content. These are relevant modifications to this general principle Towards Trust-to-Trust principle (application logics always run on trusted nodes?) Robustness Principle Be conservative in what you do, be liberal in what you accept from others (attributed to Jon Postel, RFC 793 TCP) Internet stack developers should be careful in respecting what specified in existing RFCs when they implement their functions, but be ready to process less rigidly and to accept non-compliant input from others (even non-compliant with existing RFCs) 11

12 Web Principles Web principles follow the guidelines of the ones at the basis of the underlying TCP/IP stack Simplicity, modularity, decentralization, and robustness In particular, about access, data representation, and data transformation for Web resources: Principle of application of least powerful language to implement any feature (maximum accessibility and URL mechanism) Cental and recognized proble is state maintenance for stateful interactions. For instance, Representational State Transfer (REST- see later), based on URIs, HTTP, XML Client-server, stateless, cacheable, layered Uniform interface to transfer state between client and resource (limited set of well defined operations, possibly using code on demand) 12

13 SOA Principles Service Oriented Architecture (SOA) as the sw architecture where features and functions are structured around business processes and implemented via interoperable loosely-coupled services. Strongly based on message-oriented communications Re-usability, granularity, modularity, possibility of dynamic composition, component-based organization, interoperability Compliance with standards Identification and classification in terms of categories of services, provisioning and delivery, monitoring and tracking 13

14 Specific Principles for Mobile: Device Perspective (see NoTA) Example of Network on Terminal Architecture (NoTA): architecture proposed by Nokia to internally structure mobile devices; general validity of principles below System-level loose coupling. Loose coupling pushed to the extreme of hw components that are the constituents of the device Interconnect-centric. Central component is responsible for the interconnection of other components and services (common bus), based on message passing mechanisms Based on (and oriented to) services, features implemented via services with well defined interfaces. Together with loose-coupling, this favors adaptiveness Message & data driven. Message passing as preferred mechanism in applications. Data-driven communications in the sense of forwarding requests based also on current system conditions and data included in the requests themselves. Towards decoupling Implementation-wise heterogeneous. Integration of sub-systems from different manufacturers and vendors; once interface specs and request formats are known, components are inter-changeable 14

15 The NoTA Example Based on services also for the internal integration within a single device Possibility to compose sub-systems 15

16 Specific Principles for Mobile: Perspective Session Maintenance (SIP) Session Initiation Protocol (SIP), as basic mechanism for converging Next Generation Networks (NGNs). Have you already used the term in other courses, haven t you? Massive usage of proxies, e.g., for routing Call state maintained at endpoints Endpoint fate sharing, i.e., application failure when their endpoints fail Exploitation of a dialog model, NOT call-oriented model Architecture based on logical components (they play logical roles, not necessarily associated with physical components) Generality over efficiency Clear and clean separation between signalling plane and media distribution plane 16

17 The SIP Example Protocol that exchanges typically verbose messages and is based on proxies to maintain session state Dialog model, not call oriented Together with Diameter, it realizes the basis for IP Multimedia Subsystem (IMS) architecture 17

18 Specific Principles for Mobile: Cross-Layering Different types of interaction for different ways of crosslayering in a protocol stack Upward info flow, with info propagated from lower to higher layers, in opposite to classical principles for layered architectures Downward info flow, with info propagated from higher to lower layers, typically to configure lower-layer parameters and settings Back-and-forth info flow, with info propagated in both directions Merging of adjacent layers, allows the combination of different adjacent layers into a single super-layer Coupling with no addition of new interfaces. Two or more layers are coupled at design time in a finalized way, with no possibility of maintaining independency/abstraction from lower layer Vertical calibration between layers. Usually to achieve layersjoint optimization of the configuration of parameters (joint tuning) and to obtain better overall performance 18

19 Cross-Layering Principle Designed for X Layer X Upward information flow Downward information flow Back and forth flow Merging of adjacent layers Design coupling Vertical coupling 19

20 Architectural Patterns Several architectural patterns of general applicability and usage, not only in distributed systems: Level-based. Multi-layer sw architecture with different responsibilities rigidly allocated to different layers Client-Server. Most frequent pattern in distributed computing: clients use resources and services offered by server Peer-to-peer. Any node can dynamically play the role of either client or server; functionality could be more or less symmetric Pipeline (or pipe&filter). Pipeline as chain of processing elements aligned in such a way that output of one is offered as input for the successive one in the chain Multi-tier. Client-server architecture where applications are run by a multiplicity of different software agents Blackboard. A common knowledge base (blackboard) is updated iteratively by different knowledge sources, starting from including problem specification and then evolving to solution results Publish/Subscribe. 1) Event channel and 2) Notifier (abstracting from location/distribution of broker) 20

21 Architectural Patterns for Mobile Computing Not only usable in mobile applications, but particularly useful in these scenarios: Model-View-Control (MVC), as either architectural or design pattern, see Web applications Broker, to introduce and favor decoupling between clients and servers Microkernel. Crucial reduced system features (microkernel), cleanly separated from more complex and extended functionality, which may be plugged-in via given interfaces Active Object. It simplifies the support to asynchronous processing via encapsulation of requests and responses at service completion 21

22 Model-View-Control Application plit in three parts, with separated responsibilities and well-specified interaction modes Method invocations and events For example, used in Symbian OS 22

23 Broker Broker component that implements decoupling between clients and servers Servers register at brokers, by offering their services to clients via interfaces registered at the broker Clients access server functionality by sending service requests to the broker Broker duties include: to determine/localize the suitable server to perform request forwarding to servera to transmit results and exceptions back to clients Typical example: CORBA Object Request Broker 23

24 MicroKernel Pattern typically applied in scenarios with complex sw systems that play the role of platforms for other applications Desired features are extensibility, adaptivity, and interoperability Central idea is small extensible core that can be expanded through components that can be plugged-in dynamically External Server Calls Microkernel Microkernel Microkernel calls Internal Server Calls Adapter Calls Client 24

25 Support for asynchronous processing Active Object Works through encapsulation and management of asynchronous service requests and of responses when the service is completed Client is notified of operation completion and capable of performing other operations, even with the same server, in an asynchronous way Active Object runs in the same thread of main application, to reduce overhead of context switching between threads Active Object has to manage events in a non-preemptive way (one event processed at a time; rapid processing) Decide resumed object CActiveScheduler ActiveObject Status AsynchronousServiceProvider CActive Status flags 25

26 Patterns for Mobile Computing Three pattern categories for mobile middleware and applications: For distribution (how to distribute and access resources in runtime execution environment) remote facade, data transfer object, remote proxy, observer For resource management and synchronization session token, caching, eager acquisition, lazy acquisition, synchronization, rendezvous, state transfer For communication connection factory, client-initiated connection 26

27 Distribution: Remote Facade Mobile Device Addresses Directions and maps Last hop wireless network Remote Facade Addresses Coordinates Coordinates Routes Route Segment Direction Route Segment Highlighted map Fast fixed-network Map Web Services Coarse-grained interface towards single or multiple fine-grained objects Interface provided via remote gateway Accepts incoming requests that are compliant with facade interface Successive interactions are fine-grained between remote facade (gateway) and object interfaces Application adopting the pattern does NOT need to know which specific remote servers or functions are used to implement the requested operations 27

28 Distribution: Data Transfer Object (DTO) Data Transfer Object (DTO) pattern to offer a serializable container to transfer multiple data elements among distributed processes Primary goal is to reduce the number of remote method calls Single DTO contains all the data that have to be transferred because of interest for an overall application Usually implemented as a simple serializable object that includes a set of fields with the corresponding getter & setter methods 28

29 Distribution: Remote Proxy Proxy (or gateway) interposed between device and network By the way, it is clear the difference between proxy and gateway, isn t it? Client Web Browser encoded request wireless encoded response Gateway Encoders Decoders Protocol Gateways request response Server HTTP Server CGI,.. All messages/packets (or a selected subset of them) pass through the proxy, which can evaluate them (also their content) and perform operations on them Proxies also to perform computationally intensive operations in place of client device Proxy works as an adapter, by also enabling server-side interaction with no need of implementing terminal-specific protocols and solutions Typically need for discovery solutions to identify proxies at runtime 29

30 Distribution: Observer Supports definition of one-to-many dependencies between objects All objects that are considered dependent are notified at the occurrence of modifications of the state of objects under observation Decoupling via subject and observer Support to group-oriented communications, but limited scalability Adopted in Java and Jini event models Subject Update observers Observer ConcreteSubject Attach/detach observer Subject getstate ConcreteObserver 30

31 Resource Management: Session Token Makes simpler and more lightweight the duties and requirements for server-side state management Token emitted by server and sent to client (it includes data referring to the active session of the client with that server) Token includes session identifier (sometimes also related security info and time-to-live in order to avoid replay attacks) When client presents again the token to server, the server can correctly associate the client to its proper session (stato, ) By the way, in which technologies have you already seen the application of such a solution pattern? 31

32 Resource Management: Caching Suggests temporary storage of resources in local memory after their employment, instead of their immediate destruction or de-allocation First, local check in resource cache, whenever a new request for resource/service is received If cache hit, immediate delivery to requesting application If cache miss, request is propagated and new entry created in cache Examples of file systems, such as Coda and Aura, for pervasive computing ResourceProvider ResourceUser Access ResourceCache ResourceProvider provides Resource Resource Access 32

33 Resource Management: Eager Acquisition If needed resources are known by an application from the beginning, possibility to exploit this info to operate prefetching of required resources Result is that resources are already available locally when actual need will occur; no necessity of remote requests Examples of resources such as memory, network connections, file handlers, threads, and sessions ResourceProvider ResourceUser ProviderProxy Resource 33

34 Resource Management: Lazy Acquisition To optimize system resource usage, this pattern suggest to postpone resource acquisition till the end (latest possible time) Resource Proxy is responsible for intercepting all user requests for resources Resource Proxy does NOT acquire resources, transparently, until the user does not access them explicitly ResourceProvider ResourceUser ResourceProxy Resource 34

35 Synchronization To efficiently manage multiple instances of data for a set of devices, this pattern suggests to realize and use a synchronization engine Sync engine keeps track of modifications made on employed data, by exchanging modification metadata transparently (coordination of different engines) and by updating data when appropriate, e.g., connectivity is available Sync engine responsible for conflict detection and resolution during sync process Possibility to access stale data and conflicts Terminal Synchronization engine Host Synchronization engine Now, small :-) lecturing time about sync and SyncML Data Data 35

36 Synchronization and SyncML: Traveling Salesman Scenario Mobile Device Local DB Company Central DB Mobile Device Local DB Itinerary covering clients to visit Mobile Device Local DB Also possibility of temp disconnection Customer A Customer B Customer C 36

37 Two Primary Types of Possible Synchronization 37 Synchronization at process level Synchronization at data level time Process A changes Data item 1 Process B System A Process changes System B Process changes sync Data Item 1 Data Item 1 time Process A Data item 1 changes sync detection sync Process B Main? System changes Data Item 1 Data item 1

38 Sometimes it is possible to merge data during synchronization System A System B System A System B Order with 50 items Order with 25 items Order: 50 Order: 25 Stock Product A: 100 Stock Product A: 100 Stock Product A: 50 Stock Product A: 75 Disconnected operations Main? System Apply changes in sync phase Main? System Stock: 100 Stock: 25 Insert order, reduce stock Insert order, reduce stock No conflicts in this case; always true? 38

39 Synchronization: Basic Models and Elements Until an efficient implementation of the ideal concept of cloud computing will not be available, seamlessly and with low cost, relevance of disconnected operations and synchronization in a second step/phase Apart from joking, costs (in terms of money, energy, ) + connectivity bandwidth + discontinuous connectivity push towards disconnected operations and replicas/copies management Freedom degrees in synchronization: When to launch sync operations Manuas vs automated trigger See also similar problems in more traditional distributed replication How to synchronize (sync styles) Pessimistic single modifiable copy; synchronization as replication of the single modified instance Optimistic multiple copies may be modified; in a second step, trying to reconcile already performed modifications With which costs? 39

40 Synchronization: Basic Models and Elements Often used basic mechanism: versioning Different possible solutions; in general, open issue on how to do versioning to improve sync process according to optimistic approach Usually simple versioning mechanisms staisfy the following properties: If version B comes from a change in A, then version B is greater than version A If two copies have been concurrently modified in different locations, then version numbers are NOT comparable Linear sequence of versions at each single location; anyway possibility to detect concurrent modifications Two phases (in addition to update propagation): Change detection (clean or dirty copies, also with conservative approach) Reconciliation (need to consider syntax and semantics of data) Log with modification operations reconciliation as processing of overall log that starts from the last common version before change State comparison it operates directly on changed data 40

41 Synchronization In realistic cases, always synchronization as a process between ONLY two nodes that keep data copies Centralized architecture with one node playing the role of master for each data instance Tree-based architecture (sync between node and its single parent) More general architecture as cyclic connected graph (greater flexibility but more complex management: e.g., which previous versions to consider for state comparison?) Rarely used in nowadays sync systems Reconciliation algorithms may benefit from knowledge of the nature (e.g., structure) of shared data Growing reconciliation capabilities while passing from opaque info, to known structure, to unique id also for data parts, to known semantics, and finally to application-specific solutions 41

42 A couple of notable examples File systems (e.g., Coda, just to mention one of the oldest): Do you know the technical difference and distinction between Networked File System (NFS) and Distributed File System (DFS), don t you? Typically DFS work on consistency for folder tree, not at the level of data content for each file (delegated to an external synchronizer plug-in); oftem request to explicit intervention by user Similarly to consistency management for an XML tree Do you know the ancestor tools diff and patch in Unix? Or more refined and sophisticated examples of tools, such as rsync? 42

43 A couple of notable examples Concurrent Versions Systems (CVSs) for collaborative work, usually for sw development: First trivial versions with centralized server that releases a lock to a single participant at a time; NO need for reconciliation Now generally optimistic approach and centralized architecture: 3-way merge algorithm; conflict detection and possible request for user intervention Even first non-centralized approaches, with exploitation of change sets (each of them atomic and with unique id): synchronization a ordered and completed application of all change sets 43

44 Middleware for Synchronization Of growing relevance for mobile systems and services, middlewarelayer support for application sync Synchronization APIs available to developers Operations for update detection and reconciliation as typically local operations On the contrary, needed actions of update propagation as operations that call for novel protocols and support of intermittent connectivity Often based on messaging or pub/sub systems Example of (partial) solution for synchronization, relatively widespread and adopted: SyncML 44

45 SyncML Open Mobile Alliance (OMA) adopted Synchronization Markup Language (SyncML) as the sync language to increase interoperability and to contrast growing number of proprietary protocols SyncML is NOT a compete sync solution: only sync protocol (update propagation), NO specifications about change detection and reconciliation Based on log-oriented approach (idea to track any insert, delete,... operations on data objects that are considered atomic entities in SyncML) Centralized architecture; message exchange Sync is started by client Server receives modifications, applies them to its main replica, determines possible conflicts, and returns back to client another SyncML file with further modifications to apply Usage of several protocols at lower layers (HTTP, OBEX, ) to transfer SyncML messages 45

46 SyncML Sync server typically knows application semantics (external to SyncML specification) for reconciliation; usage of version numbers Used in several existing applications OMA includes Ericsson, Nokia, IBM, Motorola, 46

47 SyncML in Finer Details Designed to be efficient over wireless networks: data and command encoding is optimized (WAP Binary XML - WBXML) in a binary format Robust to connection losses during message exchange Several solutions for message transfer: HTTP, Bluetooth OBEX, IrDA, SMTP, and WAP Wireless Session Protocol Support to any type of data, from vcard to , from relational data to HTML/XML documents and binary data Standard specification defines: SyncML representation protocol for messsage format SyncML synchronization protocol for sync operations between two entities (client and server in SyncML terminology) 47

48 SyncML Synchronization Protocol Client and server have to maintain modification logs (non-standardized format); if log is lost, slow sync Initial negotiation to determine device capabilities (e.g., supported data formats, ) Exploitation of sync anchors (strings) to identify sync events. Client-side, last anchor call represents last event before sync with server; next the current one. Comparison with server to verify that faults/failures have not generated synch anchor loss; in the case, slow sync Unique identifiers for data to keep synchronized. Usage of client-side Locally Unique IDs (LUIDs) and server-side GUIDs; mapping table is maintained server side Mode to notify client that conflict has been solved (state codes to describe conflict type and how it has been solved). For example: <Status> <MsgRef> 1 </MsgRef> <CmdRef> 2 </CmdRef> <SourceRef> 2121 </SourceRef> <Data> 208 </Data> <! conflict solved through data merge - -> </Status> 48

49 <SyncML> <SyncHdr> <VerDTD>1.0</VerDTD> <VerProto>SyncML/1.0</VerProto> <SessionID>1</SessionID> <MsgID>2</MsgID> Example of SyncML Message: Client Sends Changes <Target><LocURI> </Target> <Source><LocURI>IMEI: </LocURI></Source> </SyncHdr> <SyncBody> <Status> <MsgRef>1</MsgRef><CmdRef>0</CmdRef> <Cmd>SyncHdr</Cmd> <TargetRef>IMEI: </TargetRef> <SourceRef> </SourceRef> <Data>212</Data> <!--Statuscode = OK, successful authentication for session--> </Status> 49

50 Example of SyncML Message: Client Sends Changes <Status> <MsgRef>1</MsgRef><CmdRef>1</CmdRef> <Cmd>Alert</Cmd> <TargetRef>./dev-contacts</TargetRef> <SourceRef>./contacts/james_bond</SourceRef> <Data>200</Data> <! Status code for success--> <Item> <Data> <Anchor xmlns='syncml:metinf'><next> t093223z </Next></Anchor> </Data> </Item> </Status> <Sync> <CmdID>1</CmdID> <Target><LocURI>./contacts/james_bond</LocURI></Target> <Source><LocURI>./dev-contacts</LocURI></Source> <Meta> <Mem xmlns='syncml:metinf'> <FreeMem>8100</FreeMem> <! Free memory on client calendar app--> 50

51 Example of SyncML Message: Clients Sends Changes <FreeId>81</FreeId> <! Number of free records in calendar--> </Mem> </Meta> <Replace> <CmdID>2</CmdID> <Meta><Type xmlns='syncml:metinf'>text/x-vcard</type> </Meta> <Item> </SyncBody> </SyncML> <Source><LocURI>1012</LocURI></Source> <Data> vcard data go here </Data> </Item> </Replace> </Sync> 51

52 Further Info and Useful Links There are existing servers, also open source, that support SyncML, e.g., Sync4j and its implementation as extension module for Java Enterprise application servers (see Funambol community ) Further information and useful links : SyncML - x.html JSR230 Data Sync API

53 Synchronization: Rendezvous Rendezvous as frequently used pattern in network infrastructure elements (but not only) to realize management of mobile devices In general, rendezvous as a pattern to allow two or more entities to coordinate their activities Typically implemented in distributed systems via rendezvous points Entities that are logically centralized (indirection points) Accept messages/packets and keep state, thus being able to respond, e.g., on where a mobile device is currently located Examples: DNS, Mobile IP, HIP,... Client A Update data Rendezvous Lookup data Client B Access client A Either through Rendezvous or directly 53

54 Resource Management & Synchro: State Transfer Client Old AP New AP Rendezvous Correspondent node Old AP is the current point of attachment Attach to a new AP Teardown old attachment Update location As you already know, different types of handoff are possible Forward message Lookup client Send message Handoffs may need state transfer between APs Exploitaton of indirection point (rendezvous) to ensure reachability 54

55 Examples of Rendezvous & State Transfer: Mobile Correspondent IP, Wireless CORBA, Mobile Web Server host Home agent Foreign agent Home link Web server Mobile host Browser Care-of-Address (CoA) Foreign link Home domain Home Location Agent Operator firewall 3 Gateway 2 1 DNS Terminal Bridge GIOP Terminal tunnel domain Internet Access Bridge Access Bridge Visited domain Access Bridge Host Access Bridge 55

56 Communication: Connection Factory Suggests decoupling application and underlying communication system via introduction of a component used to instantiate, access, and terminate connections The factory design pattern is widely used; in this case, it is employed to enable the efficient management and re-use of connections Largely used in the Java world in general. APIs for Java ME communications adopt this pattern 56

57 Communication: Client-initiated Connection for Push Model Client Edge Proxy Server Lookup service Initiate connection Update client status Lookup client In many cases it is impossible to reach a mobile client due to firewall/nat along the communication path Forward message Send message Associate message with connection These issues motivate the usage of client-initiated connections to a server with public IP address that then can operate message push towards client by using existing connection Examples: MS DirectPush, AJAX 57

58 Communication: Multiplexed Connection Connection 1 Connection N Connection 1 Connection N Multiplexer Single connection Demultiplexer Inefficient to create many connections that may compete for network/system resource consumption Multiplexed Connection uses a single logical connection and multiplexes it to support multiple connections at a higher abstraction level Allows differentiated priorities to multiplexed messages Example: Stream Control Transfer Protocol (SCTP) 58