Transcript Networking

Networking and layered styles
INF 123 – Software architecture
[email protected]
1
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?
2
Outline
•
•
•
•
•
Distributed system
The OSI model
The layered style
Client-server
Pipe and filter
3
DISTRIBUTED SYSTEM
4
Distributed system
• Collection of interacting components hosted
on different networked machines
Host 2
Component 3
Component 1
Component 4
Host 1
Host 3
Component 2
Component 5
Network interface of the OS
5
Examples of distributed systems
•
•
•
•
•
WWW, DNS, TOR, …
Cell phones + towers
SETI@home
Online games
Peer to peer: Skype, Torrents
6
TOR
• The Onion Router
7
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
8
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.
9
10
11
THE OSI MODEL
12
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
13
68 pages!
http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.200-199407-I!!PDF-E&type=items
14
15
16
DNS, FTP, HTTP, SMTP
SSL, TLS
packets
TCP, UDP
datagrams
17
Message encapsulation
layer
5-7
4
3
2
18
Web browser asking for a web page
Web browser
Requests
Packets
Datagrams
Web page
7 application
HTTP
HTTP
TCP
TCP
4 transport
IP
IP
3 network
Frames
Bits
Electrons
Photons
Carrier pigeons
Physical link (copper wire, optic fiber, …)
1 physical
19
Web browser asking for a web page
Web browser
Web page
Transparent!
HTTP
HTTP
TCP
TCP
IP
IP
Physical link (copper wire, optic fiber, …)
20
Dependencies
http://networking.ringofsaturn.com/Protocols/sevenlayer.php
21
TCP vs UDP
TCP
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 resend to fix.
Checksum only. You decide what
to do with the mess.
Applications
(level 7)
HTTP, FTP
DNS, Voice over IP, FPS games,
streaming
22
Turtles all the way down
THE LAYERED STYLE
23
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
24
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
25
Globus grid reference architecture
Application
SearchBean
HTTPFormRecorder
QueryClient
PageBean
Dataset
ProfileClient
ProductClient
DatasetDisplayer
ConfigurationBean
Utilities
Collective
QueryEngine
ServerImpl
RMIQueryServiceFactory
QueryServicePOA
ServerPOA
Resource
QueryServiceHolder
ProfileAttributes
ResourceAttributes
DatabaseProfileHandler
Profile
DDMResultParser
ProfileServiceAdaptor
ProfileElement
Connectivity
Fabric
Expression
ProfileServicePOA
DatabaseProfileManager
ExecServer
Configuration
XMLQuery
Transaction
ChunkedProductInputStream
QueryResult
CORBA_Archive_ServiceHolder
Result
CORBA_Archive_ServicePOA
ProductServiceAdaptor
ProductServicePOA
QueryHeader
Mattmann et al, Unlocking the Grid , sunset.usc.edu/classes/cs578_2014b/week3b-supp.ppt
26
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
27
CLIENT-SERVER
28
Client-server
client
client
client
server
29
Constraints
•
•
•
•
Clients initiate the communication
Communication usually over the network
Server has the main functionality
No client-to-client communication
30
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
31
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”)
32
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
33
“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
34
“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 list
clients = []
def on_msg(msg):
txt = msg[‘txt’]
for c in clients:
c.send(txt)
35
“Subverting” the style
endpoints = {}
def on_msg(msg):
clients = []
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
txt = msg[‘txt’]
for c in clients:
c.send(txt)
def on_open(self):
clients.append(self)
36
“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
37
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
38
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
39
NOT a layered architecture
PIPE AND FILTER
40
Assembly line
41
Constraints
• Each task runs in its own process
• Stream of data passed between tasks
– Input/output format
input
simulation/
logic
display
42
Gains
• Modularity between tasks
• Concurrency and speed-ups
• Reusable components
– Expected input and output formats
43
Beware
• The data can only go
one way
• Congestion may cause
starvation
44
More reading
• http://msdn.microsoft.com/enus/library/ff963548.aspx
45