1 / 37

Computer Science 425 Distributed Systems

Computer Science 425 Distributed Systems. Lecture 14 NETWORKING – Part III, RPCs, etc. People: many identifiers: SSN, name, Passport # Internet hosts, routers: IP address (32 bit) - used for addressing datagrams Resource “name”, e.g., URL sal.cs.uiuc.edu – human-readable format

jesse
Download Presentation

Computer Science 425 Distributed Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Computer Science 425Distributed Systems Lecture 14 NETWORKING – Part III, RPCs, etc.

  2. People: many identifiers: SSN, name, Passport # Internet hosts, routers: IP address (32 bit) - used for addressing datagrams Resource “name”, e.g., URL sal.cs.uiuc.edu – human-readable format Q: given a resource name, how does a client find out the IP address of the service/server? Domain Name System: distributed database implemented in a hierarchy of many name servers application-layer protocol that is responsible for resolving names (address/name translation) DNS: Domain Name System

  3. Alternative no server has all name-to-IP address mappings Hierarchy of name servers authoritative name server: for a resource, stores the mapped IP address for that resource local name servers: each institution/company/ISP owns a local (default) name server host DNS query first goes to local name server local name server might be caching an answer Why not have a central DNS server? single point of failure traffic volume may be far maintenance difficult doesn’t scale! (WWW contains several billion pages today) DNS Name Servers

  4. contacted by local name server that can not resolve name root name server: contacts authoritative name server if name mapping not known gets mapping returns mapping to local name server ~ dozen root name servers worldwide (as of ’98) DNS: Root Name Servers

  5. host surf.eurecom.fr wants IP address of dragon.cs.uiuc.edu 1. Contacts its local DNS server, dns.eurecom.fr 2.dns.eurecom.fr contacts root name server, if necessary 3. root name server contacts authoritative name server, dns.cs.uiuc.edu, if necessary Answer returned by first server that is caching the mapping tuple local name server dns.eurecom.fr Simple DNS Example root name server 2 4 3 5 authoritative name server dns.cs.uiuc.edu 1 6 requesting host surf.eurecom.fr dragon.cs.uiuc.edu

  6. Root name server: may not know the authoritative name server may know intermediate name server: whom to contact to find authoritative name server Hierarchy . .edu .com .mil … uiuc.edu mit.edu… local name server dns.eurecom.fr intermediate name server dns.uiuc.edu DNS Example root name server 6 2 3 7 5 4 1 8 authoritative name server dns.cs.uiuc.edu requesting host surf.eurecom.fr dragon.cs.uiuc.edu

  7. recursive query: puts burden of name resolution on servers along the way may fail if a server does not know next server to contact iterated query: contacted server replies with name of server to contact “I don’t know this resource name, but ask this other server” takes longer (more replies) but gives client more control local name server dns.eurecom.fr intermediate name server dns.uiuc.edu DNS: Iterated Queries root name server iterated query 2 3 4 7 5 6 1 8 authoritative name server dns.cs.uiuc.edu requesting host surf.eurecom.fr dragon.cs.uiuc.edu

  8. once (any) name server learns mapping, it caches mapping cache entries timeout (disappear) after some time update/notify mechanisms RFC 2136 http://www.ietf.org/html.charters/dnsind-charter.html Akamai uses this extensively DNS: Caching and Updating Records

  9. Firewalls • A set of processes that monitor & control all comm. into and out of an intranet, for: • Service control • Behavior control • User control • Firewall filtering can be done at diff. levels of protocol stack • IP packet filtering • E.g., disallow packets from certain IP addresses • TCP gateway filtering • E.g., check format of TCP packets to avoid attacks using malformed TCP packets • Application gateway filtering • E.g., web proxy

  10. Firewall Configurations • For efficiency reasons, IP filtering • done in kernel • Separated from other filtering TCP and appl filtering • - Hosts in intranet • need not know IP addresses of • hosts in external network, • and vice-versa • Double-walled protection

  11. Summary Structure of the Internet • Protocol stacks (e.g., OSI 7 layer, 5 layer) • IP packet format • ARP, DNS • Routing algorithms – distance vector, link state, proactive, reactive • TCP • Firewalls Structure constantly evolving with new networks and standards (e.g., data over cellphones, IPv6)

  12. Computer Science 425Distributed Systems Lecture 14 Inter-process Communication & Distributed Objects (I) Sections 4.3-4.4, Chapter 5

  13. Search in Chord What are “RPCs”? At node n, send query for key k to largest successor/finger entry < k if none exist, return successor(n) to requestor Say m=7 0 N16 N112 All “arrows” are RPCs N96 N32 Who has bad.mp3? (hashes to K42) File bad.mp3 with key K42 stored here N45 N80

  14. Bank Database Example How are “transactions” executed between a client ATM and a bank server? • Bank Database: Think of two simultaneous deposits of $10,000 into your bank account, each from one ATM. • Both ATMs read initial amount of $1000 concurrently from the bank server • Both ATMs add $10,000 to this amount (locally at the ATM) • Both write the final amount to the server • What’s wrong? • The ATMs need mutually exclusive access to your account entry at the server

  15. Bank Database Example How is your bank account variable replicated (and maintained) among the multiple bank servers? • Bank Database: Think of two simultaneous deposits of $10,000 into your bank account, each from one ATM. • Both ATMs read initial amount of $1000 concurrently from the bank server • Both ATMs add $10,000 to this amount (locally at the ATM) • Both write the final amount to the server • What’s wrong? • The ATMs need mutually exclusive access to your account entry at the server

  16. Applications RPCs and RMIs, e.g., CORBA Middleware Request reply protocol layers= Provide support to the application External data representation Operating System Middleware Layers RMI=Remote Method Invocation CORBA=Common Object Request Brokerage Architecture

  17. Local Objects • Object • consists of a set of data and a set of methods. • E.g., C++ object such as the Chord object (Chord data structures + functions at a node). • Object reference • an identifier via which objects can be accessed. • i.e., a pointer • Interface • provides a definition of the signatures of a set of methods (i.e., the types of their arguments, return values, and exceptions) without specifying their implementation. • E.g., put(objectname), get(objectname) API for Chord object. Same API also applies to other objects such as Gnutella, Kazaa, etc.

  18. Remote Objects • Remote method invocation • method invocations between objects in different processes (processes may be on the same or different host). • Variant of Remote Procedure Call (RPC), which is between different processes (may be on same or different host) • Remote objects • objects that can receive remote invocations. • Remote object reference • an identifier that can be used globally throughout a distributed system to refer to a particular unique remote object. • Remote interface • Every remote object has a remote interface that specifies which of its methods can be invoked remotely. E.g., CORBA interface definition language (IDL)

  19. remote object Data remote interface m4 { m1 implementation m5 m2 m6 of methods m3 A Remote Object and Its Remote Interface Example Remote Object reference=(IP,port,objectnumber,signature,time)

  20. local C remote E local invocation invocation remote invocation invocation F B local A invocation D Remote and Local Method Invocations Process Object Process Process Host A Host B Local invocation=between objects on same process. Has exactly oncesemantics Remote invocation=between objects on different processes. Ideally also want exactly once semantics for remote invocations But difficult (why?)

  21. Failure Modes of RMI/RPC (and if request is received more than once?) Request Execute lost request correct function Reply Channel fails during reply Execute Request Execute, Crash crash before reply Reply Client machine fails before receiving reply Request Execute Crash crash before execution Reply

  22. Invocation Fault tolerance measures semantics Retransmit request Duplicate Re-execute procedure message filtering or retransmit reply No Not applicable Not applicable Maybe Yes No Re-execute procedure At-least-once Yes Yes Retransmit reply At-most-once Transparency=remote invocation has same behavior as local invocation [Birrell and Nelson, inventors of RPC, 1984] Very difficult to implement in asynchronous network… Invocation Semantics whether to keep a history of result messages to enable lost results to be retransmitted without re-executing the operations Whether or not to retransmit the request message until either a reply is received or the server is assumed to be failed when retransmissions are used, whether to filter out duplicate requests at the server. CORBA (ok for idempotentoperations) Sun RPC Java RMI, CORBA Idempotent=same result if applied repeatedly

  23. server client remote skeleton object A proxy for B object B & dispatcher Request for B’s class Reply Remote reference Communication Communication Remote module reference module module module Proxy and Skeleton in Remote Method Invocation Process P2 Process P1 MIDDLEWARE

  24. server client remote skeleton object A proxy for B object B & dispatcher Request for B’s class Reply Remote reference Communication Communication Remote module reference module module module Proxy and Skeleton in Remote Method Invocation Process P2 (“server”) Process P1 (“client”)

  25. Remote Reference Module • Is responsible for translating between local and remote object references and for creating remote object references. • Has a remote object table • An entry for each remote object held by any process. E.g., B at P2. • An entry for each local proxy. E.g., proxy-B at P1. • When a new remote object is seen by the remote reference module, it creates a remote object reference and adds it to the table. • When a remote object reference arrives in a request or reply message, the remote reference module is asked for the corresponding local object reference, which may refer to either a proxy or to a remote object. • In case the remote object reference is not in the table, the RMI software creates a new proxy and asks the remote reference module to add it to the table.

  26. Proxy • Is responsible of making RMI transparent to clients by behaving like a local object to the invoker. • The proxy implements (Java term, not literally) the methods in the interface of the remote object that it represents. But,… • Instead of executing an invocation, the proxy forwards it to a remote object. • Each method of the proxy marshals the following into a request message: (i) a reference to the target object, (ii) its own method id and (iii) the argument values. Request message is sent to the target, then proxy awaits the reply message, un-marshals it and returns the results to the invoker.

  27. Marshalling & Unmarshalling • External data representation: an agreed, platform-independent, standard for the representation of data structures and primitive values. • CORBA Common Data Representation (CDR) • Allows a Windows client (little endian) to interact with a Unix server or Mac server (big endian). • Marshalling: the act of taking a collection of data items (platform dependent) and assembling them into the external data representation (platform independent). • Unmarshalling: the process of disassembling data that is in external data representation form, into a locally interpretable form.

  28. What about Server Side? Dispatcher and Skeleton • Each process has one dispatcher, and a skeleton for each local object (actually, for the class). • The dispatcher receives all request messages from the communication module. • For the request message, it uses the method id to select the appropriate method in the appropriate skeleton, passing on the request message. • Skeleton “implements” the methods in the remote interface. • A skeleton method un-marshals the arguments in the request message and invokes the corresponding method in the remote object (the actual object). • It waits for the invocation to complete and marshals the result, together with any exceptions, in a reply message.

  29. Remote Method Invocation (RMI) Client Process Proxy object is a hollow container of Method names. Remote Reference Module translates between local and remote object references. Proxy Object B Object A Remote Reference Module Comm. Module Server Process Dispatcher sends the request to Skeleton Object Skeleton unmarshals parameters, sends it to the object, & marshals the results for return Remote Reference Module Comm. Module Dispatcher Object B Skeleton for B’s Class MIDDLEWARE

  30. Generation of Proxies, Dispatchers and Skeletons • In CORBA, programmer specifies interfaces of remote objects in CORBA IDL; then, the interface compiler automatically generates code for proxies, dispatchers and skeletons. • In Java RMI • The programmer defines the set of methods offered by a remote object as a Java interface implemented in the remote object. • The Java RMI compiler generates the proxy, dispatcher and skeleton classes from the class of the remote object.

  31. Binder and Activator • Binder: A separate service that maintains a table containing mappings from textual names to remote object references. (sort of like DNS, but for the specific middleware) • Used by servers to register their remote objects by name. Used by clients to look them up. E.g., Java RMI Registry, CORBA Naming Svc. • Activation of remote objects • A remote object is active when it is available for invocation within a running process. • A passive object consists of (i) implementation of its methods; and (ii) its state in the marshalled form (a form in which it is shippable). • Activation creates a new instance of the class of a passive object and initializes its instance variables. It is called on-demand. • An activator is responsible for • Registering passive objects (recording the names of the servers against the names of the passive objects) • Starting named server processes and activating remote objects in them. • Keeping track of the locations of the servers for remote objects it has already activated • E.g., Activator=Inetd, Passive Object/service=FTP (invoked on demand)

  32. Etc. • Persistent Object = an object that survives between simultaneous invocation of a process. E.g., Persistent Java, PerDIS, Khazana. • If objects migrate, may not be a good idea to have remote object reference=IP+port • Location service= maps a remote object reference to its likely current location • Allows the object to migrate from host to host, without changing remote object reference • Example: Akamai is a location service for web objects. It “migrates” web objects using the DNS location service

  33. MP1 and Midterm

  34. MP1 – richftp : concurrent file transfer (at each host) Application layer app_result richftp_get richftp_put richftp_abort richftp layer MP1 network sockets

  35. MP1 – richftp • richftp_get and richftp_put : enqueue request and return a requestid (nonblocking ftp requesting processing) • request is handed off to a special thread • thread contacts server thread to transfer file • when complete, richftp layer calls app_result • Application layer at client may call richftp_abortftp to stop file transfer at any time • You are given template code with all interfaces and everything, but… • Your job is to implement the richftp layer. • All code that you add in has to be your own. We will look through your code. • We will test your code automatically by replacing the entire Application layer (so do not change anything in this layer) • More details in MP1 handout…

  36. Miderms Distribution

  37. Midterm Statistics • Midterm back. High : • 94.67/100 (grads) • 90.33/100 (undergrads) • Count: 40 (22 UG, 18 G) • Low: 47 • Median: 81.28 (72.33 UG, 84.29 G) • Mean: 78.57 (73.14 UG, 84.89 G) • Std. Dev: 11.25 (11.56 UG, 7.71 G) • Reading for next lecture: Sections 4.3-4.4, Chapter 5, Sections 13.1-13.3.

More Related