1 / 75

Communication essentials

Communication essentials. Communication patterns Communication structure: OSI reference model and TCP/IP coverage Major middleware communication services RPC RMI http I hate to wait … Message passing (skip) Streams. Communication patterns. Producer. Consumer. query. response.

haig
Télécharger la présentation

Communication essentials

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. Communication essentials • Communication patterns • Communication structure: OSI reference model and TCP/IP coverage • Major middleware communication services • RPC • RMI • http • I hate to wait … • Message passing • (skip) Streams Distributed Systems - Comp 655

  2. Communication patterns Producer Consumer query response Distributed Systems - Comp 655

  3. Communication patterns with broker Consumer 1 Producer 1 Subscription service Consumer 2 Producer 2 Consumer 3 query Server 1 Request broker Client 1 query response Server 2 Client 2 response Server 3 Distributed Systems - Comp 655

  4. Communication patterns -other variations • Blocking or non-blocking • Connection-based or connectionless • Transient or persistent Examples: • blocking transient query-response == RPC • non-blocking persistent producer/consumer == message queuing Distributed Systems - Comp 655

  5. A note about blocking • Blocking communication blocks the thread that makes the call • Other work may continue in other threads in the same process • More about threads and processes next week Distributed Systems - Comp 655

  6. Communication essentials • Communication patterns • Communication structure: OSI reference model and TCP/IP coverage • Major middleware communication services • RPC • RMI • http • I hate to wait … • Message passing Distributed Systems - Comp 655

  7. OSI Reference Model TCP/IP HTTP, FTP, … 2-1 not used not used TCP, UDP connectionless IP e.g. Ethernet sending bits Distributed Systems - Comp 655

  8. Middleware Protocols 2-5 RPC RMI Distributed Systems - Comp 655

  9. Where does http fit? • Originally, it looked like an application-level protocol, where the application was fetching and viewing HTML pages • As the Web has matured, it has been used increasingly as middleware. • It’s the foundation for • Web applications • Web services Distributed Systems - Comp 655

  10. Communication essentials • Communication patterns • Communication structure: OSI reference model and TCP/IP coverage • Major middleware communication services • RPC • RMI • http • I hate to wait … • Message passing Distributed Systems - Comp 655

  11. RPC is all about • Allowing a client to make a procedure call that is processed on a remote machine • Without the client’s having to care (much) Distributed Systems - Comp 655

  12. 2.3 0.98 Ordinary procedure call process caller callee (callee is atanh) Distributed Systems - Comp 655

  13. 0.98 0.98 client stub server stub message Atanh, 0.98 RPC: call the procedure across a network client process server process caller callee network Distributed Systems - Comp 655

  14. 2.3 2.3 client stub server stub message OK, 2.3 RPC: call the procedure across a network client process server process caller callee network Distributed Systems - Comp 655

  15. RPC Summary • client stub pretends to be the callee client process server process • server stub pretends to be the caller • caller and callee are written as if they were on the same machine caller callee client stub server stub • location transparency!! (almost) network Distributed Systems - Comp 655

  16. Warning: passing parameters and results can be tricky Distributed Systems - Comp 655

  17. Passing Value Parameters (1) Distributed Systems - Comp 655

  18. Passing Value Parameters (2) • Original message (JILL, 5) on the Pentium (little endian) • The message after receipt on the SPARC (big endian) • The message after being inverted. The little numbers in boxes indicate the address of each byte Number is backwards String is backwards Distributed Systems - Comp 655

  19. Conclusion from the byte order problem • You have to explicitly define your interfaces. • This problem is one of the fundamental motivators for the use of Interface Definition Languages (IDL) • Passing value parameters is a key component of access transparency. Distributed Systems - Comp 655

  20. Interface definition Interface definitions are critical factors in • Openness • Flexibility • Access transparency • Enabling proxy construction in middleware Distributed Systems - Comp 655

  21. Activity – what can go wrong?(with an RPC) Brainstorm things that can go wrong when a program on machine A tries to make an RPC to a server on machine B Network A B Distributed Systems - Comp 655

  22. Pick the top three • The instructor will pick some of the failures you brainstormed • Multi-vote on the ones in whose solutions you are most interested • You will use the top three vote-getters in the next activity Distributed Systems - Comp 655

  23. Activity – what could you do about it? Brainstorm approaches to dealing with the top three failure modes Network A B Distributed Systems - Comp 655

  24. Communication patterns -reminder Parameters: • Query-response or producer-consumer • Blocking or non-blocking • Connection-based or connection-less • Persistent or transient Examples: • blocking transient query-response == RPC • non-blocking persistent producer/consumer == message queuing Distributed Systems - Comp 655

  25. Finding the server or peer • In all cases, the process that initiates a communication has to find the process it wants to communicate with • The address could be in • Source code (simplest, least flexible) • Configuration file • A network directory service (requires client to know a name for a server) (e.g. DNS) • A series of directories (e.g. LDAP, then RMI Registry) • Interaction with the directory is usually blocking request/response Distributed Systems - Comp 655

  26. Communication essentials • Communication patterns • Communication structure: OSI reference model and TCP/IP coverage • Major middleware communication services • RPC • RMI • http • I hate to wait … • Message passing Distributed Systems - Comp 655

  27. Focus on Remote Objects • Here, object == state + methods + interface • Usually, only the interface is distributed • “Remote objects” refers to approaches in which, for each object there is some server where all of it state resides Distributed Systems - Comp 655

  28. Distributed Objects • Common organization of a remote object with client-side proxy. 2-16 Distributed Systems - Comp 655

  29. Basic Java RMI Interface.class _Stub.class * • Server registers its name and remote object • Client gets reference to remote object from rmiregistry • Client calls server Client 2. rmiregistry** 3. * = not needed if Client and Server are both Java 1.5 or newer 1. Server ** = RMI Registry can be a separate process or an object inside the Server process. If separate, must be on same machine. Interface.class _Skel.class * Distributed Systems - Comp 655

  30. Passing objects around … • In RMI, parameters and return values can be object references • If the parameter refers to a local object, do you copy the object or pass only a reference? • If the parameter refers to a remote object, what do you pass? Distributed Systems - Comp 655

  31. Local, remote objects in Java RMI • Local objects are passed by value • Remote objects by reference • Passing a remote object by reference means passing a proxy by value Distributed Systems - Comp 655

  32. Parameter Passing in RMI Distributed Systems - Comp 655

  33. http • Communication patterns: • Transient • Query/response • But, http does NOT simulate a procedure call • Non-blocking (officially) • Many clients choose to block • HTTP 1.1 is defined in RFC 2616 • Depends on TCP for reliable communication Distributed Systems - Comp 655

  34. Steps in an HTTP interaction • Client requests TCP connection • Client and server collaborate to create a TCP connection • Client sends an HTTP request • Server sends a response • TCP connection torn down • In HTTP 1.1, connection can be kept alive Distributed Systems - Comp 655

  35. method request URI protocol headers content Anatomy of an HTTP request POST /don/demo HTTP/1.1 accept: */* accept-language: en-us referer: http://localhost:8080/don/echoclient.htm content-type: application/x-www-form-urlencoded accept-encoding: gzip, deflate user-agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; NovaPacs Viewer 6.0.197.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727) host: localhost:8080 content-length: 37 connection: Keep-Alive cache-control: no-cache name=007&mission=deep%20dark%20secret Distributed Systems - Comp 655

  36. Watch out for Norton (and others) POST /don/demo HTTP/1.1 accept: */* accept-language: en-us -------: ----:-----------:----------------------- content-type: application/x-www-form-urlencoded ---------------: ----- ------- user-agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; NovaPacs Viewer 6.0.197.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727) host: localhost:8080 content-length: 37 connection: Keep-Alive cache-control: no-cache name=007&mission=deep%20dark%20secret Distributed Systems - Comp 655

  37. status code protocol reason phrase headers content Anatomy of an HTTP response HTTP/1.1 200 OK X-Powered-By: Servlet/2.5 Content-Type: text/xml;charset=utf-8 Content-Length: 57 Date: Sun, 16 Sep 2007 17:55:54 GMT Server: Sun Java System Application Server Platform Edition 9.0_01 <greeting>Hello, 007. You made a POST request.</greeting> Distributed Systems - Comp 655

  38. Making an HTTP request in Java Distributed Systems - Comp 655

  39. Server side: HttpServlet Distributed Systems - Comp 655

  40. Servlet container Container (Tomcat, Glassfish, WebLogic, WebSphere, etc) your Servlet Servlet base class request client response DB whatever Distributed Systems - Comp 655

  41. Smudging the transparency … • Network-unfriendly code • Lots of clients can mean lots of configuration management Distributed Systems - Comp 655

  42. Network-unfriendly code … • In OO, there are usually lots of fine-grained classes, and lots of getters and setters • Performance is not good if you do this over a network Person person = new Person(); person.setFirstName(fname); person.setMiddleInitial(initial); person.setLastName(lname); Address address = new Address(); address.setStreet(street); address.setCity(city); address.setState(state); person.setAddress(address); … Distributed Systems - Comp 655

  43. Network-unfriendly client server domain object domain object Distributed Systems - Comp 655

  44. A more network-friendly way • This is a recurring problem in distributed systems • Remote façade and Data transfer object patterns provide the core of a solution • Define a façade class with methods that group multiple fine-grained operations together • Define classes (DTOs) with nothing but getters and setters for moving groups of data items around • Keep the business logic in the original class(es) on the server side Distributed Systems - Comp 655

  45. Using Remote Façade + DTO • Client creates a DTO • Client calls lots of setters on DTO • Client calls façade with DTO as parameter • Service calls lots of getters on DTO, setters (and other methods, as needed) on the domain object(s) • Façade creates DTO2 • Façade calls setters on DTO2 • Façade returns DTO2 to client • Client calls lots of getters on DTO2 Distributed Systems - Comp 655

  46. Using Remote Façade + DTO client server Façade DTO DTO domain object domain object DTO2 DTO2 Distributed Systems - Comp 655

  47. Remote Façade + DTO code (flavor) PersonTO pto = new PersonTO(); pto.setFirstName(fname); pto.setMiddleInitial(initial); pto.setLastName(lname); pto.setStreet(street); pto.setCity(city); pto.setState(state); Facade facade = new Facade(); ResultTO rto = facade.addPerson(pto); … Distributed Systems - Comp 655

  48. Remote Façade + DTO consequences • Reduced network traffic • Reduced coupling between client and domain model • Costs include • More classes to deal with • Getters and setters called multiple times (client DTO.get, server DTO.get + domain.set) • Risks include • Temptation to put business logic in DTO • Temptation to skip domain model development and build a DTO-processing system Distributed Systems - Comp 655

  49. More about client/domain coupling • Refactoring is a good thing • Issues with refactoring a network service • Refactored client needs to be deployed in many places • Service administrators may not know where all the clients are • There may be clients the service developers know nothing about Distributed Systems - Comp 655

  50. A more refactoring-friendly way • This is a recurring problem in distributed systems • Patterns include • Migrate code at runtime • e.g. applet • See Tanenbaum & van Steen, section 3.5, if interested • Remote façade + DTO helps here, too Distributed Systems - Comp 655

More Related