CSC 290e Mobile Computing Networking Fundamentals 10 September 2001 ------------------------------------- Parallel vs. distributed computing Disclaimer: this is mostly opinion. Parallel computing is spreading a single computation across multiple processors to achieve speedup. A good example is calculating the pixels of a ray traced image, or doing a complicated matrix computation. Distributed computing is typically for more loosely coupled applications. There are usually multiple, geographically distributed hosts involved, they can be running different operating systems, etc. Why do distributed computing? fault tolerance, redundancy of data distribution is inherent in the system e.g., mobile systems can build a bigger system e.g., the world wide web ----------------------------- Cordinated Attack classical problem in distributed computing Two generals of the same army positioned on top of two hills, each with a small contingent of people Enemy in the valley Communicate only by sending messengers -- through the valley Messengers can get lost, be captured, be delayed Generals need to decide whether or not to "attack at dawn". Each decides separately, but needs to communicate the decision to the other general If both attack, they will be successful. If only one attacks, they will certainly fail. Question: how will they make this decision? Put another way, what algorithm can they use to ensure that if one attacks, so with the other, but also guarantee that if one will not attack, neither will the other. The surprize: this is actually impossible! There is no alogrithm that can guarantee this. In theoretical computing, this is refereed to as **consensus**. Proof it is impossible: - Reaching an agreement on one of two possible decisions requires the successful arrival of at least one message. - Consider a scenario A in which the fewest delivered messages that will result in agreement to attack are delivered. - Let scenario B be the same as A except that the last message delivered in A is lost in B, and any other messages that might be sent later are also lost. - Suppose this last message is from general 1 to general 2. - General 1 sees the same messages in two scenarios, so he must decide to attack. - However, the minimality assumption of A implies that general 2 cannot also decide to attack in sceanrio B, so he must make a different decision. - Hence the problem is unsolvable real examples of consensus - commit or abort a transaction in a distributed database - agree on values of replicated, distributed sensors - agree on whether a system component is faulty Note: consensus is easy with no failures ----------------------------------- So, if it is impossible for two processes to agree in the presence of faults, how do we get anything accomplished in distributed systems? TCP transmission control protocol S sends data to D --> are messages from S to D <-- are messages from D to S connect --> setup connection <-- connect ack data --> S sending data, D storing in tmp <-- ack if lost, S will retransmit data --> if lost, D will retransmit <-- ack dataDone --> D accepts file, flip pointer from tmp to real <-- ok disconnect --> D starts timer for disconnect <-- disconnect confirm S gets rid of connection disconnect ack --> D gets rid of connection, if lost, timeout use three-way handshake to set up connection use timeouts to detect possible losses although we HAVE successfully transmitted a file, we have still NOT solved distributed consensus Things people work on to make TCP work better: - simultaneously sending multiple data packets and waiting for a group of acks. sliding window protocols - congestion control. slow-start, fast retransmit. how to adjust the size of the window on sliding window protocols - what we just described is related an end-to-end protocol. If you think about a connection between a wired machine and a wireless machine, only the last hop from the wired machine to the wireless machine is likely to be faulty (wireless links are generally more fault-prone than wired ones). So we can do some fancy caching to decrease the error rate. - in web systems, people try to use the same tcp connection for multiple flows. The idea is to eliminate the time needed to setup the connection - persistent connections. Same idea, but not for multiple simultaneous flows. Instead, use the same connection for consecutive flows. UDP: user datagram protocol unreliable good for sending multimedia. By the time it was realized that a packet was dropped, its retransmission would be too late to insert into the proper place in the video/audio stream data --> data --> no handshaking connectionless TCP vs UDP Application Transport Protocol ----------------------------------------- electronic mail TCP remote terminal access TCP Web TCP file transfer TCP remote file server typically UDP streaming multimedia typically UDP Internet telephony typically UDP Network Management typically UDP Routing Protocol typically UDP Name Translation typically UDP