程序代写代做代考 更新

更新

4/12: Please disregard the example in Section 2.8 in the Assignment and
look at the revised example below:

 

(Note that the timeouts are reset when the window moves. Also, with one
execution of the program node 1 should be able to send a message to node 2,
both nodes will print out a summary when finished and then node 2 should be
able to send a message to node 1 and then both nodes will print a summary for
that message transfer)

 

$ ./gbnnode 1111 2222 5 -p 0.1

node> send abcdefgh

[1353035731.011] packet0 a sent

[1353035731.031] packet1 b sent

[1353035731.049] packet2 c sent

[1353035731.062] ACK0 received, window moves to 1

[1353035731.078] packet3 d sent

[1353035731.082] ACK1 received, window moves to 2

[1353035731.087] packet4 e sent

[1353035731.090] ACK1 received, window moves to 2

[1353035731.103] packet5 f sent

[1353035731.106] ACK1 received, window moves to 2

[1353035731.118] packet6 g sent

[1353035731.124] ACK1 received, window moves to 2

[1353035731.136] ACK1 received, window moves to 2

[1353035731.582] packet2 timeout

[1353035731.585] packet2 c sent

[1353035731.587] packet3 d sent

[1353035731.593] ACK2 received, window moves to 3

[1353035731.599] packet4 e sent

[1353035731.605] ACK3 discarded

[1353035731.599] packet5 f sent

[1353035731.615] ACK4 received, window moves to 5

[1353035731.615] packet6 g sent

[1353035731.619] packet7 h sent

[1353035731.625] ACK5 received, window moves to 6

[1353035731.627] ACK6 received, window moves to 7

[1353035731.631] ACK7 received, window moves to 8

[Summary] 1/12 packets discarded, loss rate = 0.083

node>

 

Receiver side:

$ ./gbnnode 2222 1111 5 -p 0.1

node>

[1353035731.033] packet0 a received

[1353035731.042] ACK0 sent, expecting packet1

[1353035731.053] packet1 b received

[1353035731.059] ACK1 sent, expecting packet2

[1353035731.072] packet2 c discarded

[1353035731.079] packet3 d received

[1353035731.084] ACK1 sent, expecting packet2

[1353035731.095] packet4 e received

[1353035731.101] ACK1 sent, expecting packet2

[1353035731.106] packet5 f received

[1353035731.113] ACK1 sent, expecting packet2

[1353035731.119] packet6 g received

[1353035731.120] ACK1 sent, expecting packet2

[1353035731.588] packet2 c received

[1353035731.590] ACK2 sent, expecting packet3

[1353035731.596] packet3 d received

[1353035731.601] ACK3 sent, expecting packet4

[1353035731.604] packet4 e received

[1353035731.607] ACK4 sent, expecting packet5

[1353035731.617] packet5 f received

[1353035731.619] ACK5 sent, expecting packet6

[1353035731.621] packet6 g received

[1353035731.623] ACK6 sent, expecting packet7

[1353035731.625] packet7 h received

[1353035731.629] ACK7 sent, expecting packet8

[Summary] 1/13 packets dropped, loss rate = 0.076

node>








4/12: Addressing a typo in loss rate calculation for part 4 

The last bullet of 4.4 says that probe receivers learn of the loss rate (total #
dropped packets / total # sent packets) via a DV update from the probe sender.
It should be the sender learning this loss rate from the receiver via DV updates.
Probe senders aren’t dropping anything (ACKs are not dropped).

 

Note how in 4.6, (the loss rate probabilities) only follow the
receiver command. Thus, the receivers are the ones with a target probability,
and they are the ones dropping packets and computing the link cost as
described in 4.2.