Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

Slides on Problem Solving I - Distributed Software Develop | CS 682, Study notes of Software Engineering

Material Type: Notes; Class: Distributed Software Develop; Subject: Computer Science; University: University of San Francisco (CA); Term: Unknown 1989;

Typology: Study notes

Pre 2010

Uploaded on 07/30/2009

koofers-user-5iq-2
koofers-user-5iq-2 🇺🇸

1

(1)

10 documents

1 / 36

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Distributed Software
Development
Problem Solving I
Chris Brooks
Department of Computer Science
University of San Francisco
Department of Computer Science University of San Francisco p. 1/??
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17
pf18
pf19
pf1a
pf1b
pf1c
pf1d
pf1e
pf1f
pf20
pf21
pf22
pf23
pf24

Partial preview of the text

Download Slides on Problem Solving I - Distributed Software Develop | CS 682 and more Study notes Software Engineering in PDF only on Docsity!

Distributed SoftwareDevelopment^ Problem Solving I

Chris Brooks Department of Computer ScienceUniversity of San Francisco^ Department of Computer Science — University of San Francisco – p. 1/

Distributed Problem Solving • The preliminary portion of the course focused on techniquesfor achieving properties or states in distributed systems. • Causal delivery, mutual exclusion, etc. • Now, we turn to the question of how to solve problems in adistributed fashion, assuming that we have implementedsome of these properties.

Department of Computer Science — University of San Francisco – p. 2/

Centrally controlled environments • At one extreme, all processes in a system are controlled by asingle individual or organization.^ •^ Beowulf cluster^ •^ Parallel computer^ •^ Intranet • This allows us to make fairly restrictive assumptions aboutthe behavior of system processes.^ •^ NFS, parallel computation (e.g. conjugate gradient)

Department of Computer Science — University of San Francisco – p. 4/

Cooperative processes

-^ We’ll also think about processes that are controlled byseparate individuals, but assumed to be cooperative.^ •^ SETI@Home, distributed.net^ •^ Meeting scheduling^ •^ TCP (originally) •^ In this case, we can assume that processes will actbenevolently, but that they will be heterogenous.

Department of Computer Science — University of San Francisco – p. 5/

TCP: an illustration

-^ TCP is an example of a protocol that was designed to workin a cooperative environment. •^ Recall that TCP is built on top of UDP^ •^ UDP provides packet-oriented delivery. •^ TCP provides reliable in-order delivery on top of UDP. •^ Sender A sends a packet to receiver B. •^ B returns an acknowledgment that the packet was received. •^ If A does not receive an ACK before a timer expires, thepacket is resent.

Department of Computer Science — University of San Francisco – p. 7/

TCP: an illustration

-^ To improve transmission efficiency, TCP uses a conceptcalled^

sliding windows

-^ The sender has a “window” of size

n. It sends all packets

within that window. • As the lowest-numbered packet in the window isacknowleged, the window “slides” upward, and morepackets are sent. • This improves transmission rates - the goal is for thenetwork to be completely saturated.

Department of Computer Science — University of San Francisco – p. 8/

TCP: an illustration

-^ The TCP congestion algorithm does the following (loosely):^ •^ When a packet is lost, halve the window size and doubletimeout.^ •^ If all packets in a window are transmitted successfully,increase window size by 1. •^ There are lots of details in the implementation of this thatI’m glossing over. •^ The key point is this: This protocol works wonderfully,

as

long as everyone else also uses it

-^ Designed to minimize congestion over the entireInternet.

Department of Computer Science — University of San Francisco – p. 10/

TCP: an illustration

-^ In the early days if the Internet, this was not a problem.^ •^ Small number of users, fewer bandwidth-saturatingapps. •^ Parallel download of images from web pages was the firstconcern. •^ Later, non-TCP protocols (RTSP, proprietary schemes)implemented their own congestion control algorithms. •^ These applications are not necessarily tuned to any sort ofglobal optimum.

Department of Computer Science — University of San Francisco – p. 11/

Distributing a Problem

-^ We’ll also need to think about how well a problem can bepartitioned. •^ Typically, a problem is distributed by dividing it intosubproblems. •^ Each node or process works on its own subproblem. •^ Processes may need to communicate with each other. •^ A center or coordinator is responsible for doling outsubproblems and collecting results.

Department of Computer Science — University of San Francisco – p. 13/

Problem Coupling

-^ We can characterize distributed problems by the degree ofinteraction that is required between nodes. •^ Tightly coupled: nodes must communicate frequently inorder to solve subproblems. •^ Loosely coupled: Subproblems are relatively independent ofeach other. •^ “Medium coupled”: Some interaction must take place.

Department of Computer Science — University of San Francisco – p. 14/

Tightly Coupled Problems

-^ Tightly coupled problems typically have a great deal of datadependency between subproblems.^ •^ Nodes must frequently share partial results in order toproceed. •^ This means that tightly coupled problems are best solved ina parallel computer or a LAN. •^ All nodes should have roughly the same computing power.^ •^ A slow process can act as a bottleneck.

Department of Computer Science — University of San Francisco – p. 16/

Loosely coupled problems

-^ At the other end of the spectrum are loosely coupledproblems. •^ The center can divide up a problem and allow processes towork independently on subproblems. •^ Nice for settings in which communication is slow, or nodesmay run at different speeds •^ Examples:^ •^ distributed.net^ •^ SETI@Home

Department of Computer Science — University of San Francisco – p. 17/

mmetric-key encryption: a brief digress^ •^ Symmetric key encryption (or secret-key encryption) usesone key to encrypt and decrypt a message.^ •

As opposed to public-key encryption, which uses pairs ofkeys. • A series of bit shifts and ANDs with a key are used toconceal a message. • Secret-key encryption is “more secure” than public keyencryption in the sense that a shorter key is needed toprovide the same level of security.

Department of Computer Science — University of San Francisco – p. 19/

mmetric-key encryption: a brief digress^ •^ Two well-known algorithms: DES, RC5.^ •

DES was developed by the government in the 50s • RC5 was developed at RSA labs in the 90s. • The only^ known

way to defeat them is through exhaustive search of all keys. • DES keyspace is

keysize 2

-^ 56-bit secret-key algorithm has a keyspace of

56 2 = 72

quadrillion keys.

Department of Computer Science — University of San Francisco – p. 20/