Unicamp MC714 Distributed Systems Slides by Maarten van Steen, adapted from Distributed Systems, 3rd edition Chapter 04: Communication
Revision: Revision: Threads and Distributed Systems Improve performance Starting a thread is typically much cheaper than starting a new process. Having a single-threaded server prohibits simple scale-up to a multiprocessor system. As with clients: hide network latency by reacting to next request while previous one is being replied. Better structure Most servers have high I/O demands. Using simple, well-understood blocking calls simplifies the overall structure. Multithreaded programs tend to be smaller and easier to understand due to simplified flow of control. 2 / 62
Revision: Revision: Ways of virtualization (a) Process VM, (b) Native VMM, (c) Hosted VMM Application/Libraries Application/Libraries Application/Libraries Operating system Runtime system Operating system Virtual machine monitor Operating system Virtual machine monitor Operating system Hardware Hardware Hardware (a) (b) (c) Differences (a) Separate set of instructions, an interpreter/emulator, running atop an OS. (b) Low-level instructions, along with bare-bones minimal operating system (c) Low-level instructions, but delegating most work to a full-fledged OS. 3 / 62
Revision: Revision: Servers and state Stateless servers Never keep accurate information about the status of a client after having handled a request: Don’t record whether a file has been opened (simply close it again after access) Don’t promise to invalidate a client’s cache Don’t keep track of your clients 4 / 62
Revision: Revision: Servers and state Stateless servers Never keep accurate information about the status of a client after having handled a request: Don’t record whether a file has been opened (simply close it again after access) Don’t promise to invalidate a client’s cache Don’t keep track of your clients Consequences Clients and servers are completely independent State inconsistencies due to client or server crashes are reduced Possible loss of performance because, e.g., a server cannot anticipate client behavior (think of prefetching file blocks) 4 / 62
Revision: Revision: Servers and state Stateless servers Never keep accurate information about the status of a client after having handled a request: Don’t record whether a file has been opened (simply close it again after access) Don’t promise to invalidate a client’s cache Don’t keep track of your clients Consequences Clients and servers are completely independent State inconsistencies due to client or server crashes are reduced Possible loss of performance because, e.g., a server cannot anticipate client behavior (think of prefetching file blocks) Question Does connection-oriented communication fit into a stateless design? 4 / 62
Revision: Revision: Server Clusters Common organization Logical switch Application/compute servers Distributed (possibly multiple) file/database system Dispatched request Client requests First tier Second tier Third tier Crucial element The first tier is generally responsible for passing requests to an appropriate server: request dispatching 5 / 62
Revision: Revision: Request Handling Observation Having the first tier handle all communication from/to the cluster may lead to a bottleneck. A solution: TCP handoff Logically a Response single TCP Server connection Request Request (handed off) Client Switch Server 6 / 62
Revision: Models for code migration Before execution After execution Client Server Client Server code code CS exec exec* resource resource code code REV − → exec − → exec* resource resource CS: Client-Server REV: Remote evaluation 7 / 62
Revision: Models for code migration Before execution After execution Client Server Client Server code code CoD ← − ← − exec exec* resource resource code code MA − → − → exec exec* resource resource resource resource CoD: Code-on-demand MA: Mobile agents 8 / 62
Revision: Strong and weak mobility Object components Code segment: contains the actual code Data segment: contains the state Execution state: contains context of thread executing the object’s code Weak mobility: Move only code and data segment (and reboot execution) Relatively simple, especially if code is portable Distinguish code shipping (push) from code fetching (pull) Strong mobility: Move component, including execution state Migration: move entire object from one machine to the other Cloning: start a clone, and set it in the same execution state. 9 / 62
Revision: Revis˜ ao: Exerc´ ıcios Considere um servi c ¸ o que leva um total de 10 ms para atender um 1 pedido desde que os dados necess´ arios estejam em uma cache na mem´ oria principal. Nos casos onde os dados n˜ ao est˜ ao na ¸ ˜ ao de disco que leva 90 ms ´ cache, uma opera c e necessaria antes de completar o pedido, e durante este tempo a thread que processa o pedido ´ e suspensa. Assuma que os dados est˜ ao na cache para 50% dos pedidos. Quantos pedidos por segundo o servidor pode tratar se for implementado com uma ´ unica thread? E se o servidor usar m´ ultiplas threads? Faz sentido limitar o n ´ umero de threads em um processo servidor? 2 Argumente. Existem casos onde um servidor single-thread tem desempenho 3 melhor do que um servidor multi-thread? Argumente. 10 / 62
Revision: Revis˜ ao: Exerc´ ıcios Um servidor multi-processos tem algumas vantagens e 4 desvantagens quando comparado com um servidor multi-threads. Dˆ e alguns exemplos. Um servidor que mant´ em uma conex˜ ao TCP/IP para um cliente ´ e 5 stateful ou stateless ? 11 / 62
Exercises: Exerc´ ıcios Descreva o processo de conex˜ ao entre cliente e servidor com 1 sockets TCP/IP . Diferencie comunicac ¸ ˜ ao s´ ıncrona e ass´ ıncrona, persistente e 2 transiente. Dˆ e exemplos de cada combinac ¸ ˜ ao. Descreva um problema de escalabilidade com comunicac ¸ ˜ ao 3 s´ ıncrona transiente. Qual ´ e o papel de um broker na comunicac ¸ ˜ ao orientada a 4 mensagens? 12 / 62
Exercises: Exerc´ ıcios Na Figura 4.35, qual ´ e o fator de stretch da rede de overlay na rota 5 A → C? Explique o princ´ ıpio de anti-entropia usado em protocolos 6 epidˆ emicos. Descreva o problema de remoc ¸ ˜ ao de dados em protocolos 7 epidˆ emicos e apresente uma soluc ¸ ˜ ao. Descreva um algoritmo epidˆ emico que calcule o tamanho de uma 8 rede. 13 / 62
Communication: Foundations Layered Protocols Basic networking model Application protocol Application 7 Presentation protocol Presentation 6 Session protocol Session 5 Transport protocol Transport 4 Network protocol 3 Network Data link protocol 2 Data link Physical protocol 1 Physical Network Drawbacks Focus on message-passing only Often unneeded or unwanted functionality Violates access transparency The OSI reference model 14 / 62
Communication: Foundations Layered Protocols Low-level layers Recap Physical layer: contains the specification and implementation of bits, and their transmission between sender and receiver Data link layer: prescribes the transmission of a series of bits into a frame to allow for error and flow control Network layer: describes how packets in a network of computers are to be routed. Observation For many distributed systems, the lowest-level interface is that of the network layer. The OSI reference model 15 / 62
Communication: Foundations Layered Protocols Transport Layer Important The transport layer provides the actual communication facilities for most distributed systems. Standard Internet protocols TCP: connection-oriented, reliable, stream-oriented communication UDP: unreliable (best-effort) datagram communication The OSI reference model 16 / 62
Communication: Foundations Layered Protocols Middleware layer Observation Middleware is invented to provide common services and protocols that can be used by many different applications A rich set of communication protocols (Un)marshaling of data, necessary for integrated systems Naming protocols, to allow easy sharing of resources Security protocols for secure communication Scaling mechanisms, such as for replication and caching Note What remains are truly application-specific protocols... such as? Middleware protocols 17 / 62
Communication: Foundations Layered Protocols An adapted layering scheme Application protocol Application Middleware protocol Middleware Host-to-host protocol Operating system Physical/Link-level protocol Hardware Network Middleware protocols 18 / 62
Communication: Foundations Types of Communication Types of communication Distinguish... Synchronize at� Synchronize at � Synchronize after� request submission request delivery processing by server Client Request � Transmission� interrupt Storage� facility Reply Server Time Transient versus persistent communication Asynchronous versus synchronous communication 19 / 62
Recommend
More recommend
