




























Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Community
Ask the community for help and clear up your study doubts
Discover the best universities in your country according to Docsity users
Free resources
Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors
Material Type: Notes; Class: Distributed Software Develop; Subject: Computer Science; University: University of San Francisco (CA); Term: Unknown 1989;
Typology: Study notes
1 / 36
This page cannot be seen from the preview
Don't miss anything!
Chris Brooks Department of Computer ScienceUniversity of San Francisco^ Department of Computer Science — University of San Francisco – p. 1/
Department of Computer Science — University of San Francisco – p. 2/
Department of Computer Science — University of San Francisco – p. 4/
-^ 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 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/
-^ 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/
-^ 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/
-^ 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/
-^ 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/
-^ 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 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/
-^ 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/
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/
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/