что произойдет после изменения строки в протоколе Stop и Wait (симплекс)? - PullRequest
0 голосов
/ 18 апреля 2019

пытался исследовать его во многих местах, но я все еще не уверен, и буду признателен за вашу помощь в этом коротком вопросе:

что произойдет, если мы изменим "to_physical_layer (& s)" на "to_physical_layer (& r)"в следующем коде (отмечен в коде где)?это делает протокол неудачным?если так, покажите сценарий, он потерпит неудачу.если нет - объясните, есть ли преимущество или недостаток в изменении.

код:

(simplex stop and wait protocol from tanenbaum's book):

typedef enum {frame-arrival} event_type;
#include "protocol.h"

void sender2(void){
  frame s;           // buffer for frame
  packet buffer;   // buffer for packet
  event_type event;  // frame_arrival only
  while (true) {
    from_network_layer(&buffer); // get packet
    s.info = buffer;        // copy it into frame
    to_physical_layer(&s);  // send it
    wait_for_event(&event); // wait for ack
  }
}

void receiver2(void) {
  frame r, s;        // buffers for frames
  event_type event;  // frame-arrival only
  while (true) {
    wait_for_event(&event);  // wait for frame
    from_physical_layer(&r);  // get frame
    to_network_layer(&r.info); // pass data
    question is regarding this line--> to_physical_layer(&s);
      // send a dummy frame to awake sender
  }
}

что я понимаю: в основном базовая строка с "to_physical_layer (& s); // sendфиктивный кадр для пробуждения отправителя »отправляет фиктивный кадр (ACK) отправителю, чтобы уведомить его о том, что он получил пакет и что он может продолжить отправку следующего пакета.из-за этого содержание ACK, отправляемого от получателя, не имеет значения, так как вся цель состоит в том, чтобы просто отправить пакет в качестве подтверждения (также чтобы избежать отправителя, отправляющего пакеты быстрее, чем получатель может получить imho).однако я не понимаю, что произойдет, если мы поменяем to_physical_layer (& s) на to_physical_layer (& r) в отмеченной строке.я думаю, что он в основном отправляет полученному кадру вместо простого ack или фиктивного кадра получателю.поэтому, если это так, то он не потерпит крах (если буфер для принятого кадра не больше, чем тот, который кадр может обработать или отправить отправителю 2. Однако это, безусловно, замедлит широковещательную рассылку, поскольку теперь пакет стал намного больше, и посколькуэто пакет за пакетом (отправителю нужно получить пакет, прежде чем он сможет отправить следующий), тогда весь процесс будет значительно замедлен.

что вы думаете? я прав? если нет, пожалуйстапоправьте меня, чтобы я мог учиться на своих ошибках

...