P3 UDP and TCP use 1s complement for their checksums Suppose you have the following three 8 bit bytes 01010011, 01100110, 01110100 What is the 1s complement of the sum of these 8 bit bytes? (Note that[.]
P3 UDP and TCP use 1s complement for their checksums Suppose you have the following three 8-bit bytes: 01010011, 01100110, 01110100 What is the 1s complement of the sum of these 8-bit bytes? (Note that although UDP and TCP use 16bit words in computing the checksum, for this problem you are being asked to consider 8-bit sums.) Show all work Why is it that UDP takes the 1s complement of the sum; that is, why not just use the sum? With the 1s complement scheme, how does the receiver detect errors? Is it possible that a 1-bit error will go undetected? How about a 2-bit error? - Tính tổng byte cho Thêm byte bit đầu tiên: - Để phát lỗi, người nhận thêm bốn từ (ba từ gốc tổng kiểm tra) Nếu tổng chứa số 0, người nhận biết có lỗi Tất lỗi bit phát hiện, lỗi hai bit khơng phát (ví dụ: chữ số cuối từ chuyển đổi thành chữ số cuối từ thứ hai chuyển thành 1) P4 a Suppose you have the following bytes: 01011100 and 01100101 What is the 1s complement of the sum of these bytes? b Suppose you have the following bytes: 11011010 and 01100101 What is the 1s complement of the sum of these bytes? c For the bytes in part (a), give an example where one bit is flipped in each of the bytes and yet the 1s complement doesn’t change P6 Consider our motivation for correcting protocol rdt2.1 Show that the receiver, shown in Figure 3.57, when operating with the sender shown in Figure 3.11, can lead the sender and receiver to enter into a deadlock state, where each is waiting for an event that will never occur - Giả sử người gửi trạng thái “Chờ gọi từ bên trên” người nhận trạng thái “Chờ gọi từ bên dưới” Người gửi gửi gói có số thứ tự chuyển sang "Chờ ACK NAK 1", chờ ACK NAK Giả sử người nhận nhận gói liệu thứ 1, gửi ACK chuyển sang trạng thái “Chờ số từ bên dưới”, chờ gói liệu có số thứ tự Tuy nhiên, ACK bị hỏng Khi người gửi rdt2.1 nhận ACK bị hỏng, gửi lại gói thứ Tuy nhiên, người nhận đợi gói có số thứ tự ln gửi NAK khơng khơng nhận gói có số thứ tự Do người gửi ln gửi gói thứ 1, người nhận ln NAK gói Sẽ khơng tiến triển từ trạng thái P7 In protocol rdt3.0, the ACK packets flowing from the receiver to the sender not have sequence numbers (although they have an ACK field that contains the sequence number of the packet they are acknowledging) Why is it that our ACK packets not require sequence numbers? - Giao thức rtd3.0 sử dụng để truyền liệu từ người gửi đến người nhận Nếu người gửi chuyển gói đến người nhận, người nhận nhận gửi ACK (Lời cảm ơn) cho người gửi để cấu hình Nếu người gửi nhận ACK chuyển sang cấp độ Trong trình này, người gửi cần số thứ tự để tìm liệu gói tin trùng lặp liệu ACK Nếu người gửi tìm thấy ACK trùng lặp nào, bỏ qua Trong trình này, gói ACK khơng u cầu số thứ tự P11 Consider the rdt2.2 receiver in Figure 3.14, and the creation of a new packet in the self-transition (i.e., the transition from the state back to itself) in the Waitfor-0-frombelow and the Wait-for-1-from-below states: sndpkt=make_ pkt(ACK,0,checksum) and sndpkt=make_pkt(ACK,0, checksum) Would the protocol work correctly if this action were removed from the self-transition in the Wait-for-1-from-below state? Justify your answer What if this event were removed from the self-transition in the Waitfor-0-frombelow state? [Hint: In this latter case, consider what would happen if the first sender-toreceiver packet were corrupted.] - Nếu việc gửi thông điệp bị loại bỏ, bên gửi nhận bế tắc, chờ đợi kiện không xảy Đây tình huống: - Người gửi gửi pkt0, nhập trạng thái "Chờ cho trạng thái ACK0" đợi gói tin trở lại từ người nhận - Người nhận trạng thái “Chờ từ bên dưới” nhận gói tin bị hỏng từ người gửi Giả sử khơng gửi lại thứ cần nhập lại trạng thái ‘đợi từ bên dưới” - Bây giờ, người gửi chờ ACK thuộc loại từ người nhận, người nhận đợi dạng gói liệu từ người gửi - bế tắc! P12 The sender side of rdt3.0 simply ignores (that is, takes no action on) all received packets that are either in error or have the wrong value in the acknum field of an acknowledgment packet Suppose that in such circumstances, rdt3.0 were simply to retransmit the current data packet Would the protocol still work? (Hint: Consider what would happen if there were only bit errors; there are no packet losses but premature timeouts can occur Consider how many times the nth packet is sent, in the limit as n approaches infinity.) - Giao thức rtd3.0 sử dụng để truyền liệu từ người gửi đến người nhận + Nếu người gửi chuyển gói đến người nhận, người nhận nhận gửi ACK (Lời cảm ơn) cho người gửi để cấu hình + Nếu người nhận nhận gói tin mà bit khơng theo thứ tự xảy lỗi khơng gửi xác nhận Người gửi truyền lại gói tin sau hết thời gian + Nếu gói gửi nhiều lần, giao thức khơng hiệu Lý cố gắng gửi gói định gói chờ khơng bị gián đoạn cịn lại phải đợi gói định phân phối P14 Consider a reliable data transfer protocol that uses only negative acknowledgments Suppose the sender sends data only infrequently Would a NAK-only protocol be preferable to a protocol that uses ACKs? Why? Now suppose the sender has a lot of data to send and the end-to-end connection experiences few losses In this second case, would a NAK-only protocol be preferable to a protocol that uses ACKs? Why? - Giao thức NAK khơng thích hợp giao thức sử dụng ACK, đặc biệt người gửi gửi liệu thường xuyên • Giao thức NAK phát gói tin bị người nhận nhận gói tin • Vì người gửi gửi liệu thường xuyên, giao thức NAK nhiều thời gian để nhận gói tin bị • Giao thức NAK nhận gói tin bị người nhận nhận gói tin có số thứ tự, khơng theo thứ tự • Người nhận sau gửi NAK đến gói tin bị cho người gửi • Sau người gửi phải truyền lại gói bị gói - Khi người gửi gửi liệu thường xuyên tỷ lệ liệu ít, giao thức NAK thích hợp giao thức sử dụng ACK • Vì người gửi gửi liệu thường xuyên, giao thức NAK nhanh chóng nhận gói tin bị • Trong giao thức NAK, người nhận khơng cần phải gửi xác nhận cho gói tin mà người nhận nhận • Vì tỷ lệ liệu ít, người nhận gửi NAK cho gói bị cho người gửi P17 Consider two network entities, A and B, which are connected by a perfect bidirectional channel (i.e., any message sent will be received correctly; the channel will not corrupt, lose, or re-order packets) A and B are to deliver data messages to each other in an alternating manner: First, A must deliver a message to B, then B must deliver a message to A, then A must deliver a message to B and so on If an entity is in a state where it should not attempt to deliver a message to the other side, and there is an event like rdt_send(data) call from above that attempts to pass data down for transmission to the other side, this call from above can simply be ignored with a call to rdt_unable_to_send(data), which informs the higher layer that it is currently not able to send data [Note: This simplifying assumption is made so you don’t have to worry about buffering data.] Draw a FSM specification for this protocol (one FSM for A, and one FSM for B!) Note that you not have to worry about a reliability mechanism here; the main point of this question is to create a FSM specification that reflects the synchronized behavior of the two entities You should use the following events and actions that have the same meaning as protocol rdt1.0 in Figure 3.9: rdt_send(data), packet = make_pkt(data), udt_send(packet), rdt_rcv(packet), extract (packet,data), deliver_data(data) Make sure your protocol reflects the strict alternation of sending between A and B Also, make sure to indicate the initial states for A and B in your FSM descriptions P22 Consider the GBN protocol with a sender window size of and a sequence number range of 1,024 Suppose that at time t, the next in-order packet that the receiver is expecting has a sequence number of k Assume that the medium does not reorder messages Answer the following questions: a What are the possible sets of sequence numbers inside the sender’s window at time t? Justify your answer Hãy xem xét liệu sau: window size (N) = , sequence number range = 1024 Trường hợp 1: • Giả sử số thứ tự gói người nhận mong đợi k giả sử người nhận nhận thừa nhận tất k-1 gói • Cửa sổ người gửi nằm dải số thứ tự [k, k + N-1] tất k-1 xác nhận nhận mà không bị Trường hợp 2: • Nếu người gửi khơng nhận thơng báo xác nhận nào, cửa sổ người gửi nằm dải số thứ tự [k-N, k-1] • Vì khơng nhận thơng báo nào, cố gắng gửi tất gói k-1 N • Vì vậy, cửa sổ người gửi nằm dải số thứ tự [k-N, k-1] Do đó, số thứ tự có bên cửa sổ người gửi thời điểm t nằm khoảng [k-N, k] b What are all possible values of the ACK field in all possible messages currently propagating back to the sender at time t? Justify your answer • Khi máy thu đợi gói có số thứ tự k bắt đầu nhận N-1 gói trước đó, giá trị có trường báo nhận (ACK) [k-N, k-1] • Đó người gửi khơng nhận N ACK, thơng điệp ACK truyền ngược trở lại • Vì người gửi gửi tất k-N gói nhận ACK cho k-N-1 từ người nhận, khơng gửi ACK nhỏ ACK n-N-1 Do đó, tất giá trị có trường ACK tất thông báo truyền ngược trở lại người gửi thời điểm t nằm dải giá trị ACK chúng nằm khoảng từ k-N-1 đến k-1 P23 Consider the GBN and SR protocols Suppose the sequence number space is of size k What is the largest allowable sender window that will avoid the occurrence of problems such as that in Figure 3.27 for each of these protocols?