OS Linux 2.6.19. Имеется установленный TCP-коннект, доступный по дескриптору сокета ( socket, connect... ). Я делаю на этот дескриптор write 64-х байт. Write возвращает 64, а адресат говорит, что получил 64 байта. Всё хорошо. Делаю коннект вновь, засыпаю. В это время умирает физический уроевень. Просыпаюсь, делаю Write 64-х байт. Write возвращает 64, адресат ничего не получает. Локальный TCP-стек делает попытки отправить кусок снова и снова, ожидая ACK. А его всё нет и нет.
1. Задача - узнать о том, на какое количество данных на момент узнавания не получено подтверждения или как при каком-либо разрыве коннекта узнать, что успел получить адресат?

Как я себе представляю предназначение TCP.

Люди хотят передавать очень длинные последовательности байт. И важно не то, сколько байт дошло, а какой за каким следует. Но internet может гарантировать сохранение последовательности только внутри одного IP-пакета. А много IP-пакетов он вправе передать хаотически.

Чтобы в таких условиях передать очень длинный поток байт, не умещающийся в один пакет, этот поток бьют на тысячи IP-пакетов, нумеруют их и беспорядочно выметают в internet. Потом они хаотически приходят получателю.

На приёмную сторону IP-пакеты падают беспорядочно, как дождь. Но там сидит уный TCP, который все пойманные в кучу пакеты составляет друг за другом по их номерам, предлагая приложениям, его использующим, цельный поток. И если TCP поймал пакеты 0...49, 51...100, то вам он сразу отдаст поток из первых пятидесяти пакетов, потом дождётся пакета номер 50, вклеит его между 49 и 51 и отдаст вам вторую половину потока.

Передающий TCP принимает от программы поток байт, бьёт его на куски, каждый кусок нумерует строго по порядку, кладёт куски в лопату и в internet высыпает сразу всю лопату. Но нумерация двухбайтная, поэтому если кусков больше 65536, номера начинают повторяться. И вот тут TCP опасается, что два куска, высыпанные в Сеть с одним номером могут запутать моск приёмному TCP, поэтому надо как-то договариваться. Для этого сделали такую штуку: приёмный TCP , приняв кусок с некоторым номером, сообщает передающему, что этот номер можно использовать снова. Это и есть ACK. Постепенно у передающего TCP снова образуется множество последовательных свободных номеров и ими он нумерует очередную последовательность пакетов, кладёт в лопату и снова высыпает в сеть.

Вот такого предназначение ACK, как я понимаю. Тогда хотелось бы попинать авторов статей, которые написали "TCP гарантирует доставку". Каждый это трактует по-своему. Найдётся даже человек, который поймёт это так:
- Если подтверждения нет, посылка повторяется.
- Если снова подтверждение нет, посылка повторяется ещё.
- Так три раза.
- Если подтверждения нет, происходит вызов начальника технической службы системы, в которой происходит передача и происходит предьявление ему претензий (ПЕП).
- Если подтверждения нет, вызывается группа слежебных роботов "сходить проверить, чё там на приёмной стороне".
- Если подтверждения нет, происходит вызов министра связи страны и происходит ПЕП. И т.п.


TCP не гарантирует доставку, он гарантирует неприкосновенность порядка байт в потоке.

Я хотел выяснить, равно ли нулю кол-во неподтверждённых кусков. Чтобы гарантировать себе, что удалёное приложение меня выслушало.

Но я забыл, что выслушивает меня не удалённое приложение, а удалённый TCP-стек. А приложение, которое приняло коннект, может давно уже лежать в коме, не успев закрыть коннект.

BarloneВсё не правильно. Sequence Number и Acknowledgment Number - 32 бита. И нумеруют они не пакеты, а байты в потоке. У каждого байта свой номер. Потому что маршрутизатор между отправителем и получателем может порезать большие пакеты на пакеты меньшего размера. И повторные отсылки пакета если подтверждение не получено есть.
rfc793The TCP must recover from data that is damaged, lost, duplicated, or delivered out of order by the internet communication system. This is achieved by assigning a sequence number to each octet transmitted, and requiring a positive acknowledgment (ACK) from the receiving TCP. If the ACK is not received within a timeout interval, the data is retransmitted. At the receiver, the sequence numbers are used to correctly order segments that may be received out of order and to eliminate duplicates. Damage is handled by adding a checksum to each segment transmitted, checking it at the receiver, and discarding damaged segments.

Ну абстрактно я всё правильно сказал. Нумерация байт или нумерация пакетов - уже избыточное уточнение технологии, без которого сохраняется смысл моих распинаний о том, что такое гарантия доставки. Ладно, смайлик -> :) :) :)

Ответ:

unsigned int x;

ioctl ( descriptor, SIOCINQ, &x );

Но есть неясности.

http://dramele.livejournal.com

Да, SIOCOUTQ.

Задача отпала.

Хотел написать класс tcp-коннектилки-отправлялки. Умеет коннеткиться, брать данные и заботиться о доставке. Для загрузки в него данных у него есть метод. Данные попадают в буффер конечной длины. Данные вытряхиваются из буффера по получении подтверждения о том, что их увидел удалённый TCP. Если коннект обрывается, делается попытка его восстановления и таки посылки содержимого буффера. И т.п.

Теперь решил поменять тех. задание. В новом ТЗ допустима потеря данных на уровне TCP без постановки в известность об этом приложения. Теперь буффер в классе не нужен, а в метод сжирания данных выглядит так: return write ( this -> connection_descriptor, data, size );