2016-09-23 2 views
0

Я пытаюсь реализовать один стек tcp. следующие шаги, которые я последовавшие:Ошибка управления потоком TCP

  1. TCP открытые:

    а. Клиент отправил «SYN» с начальной последовательностью «C» и Ack no «0» на сервер.

    b. Сервер ответил SYN + ACK с seq no «S» и ack no «C + 1».

    c. Клиент отправляет ACK + PSH с последовательностью «C + 1» и не имеет значения «S + 1».

  2. TCP посыла и RECV:

    а. Клиент отправит запрос данных с флагом ACK и данными с последующим отсутствием «C + 1» и ack no «S + 1»

    b. Отправитель отправит графу с seq no «S + 1 + data» в сегменте, и приемник отправит ACK с ack no «S + 1 + data» будет продолжаться до тех пор, пока FIN или RST не будут переданы.

В моем случае во время передачи данных я получаю мало пакетов, но могу видеть их на проводах.

Есть ли какой-либо механизм для проверки отказа от данных заказа и потеря пакетов, используя порядковый номер и номер Ack и получить пакет обратно

+0

Вы пишете свой собственный низкоуровневый tcp или используете системные функции для записи и получения? – HeadCode

+1

его низкий уровень tcp – Pawan

ответ

1

Если вы получаете сегмент с порядковым номером выше, чем следующая последовательность ожидается, вы должны отправить последний ACK. Это сообщает отправителю, что некоторые сегменты были потеряны, и он должен немедленно повторно передать все сегменты, ожидающие подтверждения.

Лучшим решением было бы реализовать вариант выборочного подтверждения в RFC 2018. Это позволит вам признать полученные сегменты не в порядке, и отправитель будет только повторно передавать те, которые были упущены.

+0

Если я отправлю последний ACK, он начнет отправлять пакеты с последнего ACKed или начнет отправку с самого начала. – Pawan

+0

Он будет отправлен с последнего ACK. – Barmar

+1

Ничто из того, что уже было признано, никогда не возмущается. – Barmar

Смежные вопросы