Centralized Architectures

Slides:



Advertisements
Similar presentations
1 Communication in Distributed Systems REKs adaptation of Tanenbaums Distributed Systems Chapter 2.
Advertisements

Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved DISTRIBUTED SYSTEMS.
Remote Procedure CallCS-4513, D-Term Remote Procedure Call CS-4513 Distributed Computing Systems (Slides include materials from Operating System.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved DISTRIBUTED.
ECE 4450:427/527 - Computer Networks Spring 2015 Dr. Nghi Tran Department of Electrical & Computer Engineering Lecture 8: Application Layer Dr. Nghi Tran.
Distributed Systems Spring 2009
Application Layer 2-1 Chapter 2 Application Layer Computer Networking: A Top Down Approach 6 th edition Jim Kurose, Keith Ross Application Layer – Lecture.
Tutorials 2 A programmer can use two approaches when designing a distributed application. Describe what are they? Communication-Oriented Design Begin with.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved DISTRIBUTED SYSTEMS.
Outcomes What is RPC? The difference between conventional procedure call and RPC? Understand the function of client and server stubs How many steps could.
McGraw-Hill©The McGraw-Hill Companies, Inc., 2004 Application Layer PART VI.
1 School of Computing Science Simon Fraser University CMPT 771/471: Internet Architecture and Protocols Socket Programming Instructor: Dr. Mohamed Hefeeda.
Introduction to the Application Layer Computer Networks Computer Networks Spring 2012 Spring 2012.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved DISTRIBUTED SYSTEMS.
16: Distributed Systems1 DISTRIBUTED SYSTEM STRUCTURES NETWORK OPERATING SYSTEMS The users are aware of the physical structure of the network. Each site.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved DISTRIBUTED SYSTEMS.
Introduction 1 Lecture 5 Application Layer slides are modified from J. Kurose & K. Ross University of Nevada – Reno Computer Science & Engineering Department.
An adapted reference model for networked communication.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved DISTRIBUTED SYSTEMS.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved DISTRIBUTED SYSTEMS.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved DISTRIBUTED SYSTEMS.
Chapter 2 Application Layer Computer Networking: A Top Down Approach, 5 th edition. Jim Kurose, Keith Ross Addison-Wesley, April A note on the use.
Chapter 2, slide: 1 CS 372 – introduction to computer networks* Monday June 28 Announcements: r Lab 1 is due today r Lab 2 is posted today and is due next.
2: Application Layer1 Chapter 2 Application Layer These slides derived from Computer Networking: A Top Down Approach, 6 th edition. Jim Kurose, Keith Ross.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved DISTRIBUTED SYSTEMS.
Throughput: Internet scenario
Application Layer 2-1 Chapter 2 Application Layer Computer Networking: A Top Down Approach 6 th edition Jim Kurose, Keith Ross Addison-Wesley March 2012.
Introduction to Distributed Systems Slides for CSCI 3171 Lectures E. W
What makes a network good? Ch 2.1: Principles of Network Apps 2: Application Layer1.
Communication Tran, Van Hoai Department of Systems & Networking Faculty of Computer Science & Engineering HCMC University of Technology.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved Chapter 4 Communication.
1 Distributed Systems : Inter-Process Communication (Multicast communication) Dr. Sunny Jeong. With Thanks to Prof.
2: Application Layer 1 Chapter 2: Application layer r 2.1 Principles of network applications r 2.2 Web and HTTP r 2.3 FTP r 2.4 Electronic Mail  SMTP,
Introduction to Distributed Systems Slides for CSCI 3171 Lectures E. W. Grundke.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved DISTRIBUTED.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved DISTRIBUTED SYSTEMS.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved DISTRIBUTED SYSTEMS.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved Architectures.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved DISTRIBUTED SYSTEMS.
DISTRIBUTED SYSTEMS Principles and Paradigms Second Edition ANDREW S
Synchronization. Why we need synchronization? It is important that multiple processes do not access shared resources simultaneously. Synchronization in.
3.1 Silberschatz, Galvin and Gagne ©2009Operating System Concepts with Java – 8 th Edition Chapter 3: Processes.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved RPC Tanenbaum.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved DISTRIBUTED SYSTEMS.
Application Layer 2-1 Chapter 2 Application Layer Computer Networking: A Top Down Approach 6 th edition Jim Kurose, Keith Ross Addison-Wesley March 2012.
Synchronization Chapter 5.
 Communication Distributed Systems IT332. Outline  Fundamentals  Layered network communication protocols  Types of communication  Remote Procedure.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved DISTRIBUTED SYSTEMS.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved DISTRIBUTED SYSTEMS.
1 Conventional Procedure Call read(fd,buf,nbytes) a)Parameter passing in a local procedure call: the stack before the call to read b)The stack while the.
Synchronization CSCI 4900/6900. Importance of Clocks & Synchronization Avoiding simultaneous access of resources –Cooperate to grant exclusive access.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved DISTRIBUTED SYSTEMS.
DISTRIBUTED SYSTEMS Principles and Paradigms Second Edition ANDREW S
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved DISTRIBUTED SYSTEMS.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved DISTRIBUTED SYSTEMS.
Synchronization Chapter 5. Clock Synchronization When each machine has its own clock, an event that occurred after another event may nevertheless be assigned.
COMP 655: Distributed/Operating Systems Summer 2011 Dr. Chunbo Chu Week 6: Synchronyzation 3/5/20161 Distributed Systems - COMP 655.
6.2 Logical Clocks Kranthi Koya09/23/2015. Overview Introduction Lamport’s Logical Clocks Vector Clocks Research Areas Conclusion.
1 K. Salah Application Layer Module K. Salah Network layer duties.
OS2-Sharif University of Technology - Sem ; R. Jalili Communication Chapter 2.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved DISTRIBUTED SYSTEMS.
Introduction to Distributed Systems Slides for CSCI 3171 Lectures E. W. Grundke.
DISTRIBUTED SYSTEMS Principles and Paradigms Second Edition ANDREW S
DISTRIBUTED SYSTEMS Principles and Paradigms Second Edition ANDREW S
Communication Chapter 2.
DISTRIBUTED SYSTEMS Principles and Paradigms Second Edition ANDREW S
Outline Communication Primitives - continued Theoretical Foundations
DISTRIBUTED SYSTEMS Principles and Paradigms Second Edition ANDREW S
ECE 4450:427/527 - Computer Networks Spring 2017
Outline Theoretical Foundations
Presentation transcript:

Centralized Architectures Figure 2-3. General interaction between a client and a server. What to do with lost message? idempotent = possible to resend message without harm, e.g., read account

Server design issues Server organization Iterative Concurrent Multithreaded Fork (unix) Stateless or stateful Client contact: End point (port) Well-known Dynamic: daemon; superserver (unix) Stateless = no info kept about the state of clients If info lost does not lead to disrutpion of the server’s service (important) Alternatvie: soft state: promise to follow state for limited time, for example inform client about updates to a resource Stateful: persistent info on its clients - info must be explicitly deleted by the server . Example: file server allows clients to keep local copy of files and also update them locally (table with client-file entries) However, if server crashes, it has to recover the table!

End Point, General Design Issues (1) Exempel: time-of-day, som behöver vara uppe konstant Klienten måste först leta upp end point-adress - speciell daemon som håller reda på aktuella adresser till tjänster daemon själv finns på en well-known port Figure 3-11. (a) Client-to-server binding using a daemon.

End Point, General Design Issues (2) Figure 3-11. (b) Client-to-server binding using a superserver. Exempel: inetd i unix = the server process for the Internet standard services /etc/inetd.conf innehåller en lista på tjänsterna: ftp, echo, telnet, finger lyssnar på tcp- och udp-portarna efter anrop slöseri med resurser att implementera varje tjänst med en specifik server I unix finns t.ex. massvis med servrar som körs samtidigt, många är passivt väntande - använder istället en superserver, som lyssnar på alla portar som är aktuella inetd exempelvis är en sådan superserver När en request kommer, gör inetd fork och skapar en annan process

Server Clusters (1) Figure 3-12. The general organization of a three-tiered server cluster. 3-tiered Tier 1 = logical switch (the access point to the cluster; can be replicated) example: tcp switch or http switch - dns can be used to return several addresses for the same host name, if using several access points to increase availability Tier 2: high-performance computers, most often single service (stream movie) Tier 3: data-processing, sometimes included in tier 2, disk access, cache Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5

Server Clusters (2) Figure 3-13. The principle of TCP handoff. The switch in tier 1: Spoof source ip when server is responding (looks like it comes form the switch) Requires OS-level modifications Load-balancing = round-robin Or more advanced: distinguish between diff port numbers Or examine http contents (context-aware request distribution) Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5

Sockets: Processes in different hosts communicating TCP with buffers, variables socket host or server process TCP with buffers, variables socket host or server process sends/receives messages to/from its socket socket analogous to door sending process shoves message out door sending process relies on transport infrastructure on other side of door which brings message to socket at receiving process controlled by app developer Internet controlled by OS Process: program running within a host. within same host, two processes communicate using inter-process communication (defined by OS). processes in different hosts communicate by exchanging messages Client process: process that initiates communication Server process: process that waits to be contacted Note: applications with P2P architectures have client processes & server processes Addressing processes - to receive messages, process must have identifier host device has unique 32-bit IP address Q: does IP address of host on which process runs suffice for identifying the process? A: No, many processes can be running on same host identifier includes both IP address and port numbers associated with process on host. Example port numbers: HTTP server: 80 Mail server: 25 to send HTTP message to gaia.cs.umass.edu web server: IP address: 128.119.245.12 Port number: 80 0-1023 well-known port numbers API: (1) choice of transport protocol; (2) ability to fix a few parameters. How to address processes? 2009-08-28 TDTS04 Lecture 2: Application layer and transport

Berkeley Sockets Figure 4-14. The socket primitives for TCP/IP. varför sockets? enkelt sätt att rpogrammera nätapplikationer på om man vill programmera närmare nätet än vad rpc tillåtter - måste känna till hur tcp och udp fungerar (ström versus paket) Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5

Connection-oriented socket (tcp) Figure 4-15. Connection-oriented communication pattern using sockets. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5

Clock Synchronization I ett centralierat system är tiden otvetydigt definierad via central klocka – anropa kernel Figuren: Viktigt för make-programmet i unix, så att man omkompilerar alla källkodsfiler som har ändrats efter senaste kompileringen (titta på objektfilernas tidsstämpel och jämför) Andra exempel: Aktiehandel, övervaka händelser vid säkerhetsövervakning – fler exempel? Figure 6-1. When each machine has its own clock, an event that occurred after another event may nevertheless be assigned an earlier time.

Physical Clocks (2) Klockan är egentligen en timer i datorn Kvartskristall som svänger med viss frekvens, varierar fårn dator till dator över tiden = skevande klockor Två register: räknare och hpållningsregister: varje svängning minskar räknaren med ett, när den når noll genereras en interrupt (ett klocktick) och räknarens återställs till ursprungsvärdet från hållningsregistret Datum och tid sparas i CMOS-RAM-minnet, ett speciellt batteriförsett minne bredvid CPU:n. Figuren: Sedan 1948 finns atomur med cesium 133 där man har definienrat en sekund som 9 192 631 770 övergångar hos cesium-133-atomen = 1 genomsnittlig solsekund – dess atomur finns hos laboratorier i världen och rapporterar till BIH i Paris, som tar medelvärdet och procuderar TAI = International Atomic Time Stämmer ej exakt med verkligheten eftersom jorden roterar allt långsammare; just nu är TAI ca 3 msec efter  måste införa skottsekunder med jämna mellanrum (när skillnaden är 800 msec till verkligheten)  detta system kalla UTC, Universal Coordinated Time (obs. förkortningen fransk!) - finns på kortvågsradion som WWV +/- 10 msec eller satellit 0,5 msec korrekt Figure 6-3. TAI seconds are of constant length, unlike solar seconds. Leap seconds are introduced when necessary to keep in phase with the sun.

Lamport’s Logical Clocks (1978)(1) The "happens-before" relation → can be observed directly in two situations: If a and b are events in the same process, and a occurs before b, then a → b is true. If a is the event of a message being sent by one process, and b is the event of the message being received by another process, then a → b - Leslie Lamport:reserach.microsoft.com/~lamport Ofta tillr’ckligt att noderan endast är överens om en gemensam tid, vilken som helst och ej nödvändigtvis den absoluta tiden i verkligheten t.ex för make behöver två noder endast komma vöerens om en fil är äldre än en anna fil  behöver endast hålla reda på vad de två noderna har utfört (skrivit i källkodsfil etc.) och när  använd logisk klocka för relativ tid mellan de två noderna = lamports logiska klockor  senare utvidgning: vektorklockor/tidsstämplar Figuren Ett meddelande kan inte tas emot av en process I förrän det har skickats av process J, ej ens på samma tid (nätet har fördräjning)

Lamport’s Logical Clocks (2) Figure 6-9. (a) Three processes, each with its own clock. The clocks run at different rates. Mät tid genom att låta varje nod ha sin egen klocka med sin egen hastighet (olika antal tick per sekund) Tavla: klockan i varje nod måste ha egenskpaen att de alltid räknas upp, aldirg ned + korrigeringar av tiden är alltid additioner, aldrig subtraktioner och, så att Om ab så gäller C(a) < C(b) - samma gäller för en nod I som skickar ett meddelande vid tiden C(a) och processen J tar emot medd vid tiden c(b) så gäller C(a) < C(b) Figuren: klockan tickar 6 i P1, 8 i P2 och 10 i P3 + fyra medd skickas och tas emot - Medd innehåller varje process tidsstämpel från när de skickades

Lamport’s Logical Clocks (3) När en process tar emot ett medd så måste dess tidsstämpel följa egenskaperna för C(a) och C(b) P2 korrigerar sin tid när den ser P3 medd m3 med plus-ett - P1 korrigerar sin tid efter m4 från P2 med plus-ett Figure 6-9. (b) Lamport’s algorithm corrects the clocks.

Lamport’s Logical Clocks (4) Figure 6-10. The positioning of Lamport’s logical clocks in distributed systems.

Lamport’s Logical Clocks (5) Updating counter Ci for process Pi Before executing an event Pi executes Ci ← Ci + 1. When process Pi sends a message m to Pj, it sets m’s timestamp ts (m) equal to Ci after having executed the previous step. Upon the receipt of a message m, process Pj adjusts its own local counter as Cj ← max{Cj , ts (m)}, after which it then executes the first step and delivers the message to the application. En nod ökar tiden med 1 när en händelse inträffar (händelse = skicka medd, ta emot medd, etc.) Mottagande nod sätter tiden till max av medd tidsstämpel och den egna tiden och ökar sedan sin egen tid med 1

Middleware Protocols Figure 4-3. An adapted reference model for networked communication. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5

Types of Communication Figure 4-4. Viewing middleware as an intermediate (distributed) service in application-level communication. persistent kommunikation = medd som har skickats lagras av sändnings-middleware tills det kommer fram till mott sändaren behöver inte vänta på svar utan kan fortsätta med annat transient kommunikation = medd lagras av middleware endast så länge som sändare och mottagare är online och exekverar om det blir fel i transporten så förloras medd eller om mott saknas/ej online asynkront = sändaren fortsätter med annat direkt efter att ha sänt medd synkront = sändaren blockeras (måste vänta på svar) tills medd accepterats av middleware – tre ställen möjliga för blockning: medd mottagits av middlware medd levererats (till servern) mott svarat (bearbetat förfrågan) Vanliga kombinationer: persistens + synkronisera vid middleware (meddelandekösystem) - transient + synkronisera vid svar Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5

Client and Server Stubs vanligt anrop = read-funktionen länkas av länkaren till read-systemanropet (enkel rutin) RPC = read-fkn länkas till klientstubbe + anropar också OS, men begär inte OS om data, utan istllet packar stubben ihop parametrarna i ett litet paket inklusive funktionsnamnet och ber OS att sända meddelandet till mottagande server där funktionen finns Figure 4-6. Principle of RPC between a client and server program. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5

Remote Procedure Calls (1) A remote procedure call occurs in the following steps: The client procedure calls the client stub in the normal way. The client stub builds a message and calls the local operating system. The client’s OS sends the message to the remote OS. The remote OS gives the message to the server stub. The server stub unpacks the parameters and calls the server. Continued … Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5

Remote Procedure Calls (2) A remote procedure call occurs in the following steps (continued): The server does the work and returns the result to the stub. The server stub packs it in a message and calls its local OS. The server’s OS sends the message to the client’s OS. The client’s OS gives the message to the client stub. The stub unpacks the result and returns to the client. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5

Passing Value Parameters (1) Figure 4-7. The steps involved in a doing a remote computation through RPC. parameternedpackning och uppackning = marshalling/unmarshalling kan ta tid att göra I java = serializinge/seralisera objekt; göra dem överförbara över nätet t.ex. tala om hur många byte en integer eller float är, hur de representeras (ebcdic, ascii eller ngn iso-standard) Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5

Asynchronous RPC (2) Figure 4-10. (b) The interaction using asynchronous RPC. asynkron rpc Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5

Asynchronous RPC (3) Figure 4-11. A client and server interacting through two asynchronous RPCs. Här: två asynkrona anrnop (ett från klienten, ett från servern)( - t.ex. hämta nätadresser till en mängd klienter först, för ett kommande anrop av dem i ett program; gära andra saker under tiden Detta kallas (figuren) deferred syncrhonous rpc = kombinera två¨asynkrona rpc-anrop - alternativ: klienten kan polla servern om svar har blivit klart än finns även One-way rpc = klienten väntar ej på Accept request från servern i början (kan ge problme om nätet ej är pålitligt; klienten vet ej säkert om begäran har mottagits av servern coh att servern arbetar med den) Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5