CS162 Operating Systems and Systems Programming Lecture 24 Network Communication Abstractions Distributed Programming November 24 2008 Prof John Kubiatowicz http inst eecs berkeley edu cs162 Review Window Based Acknowledgements TCP 100 140 190 230 260 300 340 380 400 Seq 380 Size 20 Seq 340 Size 40 Seq 300 Size 40 Seq 260 Size 40 Seq 230 Size 30 Seq 190 Size 40 Seq 140 Size 50 Seq 100 Size 40 A 100 300 Seq 100 A 140 260 Seq 140 A 190 210 Seq 230 A 190 140 Seq 260 A 190 100 Seq 300 A 190 60 Seq 190Retransmit A 340 60 Seq 340 A 380 20 Seq 380 11 24 08 Kubiatowicz CS162 UCB Fall 2008 A 400 0 Lec 24 2 Review Socket Setup Con t ion t c e n n Co t s ue q e R socket connection Client Server Socket new socket socket Server Things to remember Connection requires 5 values Src Addr Src Port Dst Addr Dst Port Protocol Often Src Port randomly assigned Done by OS during client socket setup Dst Port often well known 80 web 443 secure web 25 sendmail etc Well known ports from 0 1023 11 24 08 Kubiatowicz CS162 UCB Fall 2008 Lec 24 3 Goals for Today Messages Send receive One vs two way communication Distributed Decision Making Two phase commit Byzantine Commit Remote Procedure Call Distributed File Systems Part I Note Some slides and or pictures in the following are adapted from slides 2005 Silberschatz Galvin and 11 24 08 Kubiatowicz CS162 UCB Fall 2008 Lec 24 4 Gagne Many slides Gagne generated from my lecture notes Distributed Applications How do you actually program a distributed application Need to synchronize multiple threads running on different machines Send Network Receive No shared memory so cannot use test set One Abstraction send receive messages Already atomic no receiver gets portion of a message and two receivers cannot get same message Interface Mailbox mbox temporary holding area for messages Includes both destination location and queue Send message mbox Send message to remote mailbox identified by mbox Receive buffer mbox Wait until mbox has message copy into buffer and return If threads sleeping on this mbox wake up one of them 11 24 08 Kubiatowicz CS162 UCB Fall 2008 Lec 24 5 Using Messages Send Receive behavior When should send message mbox return When receiver gets message i e ack received When message is safely buffered on destination Right away if message is buffered on source node Actually two questions here When can the sender be sure that receiver actually received the message When can sender reuse the memory containing message Mailbox provides 1 way communication from T1 T2 T1 buffer T2 Very similar to producer consumer Send V Receive P However can t tell if sender receiver is local or not 11 24 08 Kubiatowicz CS162 UCB Fall 2008 Lec 24 6 Messaging for Producer Consumer Style Using send receive for producer consumer style Producer int msg1 1000 while 1 prepare message send msg1 mbox Consumer int buffer 1000 while 1 receive buffer mbox process message Send Message Receive Message No need for producer consumer to keep track of space in mailbox handled by send receive One of the roles of the window in TCP window is size of buffer on far end Restricts sender to forward only what will fit in buffer 11 24 08 Kubiatowicz CS162 UCB Fall 2008 Lec 24 7 Messaging for Request Response communication What about two way communication Request Response Read a file stored on a remote machine Request a web page from a remote web server Also called client server Client requester Server responder Server provides service file storage to the client Example File service Request File Client requesting the file char response 1000 send read rutabaga server mbox receive response client mbox Server responding with the file char command 1000 answer 1000 11 24 08 receive command server mbox decode command read file into answer send answer client mbox Kubiatowicz CS162 UCB Fall 2008 Get Respons e Receive Request Send ResponsLec 24 8 e General s Paradox General s paradox Constraints of problem Two generals on separate mountains Can only communicate via messengers Messengers can be captured Problem need to coordinate attack If they attack at different times they all die If they attack at same time they win Named after Custer who died at Little Big Horn because he arrived a couple of days too early Can messages over an unreliable network be used to guarantee two entities do something simultaneously Remarkably no even if all messages get through 11 am ok ks Yes 11 wor So 11 it is t if you a h w t u b h Yea is ack Don t get th No 11 24 08 way to be sure last message through Kubiatowicz CS162 UCBgets Fall 2008 Lec 24 9 Two Phase Commit Since we can t solve the General s Paradox i e simultaneous action let s solve a related problem Distributed transaction Two machines agree to do something or not do it atomically Two Phase Commit protocol does this Use a persistent stable log on each machine to keep track of whether commit has happened If a machine crashes when it wakes up it first checks its log to recover state of world at time of crash Prepare Phase The global coordinator requests that all participants will promise to commit or rollback the transaction Participants record promise in log then acknowledge If anyone votes to abort coordinator writes Abort in its log and tells everyone to abort each records Abort in log Commit Phase After all participants respond that they are prepared then the coordinator writes Commit to its log Then asks all nodes to commit they respond with ack After receive acks coordinator writes Got Commit to log Log can be used to complete this process such that 11 24 08 Kubiatowicz CS162 UCB Fall 2008 all machines either commit or don t commit Lec 24 10 Two phase commit example Simple Example A WellsFargo Bank B Bank of America Phase 1 Prepare Phase A writes Begin transaction to log A B OK to transfer funds to me Not enough funds B A transaction aborted A writes Abort to log Enough funds B Write new account balance promise to commit to log B A OK I can commit Phase 2 A can decide for both whether they will commit A write new account balance to log Write Commit to log Send message to B that commit occurred wait for ack Write Got Commit to log What if B crashes at beginning Wakes up does nothing A will timeout abort and retry What if A crashes at beginning of phase 2 Wakes up sees that there is a transaction in progress sends Abort to B What if B crashes at beginning of phase 2 B comes back up looks at log when A sends it Commit message it will say oh ok commit 11 24 08 Kubiatowicz
View Full Document
Unlocking...