networking and layered styles inf 123 – software architecture [email protected] 1

45
Networking and layered styles INF 123 – Software architecture [email protected] 1

Upload: phoebe-johnson

Post on 23-Dec-2015

218 views

Category:

Documents


2 download

TRANSCRIPT

Page 1: Networking and layered styles INF 123 – Software architecture tdebeauv@uci.edu 1

1

Networking and layered styles

INF 123 – Software [email protected]

Page 2: Networking and layered styles INF 123 – Software architecture tdebeauv@uci.edu 1

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?

Page 3: Networking and layered styles INF 123 – Software architecture tdebeauv@uci.edu 1

3

Outline

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

Page 4: Networking and layered styles INF 123 – Software architecture tdebeauv@uci.edu 1

4

DISTRIBUTED SYSTEM

Page 5: Networking and layered styles INF 123 – Software architecture tdebeauv@uci.edu 1

5

Host 1

Distributed system

• Collection of interacting components hosted on different networked machines

Component 1

Component 2

Component 3

Host 3

Component 4

Component 5

Host 2

Network interface of the OS

Page 6: Networking and layered styles INF 123 – Software architecture tdebeauv@uci.edu 1

6

Examples of distributed systems

• WWW, DNS, TOR, …• Cell phones + towers• SETI@home• Online games• Peer to peer: Skype, Torrents

Page 7: Networking and layered styles INF 123 – Software architecture tdebeauv@uci.edu 1

7

TOR

• The Onion Router

Page 8: Networking and layered styles INF 123 – Software architecture tdebeauv@uci.edu 1

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

Page 9: Networking and layered styles INF 123 – Software architecture tdebeauv@uci.edu 1

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.

Page 10: Networking and layered styles INF 123 – Software architecture tdebeauv@uci.edu 1

10

Page 11: Networking and layered styles INF 123 – Software architecture tdebeauv@uci.edu 1

11

Page 12: Networking and layered styles INF 123 – Software architecture tdebeauv@uci.edu 1

12

THE OSI MODEL

Page 13: Networking and layered styles INF 123 – Software architecture tdebeauv@uci.edu 1

13

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

Page 14: Networking and layered styles INF 123 – Software architecture tdebeauv@uci.edu 1

14

68 pages!

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

Page 15: Networking and layered styles INF 123 – Software architecture tdebeauv@uci.edu 1

15

Page 16: Networking and layered styles INF 123 – Software architecture tdebeauv@uci.edu 1

16

Page 17: Networking and layered styles INF 123 – Software architecture tdebeauv@uci.edu 1

17

TCP, UDP

SSL, TLS

DNS, FTP, HTTP, SMTP

datagrams

packets

Page 18: Networking and layered styles INF 123 – Software architecture tdebeauv@uci.edu 1

18

Message encapsulationlayer5-7

4

3

2

Page 19: Networking and layered styles INF 123 – Software architecture tdebeauv@uci.edu 1

19

Web browser asking for a web page

HTTP

TCP

IP

HTTP

TCP

IP

Physical link (copper wire, optic fiber, …)

Web browser Web page

Datagrams

Bits

ElectronsPhotonsCarrier pigeons

Packets

Requests

Frames

7 application

1 physical

4 transport

3 network

Page 20: Networking and layered styles INF 123 – Software architecture tdebeauv@uci.edu 1

20

Web browser asking for a web page

HTTP

TCP

IP

HTTP

TCP

IP

Physical link (copper wire, optic fiber, …)

Transparent!Web browser Web page

Page 21: Networking and layered styles INF 123 – Software architecture tdebeauv@uci.edu 1

21

Dependencies

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

Page 22: Networking and layered styles INF 123 – Software architecture tdebeauv@uci.edu 1

22

TCP vs UDPTCP UDP

Connection Yes. 3-packet handshake (SYN/SYN-ACK/ACK)

Connectionless, Fire-and-forget

Reliability By re-sending None

Ordering Through the sequence number No. Packets can pass each other.

Congestion control

Slow start, congestion avoidance, fast retransmit

None

Fragmentation of big packets

Handled automatically and transparently.

You handle it. Don’t send big packets anyways!

Error checking Checksum, automatically re-send to fix.

Checksum only. You decide what to do with the mess.

Applications (level 7)

HTTP, FTP DNS, Voice over IP, FPS games, streaming

Page 23: Networking and layered styles INF 123 – Software architecture tdebeauv@uci.edu 1

23

THE LAYERED STYLETurtles all the way down

Page 24: Networking and layered styles INF 123 – Software architecture tdebeauv@uci.edu 1

24

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

Display

Game logic

Sound

Page 25: Networking and layered styles INF 123 – Software architecture tdebeauv@uci.edu 1

25

Gains

• Bottom independent of top• Top independent of bottom– Unless bottom’s interface changes

• Clear dependences• Easy to test

Controller Input

Display

Game logic

Sound

Page 26: Networking and layered styles INF 123 – Software architecture tdebeauv@uci.edu 1

26

Globus grid reference architecture

Mattmann et al, Unlocking the Grid , sunset.usc.edu/classes/cs578_2014b/week3b-supp.ppt

Collective

Application

Connectivity

Resource

Fabric

Profile

ProfileAttributes ResourceAttributes

ProfileElement

DDMResultParser

QueryEngine

ServerPOA

ServerImpl

DatabaseProfileHandler

Dataset

DatasetDisplayer

PageBean

XMLQuery QueryResultTransaction

QueryHeader

Configuration

ConfigurationBean

SearchBean QueryClient

Expression

Result

HTTPFormRecorder

Utilities

ChunkedProductInputStream

DatabaseProfileManager

CORBA_Archive_ServiceHolder

ProfileServiceAdaptor

ProductClient

ProductServiceAdaptor

QueryServicePOA

ProfileClient

QueryServiceHolder

ProductServicePOA

ExecServerProfileServicePOA

CORBA_Archive_ServicePOA

RMIQueryServiceFactory

Page 27: Networking and layered styles INF 123 – Software architecture tdebeauv@uci.edu 1

27

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

Page 28: Networking and layered styles INF 123 – Software architecture tdebeauv@uci.edu 1

28

CLIENT-SERVER

Page 29: Networking and layered styles INF 123 – Software architecture tdebeauv@uci.edu 1

29

Client-server

client client client

server

Page 30: Networking and layered styles INF 123 – Software architecture tdebeauv@uci.edu 1

30

Constraints

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

Page 31: Networking and layered styles INF 123 – Software architecture tdebeauv@uci.edu 1

31

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

Page 32: Networking and layered styles INF 123 – Software architecture tdebeauv@uci.edu 1

32

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”)

Page 33: Networking and layered styles INF 123 – Software architecture tdebeauv@uci.edu 1

33

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

Page 34: Networking and layered styles INF 123 – Software architecture tdebeauv@uci.edu 1

34

“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

Page 35: Networking and layered styles INF 123 – Software architecture tdebeauv@uci.edu 1

35

“Subverting” the style

Clients send client list

def on_msg(msg): clients = msg[‘to’] txt = msg[‘txt’] for c in clients: c.send(txt)

Server holds client listclients = []def on_msg(msg):

txt = msg[‘txt’] for c in clients: c.send(txt)

Page 36: Networking and layered styles INF 123 – Software architecture tdebeauv@uci.edu 1

36

“Subverting” the style

endpoints = {}def on_msg(msg): clients = endpoints(msg[‘to’])

txt = msg[‘txt’] for c in clients: c.send(txt)

def on_open(self): name = randint(0,10**9) endpoints[name] = self

clients = []def on_msg(msg):

txt = msg[‘txt’] for c in clients: c.send(txt)

def on_open(self): clients.append(self)

Page 37: Networking and layered styles INF 123 – Software architecture tdebeauv@uci.edu 1

37

“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

Page 38: Networking and layered styles INF 123 – Software architecture tdebeauv@uci.edu 1

38

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

Page 39: Networking and layered styles INF 123 – Software architecture tdebeauv@uci.edu 1

39

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

Page 40: Networking and layered styles INF 123 – Software architecture tdebeauv@uci.edu 1

40

PIPE AND FILTERNOT a layered architecture

Page 41: Networking and layered styles INF 123 – Software architecture tdebeauv@uci.edu 1

41

Assembly line

Page 42: Networking and layered styles INF 123 – Software architecture tdebeauv@uci.edu 1

42

Constraints

• Each task runs in its own process• Stream of data passed between tasks– Input/output format

input simulation/logic display

Page 43: Networking and layered styles INF 123 – Software architecture tdebeauv@uci.edu 1

43

Gains

• Modularity between tasks• Concurrency and speed-ups• Reusable components – Expected input and output formats

Page 44: Networking and layered styles INF 123 – Software architecture tdebeauv@uci.edu 1

44

Beware

• The data can only go one way

• Congestion may cause starvation