420 likes | 640 Views
第 3 讲 移动计算系统结构与模型. §3.1 系统结构 §3.2 计算模型. Wireless Networks. Infrastructure-based Networks. Server. MU (mobile unit). Fixed network. MSS (mobile support station). Wireless radio cell (19.2Kbps). WLAN. Ad hoc Networks. Mobile Computing Architecture.
E N D
第3讲 移动计算系统结构与模型 §3.1 系统结构 §3.2 计算模型
Infrastructure-based Networks Server MU (mobile unit) Fixed network MSS (mobile support station) Wireless radio cell (19.2Kbps) WLAN
Mobile Computing Architecture • Hierarchical: wired backbone + wireless cell
Hierarchical Architecture • Fixed network can be dedicated proprietary network for the mobile system. • Fixed network can also be the Internet or Intranet. • MSS (mobile support stations, sometimes called base station) will be in charge of communication with mobile clients or mobile hosts (called mobile unitor MU). • Communication between MSS and MU can vary a lot. • MSS helps to keep track of MU. • MSS performs paging for MU within a cell. • MSS handles handoffs for MU. • Retransmission of messages can be done at MSS to MU. • MSS may also forward messages to moved MU.
Mobile Computing Architecture • Ad hoc (peer-2-peer)
Ad hoc (peer-2-peer) Architecture • The nodes play the same role • Mobile client AND network router • Multi-hop wireless paths • Mutually helping in forwarding • Self-configuration/organization • Topology maintenance • Routing
Mobile Computing Architecture • Hybrid: wireless (ad hoc) backbone + wireless cell
Hybrid Architecture • Hierarchical but both wireless • Ad hoc backbone + wireless cell • MAP (mesh access point, sometimes called mesh router) play the same role as MSS • MAP helps to keep track of MU. • MAP handles handoffs for MU. • Retransmission of messages can be done at MAP to MU. • MAP may also forward messages to moved MU. • Ad hoc networking among MAPs • Multi-hop wireless paths • Self-*
Mobile Data Communication • How mobile units (MUs) communicate with servers and other nodes in the network? • Infrastructure network: MUs communicate with MSS directly • Ad hoc network: MUs communicate with others via intermediate nodes • Actual communication varies depending on the wireless communication hardware setup and protocol, e.g., • 802.11 with CSMA/CA, or others. • For data communication, we assume the structuring of communication resource into logical channels. • A channel is a media on which a message can be sent or received. • A channel may be unidirectionalorbi-directional, of varying observed bandwidth. • For instance, 10 Mbps Ethernet can deliver observed bandwidth of about 5 Mbps. • A channel can be a point-to-point channel that supports unicast or a broadcast channel that supports broadcast. • Multicast can be implemented as a broadcast, with recipients filtering for their information, or sequential unicasts. • Channels are usually inherently asymmetric • With higher bandwidth for downlink than uplink traffic • processing power and energy of MU and MSS (or GW) are different. • Symmetric for internal communication inside ad hoc network
Mobile Data Communication • MU can tune in to different downlink channels to download the required data at appropriate time. • MU can transmit data to MSS via uplink channels, subject to competition (e.g., CSMA/CA or reservation). • This can often be modeled as a simple queue, shared by the MUs. • MU can be in active mode or in doze mode. When it is in the doze mode, it is not able to listen to data over the channel, but this saves precious energy. • Note that a disconnected MU cannot send/receive any data, even if it is in active mode. • A practical MU will often calculate the time to download its required data and turn into doze mode, waking up at the appropriate time to pick up the data. • To enable MU to calculate the moment that a data item is available, an indexto the data items to be delivered is normally sent over the channels. • This is especially true for the broadcast channel, since data items needed by different MUs are often multiplexed on the same channel.
Mobile Data Communication • Issues to consider on the characteristics of channels: • In distributed computing environment • Reliability: reliable vs unreliable channel • Synchrony: synchronous vs asynchronous channel • Ordering: FIFO vs non-FIFO channel • In mobile computing environment • Broadcast vs point-to-point channel • Asymmetry of channel (and hence bandwidth, then synchrony) • Degree of unreliability of channel (retransmission mechanism) • Degree of prolonged disconnection • Mobility of MU to another MSS (handoff and forwarding) • Questions: • How can we ensure the correctness of distributed algorithms in mobile environment with bad channel characteristics? • How can we provide proper data management under those constraints?
§3.2 Mobile Computing Models • Client/Server • Peer-to-peer • Mobile agent Recall that many mobile computing techniques have their root in distributed systems.
Traditional Client/Server Model • Client/server model is the easiest model in distributed computing. • Client/server model is therefore the most straightforward model to adopt in a mobile environment. • Reasons: • MUs are moving around, connecting to various types of servers. • Fixed MSSs act naturally like a server for communication. • Service requests can be routed from the MSSs to other types of fixed servers such as database servers, • either via transparent message passing (e.g. IPv6) • or nested client/server invocation or RPC/RMI.
Traditional Client/Server Model • Client/server computing communicates in a master/slave manner. • Server is the slave, providing services to clients as masters. • Clients make requests to servers, which are resource managers, and obtain responses from servers for their activities. • This is easily modeled or implemented by means of Remote Procedure Call (RPC). • Examples include file server, database server, printer server, web server, and application server. C S
Traditional Client/Server Model • Client life cycle: • Repeat the following until client terminates: • Communicate with user • Contact server • Communicate with server • Client contains user interface. • Server life cycle: • Run forever the following: • Accept client request • Process request and perform computation • Return result to client • Server contains shared data.
Traditional Client/Server Model • Nestedclient/server structure: • A server may not be able to perform every task and often needs the help of other servers and uses other resources. • A server may behave as a client during its request processing cycle, generating requests to other servers to help performing its task. • Nesting may be of arbitrary levels. • For example, MSS may act as a first level server, getting help from second level application server, or database server. S C S C
Types of Servers • Iterative server: • One single server process provides the service for client. • Requests from multiple clients handled one by one sequentially. • Easy to program; no concurrent access problem; good if processing time for a request is very short. • May block other requests and cause a long response time. • Concurrent server: • Server process creates a child process to handle each request it receives. It then returns to wait for a new request, before current request is completed. Child process provides the real service and generates response. • Multiple requests are handled concurrently. • Harder to program; faster response time without blocking; must be careful about concurrent access to shared data/resource. • The more common approach for practical client/server systems.
Types of Servers Iterative server Concurrent server
Types of Servers • Stateful server: • Server saves information about status of clients. Server can remember what clients have done before. The load is on server. • This reduces the size of request messages, since both client and server share their context, e.g., a next() request implies returning result starting from current position. • Lost messages could put client and server out of synchrony/context. • Stateless server: • Server maintains no information about status of clients. All requests start from a “fresh” state and are self-contained. • Request messages need to contain sufficient information for the context. The load is on client. • Straightforward handling procedures upon failures.
Types of Servers • Fat server (and thin client): • Application logic resides on server. • Usually more efficient since data (resource) and application logic (code) stay together. • Reduce network bandwidth consumption. • Easy to change application logic without affecting clients (many of them). • Adopted by majority of client/server systems. • Thin server (and fat client): • Application logic resides on client. • Easy to explore and customize client for new applications. • Client needs to know the structure of data, debugging harder. • Consistent change of application logic difficult. • Consume bandwidth by transferring data to client for processing.
Mobile Computing Model • There are a number of possible models to structure the computing elements, processes, or units in a mobile computing environment. • Client/server model: also called C/S model, the most common distributed computing model. • Client/agent/server model: also called CAS model. • Client/intercept/server model: also called CIS model. • Peer-to-peer model: the standard distributed computing model. • Mobile agent model: also called MA model.
Mobile Computing Model • Model used should be able to handle issues in mobile computing. • Disconnection and weak connection. • Variability of communication environment. • Variation of mobile host functionality and capability. • Adaptation is needed since clients and hosts come with different capability with varying resources. • Notebook computer: docked versus non-docked. • Pocket PC with expansion card: varying memory / capability. • Mobile phone with simple OS: additional software. • Adaptation is also needed for varying operating environment. • Varying wireless bandwidth and intermittent connection. • Voluntary and involuntary disconnection. • Voluntary doze off of clients.
Adaptation from Traditional to Mobile • Application-awareness: • applications should know that client may be mobile, and detection of changing environment should be built in and appropriate operation mode is used to make better use of resources. • WAP applications should be simpler than web applications, since WAP is downloaded and executed by a mobile device. • Application should detect external environment and this could be complicated. • Duty partition between client and server: • mobile clients should bear smaller responsibility • pushing more to server • Connection-awareness: • make more extensive use of caching and data hoarding if connection is not guaranteed; • reduce communication cost by call optimization, data compression.
Adaptation from Traditional to Mobile • Two extreme approaches in adaptation: • Done at system level and transparent to applications. • Advantages: existing applications can run without change. • Disadvantages: performance may be worse; some applications cannot function without making proper preventive measure (e.g., hoarding of important files that have not been accessed). • Done by individual applications. • Advantages: applications know well what to do; make use of specific application needs to optimize handling mechanism. • Disadvantages: each application has to handle its own adaptation, with high development cost; competition for shared resources handled in different manner. • Hybrid solution • Both system level and app level • Layered in system level
C/S Model • In C/S model, client submits requests to server and server returns results back to client. • However, mobile client/server model deviates from standard client/server computing for distributed environment. • Client/server model normally assumes continuous network connectivity and reasonable client ability. • Resource limitation to clients moves “fat” client activities back to server, making clients as thin as possible. • Clients cannot be too thin, since disconnection and low communication bandwidth force us to place as much processing logic in client as possible to enable processing.
C/S Model • Traditional C/S model would not work well in mobile environment. • Direct message exchange is not good for thin client, since fat servers cannot handle requests in time, causing long queues to form. • Standard RPC is not good either, since the disconnection of clients from server would lead to excessive timeout and retransmission of request/reply. • Mobility of client causes additional problem: when and where to transmit a reply back to client, even if RPC has been decoupled into asynchronous RPC? • Need to reorganize activities on clients and servers. • Make use of the client/server model as much as possible. • Focus on improving performance to MU transparently. • Decouple the communication in synchronous RPC. • Often based on extension of client/server computing model with multiple tiers.
C?S Model • Use a variant of the three-tier approach. • Middle-tier can help to resolve previous problems. • Application logic placed in a middle tier apart from the interface (client) and the data (server). • Communication between tiers by means of message passing. • More flexible with thin client and thin server. • Application logic can be changed readily. • In general, there is an increased response time and aggregate bandwidth consumption. • Move additional processing logic to agent(s). • Agents will be responsible for work to mask out mobile computing limitations.
C?S Model • An agent is an autonomous program that can perform some specific activities, according to some agreed upon arrangement with a party that the agent is responsible for. • Two common extensions to the C/S model: • CAS model (client / agent / server model) • CIS model(client / intercept / server model or client / client intercept / server intercept / server model) • In CAS model, it is closer to fat server model, since agent is near server, but some server activities are moved to the agent. • In CIS model, additional activities are moved to the two intercept agents.
CAS Model • Agent is a surrogate or proxy that acts on behalf of the client at the server. • Communications pass through agent. • To the server, the agent looks like the mobile client, so standard C/S interaction occurs between agent and server. agent client server wireless link fixed network
CAS Model • Agent functionalities • Messaging and queuing. • Optimization to transmission over wireless link (need appropriate change in client code). • Off-load processing from client. • Handle disconnection of client. • Normally asynchronous communication between client and agent. • Agent type • Client-specific: each client has one agent. • Service-specific: each client service is associated with an agent. • Service-specific: agents may be shared among several clients (then an agent becomes a mini-server itself). • Agent placement • Placed at base station or MSS: can handle transmission optimization and personalize with client, but MSS may not be trustworthy; agent may need to move with clients to other MSS. • Placed near server: longer communication path from client to agent; better for service-specific agent. • Placed near most clients: for shared service-specific server.
CAS Model • Advantages • Thin clients can shift functionalities to agents. • Complex client requests can be pre-processed or post-processed by the agent. • Server can off-load certain activities to agent. • Different protocols can be executed between client and agent and between agent and server. • Agent can cache results to improve performance. • Disadvantages • Changes are needed in client code to be able to talk to agent. • Agent can only optimize response time between server and agent, but not much between agent and client. • Client traffic needs to pass through agent. • Cannot sustain prolonged disconnection.
CAS Model • Standard CAS model refers to client / server agent / server model. • An alternative CAS model is the client / client agent / server model. • Allocate the agent close to the client. • Agent will perform hoarding, prefetching and other compression activities. client agent server client wireless link fixed network
CIS Model • Introduce a pair of agents, one located on client and one located near server. • Agents are proxies for both client and server, and are often called intercepts. • There is a clear separation of responsibility. • This is also called the CAAS model (client / client agent / server agent / server model). server agent client agent client server wireless link fixed network
CIS Model • Advantages • No change to client and server code. • More design choices to place load of clients and servers to agents. • Easy to optimize transmission with specific protocol at agents. • Mask disconnection of client through agents. • Prefetching and caching at client agent to combat disconnection, which causes inaccessibility of data. • Disadvantages • Need resource-rich client. • Traffic passes through both agents. • A lot of coding needed for both agents. • Different agent pairs for different applications. • Example: IBM WebExpress provides mobile web access with an agent pair.
Peer-to-Peer Model • It is the generalized client/server model so that any client can communicate with any other client. • No distinction between client and server. • Hosts are expected to play the role of a client and a server. • Extend CIS model so that each host has a client agent and a server agent, in addition to the client code/thread and server code/thread. • Now server can also move and suffer from disconnection. • Resource-rich mobile hosts are needed. • Server thread may need to be event-driven and started on demand, perhaps similar in nature to CGI (since it could be costly to continuously run the thread on the mobile host). • Useful for cooperative applications. • Useful in an ad hoc network without centralized server.
Mobile Agent Model • Generalize server agent to allow it to move along when client moves to other MSS. It does not matter whether there is the client agent. • The result is the mobile agent, and the mobile agent model. • An mobile agent is similar to an object (with persistent state information) but is autonomous and can move. • It carries along with the computational context when migrated to another host. • Agents can be dispatched from client, to handle ad hoc requests. This is useful since agents can contain dynamic code for different needs. • Service searching by agents to appropriate server. • Agent carries back results to the client that dispatches it. • Desirable to be autonomous, able to interact with other agents, platform independent, and reactive to external events.
Mobile Agent Model • Weak mobility • Allow mobility of code and data state. • After movement, agent is restarted and values of its variables are restored. • Agent execution restarts from the beginning of a given procedure (a method in case of objects). • Can be implemented through Java serialization of object states with a call at specific point of execution and send them over via socket or RMI. • Strong mobility • Mobility of code, data state and execution state. • Restart execution exactly from the point where it was suspended before movement. • Need the support of process migration ability at OS level.
Mobile Agent Model • Advantages • Shift the processing burden from resource-poor client to fixed network or server on which agent is executed. • Reduce communication traffic over wireless link. • Support weak connection. • Tolerate network disconnection. • Agent acts on behalf of client as a surrogate when needed (intelligent agent). • Can move around for the best server. • Disadvantages • Need to develop different programs/codes for agents. • Need to be executed in specific environments for agents. • Future agents • Programmable agent to create and change behavior of other agents.
Summary mobile computing model mobile client/server model mobile peer-to-peer model mobile agent model simple client/server model client/agent/server model client/intercept/server model
Review Questions • 计算模型有什么用?