* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download PowerPoint XP
History of wildlife tracking technology wikipedia , lookup
SIP extensions for the IP Multimedia Subsystem wikipedia , lookup
Computer network wikipedia , lookup
Telecommunications engineering wikipedia , lookup
Communication protocol wikipedia , lookup
Quality of service wikipedia , lookup
Windows Vista networking technologies wikipedia , lookup
Wake-on-LAN wikipedia , lookup
Deep packet inspection wikipedia , lookup
Packet switching wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
History of telecommunication wikipedia , lookup
Network Protocols Andy Wang Operating Systems COP 4610 / CGS 5765 Protocol   An agreement between two parties as to how information is to be transmitted A network protocol abstracts packets into messages Physical Reality vs. Abstraction Physical reality: packets Limited size Unordered Unreliable Machine-to-machine Only on local area network Asynchronous Insecure Abstraction: messages Arbitrary size Ordered Reliable Process-to-process Routed anywhere Synchronous Secure Arbitrary-Size Messages  Can be built on top of limited-size ones   By splitting a message into fix-sized packets Checksum can be computed on each fragment or the whole message Internet Protocol (IP)  Provides unreliable, unordered, machine-to-machine transmission of arbitrary-size messages Process-to-Process Communications   Built on top of machine-to-machine communications through the use of port addresses Each message contains the destination port to talk to the correct process Unreliable Data Protocol (UDP)   Provides unreliable, unordered, user-touser communication Built on the top of IP Ordered Messages   Built on top of unordered ones Use sequence numbers to indicate the order of arrival    Specific to a connection If packet 3 arrives before packet 2, wait for packet 2. Always deliver packets in order, to user applications Reliable Message Delivery   Built on top of unreliable delivery Problem: Network infrastructure can garble messages  Packets can be dropped if network buffers are full Solution     Checksum each message At a receiver, discard messages with mismatching checksums A receiver acknowledges if a packet is received properly A sender resends the same message after not hearing the acknowledgment for some time (a timeout period) A Minor Problem   A sender may send twice, if the first acknowledge is lost The receiver needs to discard duplicate packets Implications   A sender needs to buffer messages that are not yet acknowledged The receiver must track messages that could be duplicates Transmission Control Protocol (TCP)  Provides a reliable byte stream between two processes on different machines over the Internet sequence number: 1 checksum: fa73cd10 Transmission Control Protocol  Fragments the byte stream into packets and hands them to IP TCP Message Categories  Sender     Sent and acknowledged Sent and not acknowledged Not yet sent Receiver    Forwarded to application Received and buffered Not yet received More on the Sequence Number  Need a way to recycle sequence numbers  Each TCP packet has a time-to-live field  If the packet is not delivered in X seconds    The packet is dropped Sequence numbers can be reused An epoch number used to identify which set of sequence numbers is being used   Incremented at each boot Stored on disk Congestion  Implications of timeout period at a sender    Too long  unnecessary waiting Too short  a message is transmitted when an acknowledgement is in transit Network congestion  delayed acknowledgement  timeout  data retransmission  more congestion TCP Solution  Slow start: TCP starts by sending a small amount of data   If no timeout, more data is sent If timeout, TCP reduces the amount of data being sent The Byzantine Generals’ Problem  Two generals are on the tops of two mountains…   They communicate only through messengers… They need to coordinate the attack…   If they attack at the same time, they win… If they attack at different times, they will…die… The Byzantine Generals’ Problem  Question: can they guarantee a synchronized attack? The Byzantine Generals’ Problem Illustrated General X 11am OK? General Y 11am sounds good So, 11am it is. Yeah, what if you don’t get this ack? The Byzantine Generals’ Problem Over an unreliable network, we cannot guarantee that two computers will synchronize Distributed Transaction   Multiple machines agree to do something atomically, but not necessarily at exactly the same time Mechanism: two-phase commit Two-Phase Commit Account X Account Y Phase 1: ask if each can commit 1. Begin transaction Ask Y for $1 Enough cash 2. Write “Y = Y - $1” Ready to commit Phase 2: commit 3. Write “X = X + $1” 4. Commit Ask Y to commit 5. Commit Scenarios  If X crashes between 1 and 2    If X crashes before step 4   Y will wake up and do nothing X will timeout and abort the transaction X will wake up and abort the transaction If X crashes between 4 and 5  Y will timeout and ask X for the transaction Scenarios  If Y crashes between 2 and 5    Y will wake up and check the log When X sends Y the commit message, Y will commit Y can also timeout and ask X the current status
 
									 
									 
									 
									 
									 
									 
									 
									 
									 
									 
									 
									 
									 
									 
									 
									 
									 
									 
									 
									 
									 
									 
									 
									 
									 
									 
                                             
                                             
                                             
                                             
                                             
                                             
                                             
                                             
                                             
                                             
                                            