1 / 45

Networking and layered styles

Networking and layered styles. INF 123 – Software architecture tdebeauv@uci.edu. Reminder: Architectural styles. Guidelines, recipes If you follow the constraints You’ll gain the benefits Tools to understand and criticize architectures Problem – solution Why is it working that way ?.

vevina
Download Presentation

Networking and layered styles

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. Networking and layered styles INF 123 – Software architecture tdebeauv@uci.edu

  2. Reminder: Architectural styles • Guidelines, recipes • If you follow the constraints • You’ll gain the benefits • Tools to understand and criticize architectures • Problem – solution • Why is it working that way?

  3. Outline • Distributed system • The OSI model • The layered style • Client-server • Pipe and filter

  4. Distributed system

  5. Distributed system • Collection of interactingcomponents hosted on different networkedmachines Host 2 Component 3 Host 1 Host 3 Component 1 Component 4 Component 2 Component 5 Network interface of the OS

  6. Examples of distributed systems • WWW, DNS, TOR, … • Cell phones + towers • SETI@home • Online games • Peer to peer: Skype, Torrents

  7. TOR • The Onion Router

  8. Properties of distributed systems • Components run concurrently • Components fail independently • No global clock • Debugging is a pain • Latency = duration between A.send and B.recv • Aka lag or delay • Speed of light: 50 ms to reach the other side of the world • Practically much slower: 40 ms across the US

  9. Fallacies of distributed computing • The network is reliable. • Latency is zero. • Bandwidth is infinite. • The network is secure. • Topology doesn't change. • There is one administrator. • Transport cost is zero. • The network is homogeneous.

  10. The OSI model

  11. OSI model • Open Systems Interconnection, 1977 • The backbone of today’s networking • A model (in the software architecture sense) • Only a subset of the decisions about networking • Multiple visualizations • Different ways to look at the OSI model

  12. 68 pages! http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.200-199407-I!!PDF-E&type=items

  13. DNS, FTP, HTTP, SMTP SSL, TLS TCP, UDP packets datagrams

  14. Message encapsulation layer 5-7 4 3 2

  15. Web browser asking for a web page Web browser Web page HTTP HTTP 7 application Requests TCP TCP 4 transport Packets Datagrams IP IP 3 network Frames Bits Electrons Photons Carrier pigeons Physical link (copper wire, optic fiber, …) 1 physical

  16. Web browser asking for a web page Web browser Web page Transparent! HTTP HTTP TCP TCP IP IP Physical link (copper wire, optic fiber, …)

  17. Dependencies http://networking.ringofsaturn.com/Protocols/sevenlayer.php

  18. TCP vs UDP

  19. Turtles all the way down The Layered style

  20. Constraints • Ordered layers (top – bottom) • Connectors: from the current layer to… • … The layer right below (strict layered style) • … Any layer below (non-strict) • Each layer exposes an interface • Only to the layer above it • No link within the same layer Controller Input Game logic Display Sound

  21. Gains • Bottom independent of top • Top independent of bottom • Unless bottom’s interface changes • Clear dependences • Easy to test Controller Input Game logic Display Sound

  22. Globus grid reference architecture Mattmann et al, Unlocking the Grid , sunset.usc.edu/classes/cs578_2014b/week3b-supp.ppt

  23. Derivatives • Tiered style • Layered style for physical deployment • Client-server • Two layers • C2 style • Components – connectors – components – … • Aware of layers above, unaware of layers below • Requests go up, notifications go down

  24. Client-server

  25. Client-server client client client server

  26. Constraints • Clients initiate the communication • Communication usually over the network • Server has the main functionality • No client-to-client communication

  27. Client-server: pros and cons • Pros • Computation and data collocated • Server = single authority, trusted • Ignore bad clients without affecting good clients • Cons • Server = single point of failure • Server can be a bottleneck

  28. Fat client • Most of the functionality or data is client-side • Server for backups, inter-client sync, patches • Mitigate single-point of failure • Offload some computations to clients • More clients per server • Most games • Tablet and phone apps • Gmail (“you’ve been disconnected – try now”)

  29. Thin client • Most of the functionality and data is server-side • Client for user input, screen, and audio • When clients are computationally weak • Reduce the cost of the overall infrastructure • Game streaming: Onlive, Twitch TV Pokemon • Remote desktop, X terminal, library computers

  30. “Subverting” the style • Using the server as a gateway between peers • C1 sends to server • {‘from’:C1’, ‘to’: ‘C2’, ‘msg’:’hi’} • Server forwards blindly to all clients • C1 receives the message and discards it • C2 receives the message and prints it

  31. “Subverting” the style Clients send client list Server holds client list clients = [] defon_msg(msg): txt = msg[‘txt’] for c in clients: c.send(txt) defon_msg(msg): clients = msg[‘to’] txt = msg[‘txt’] for c in clients: c.send(txt)

  32. “Subverting” the style endpoints = {} defon_msg(msg): clients = endpoints(msg[‘to’]) txt = msg[‘txt’] for c in clients: c.send(txt) defon_open(self): name = randint(0,10**9) endpoints[name] = self clients = [] defon_msg(msg): txt = msg[‘txt’] for c in clients: c.send(txt) defon_open(self): clients.append(self)

  33. “Subverting” the style • Using the server as a gateway between peers • Why is it bad? • Messaging functionality replicated in all clients • No messaging functionality in the server • The server is “obeying” the clients

  34. Server-side with TCP • Listen for incoming connections • Create a socket when a client connects • Each socket is administered by a handler • So: each handler is in charge of a client • Use handler to send a message or to close the connection with that client • Poll connections to receive messages • Kernel vs user space … • Kernel notifies a handler when its socket is readable • Poll/select = Chipotle, epoll = Blaze Pizza

  35. Client-side with TCP • Initiate the connection to the server • Create a socket (handler for convenience) • Use handler to send a message or to close the connection with that client • Poll the socket to receive messages • Same as server

  36. NOT a layered architecture Pipe and filter

  37. Assembly line

  38. Constraints • Each task runs in its own process • Stream of data passed between tasks • Input/output format input simulation/ logic display

  39. Gains • Modularity between tasks • Concurrency and speed-ups • Reusable components • Expected input and output formats

  40. Beware • The data can only go one way • Congestion may cause starvation

  41. More reading • http://msdn.microsoft.com/en-us/library/ff963548.aspx

More Related