хм, это что получается, гарантирует ли нам TCP доставку или таки нет?

не доставку, а подтверждение доставки

+ ioctl/SIOCOUTQ

но обычно это не нужно, после опр. кол-ва ретрансмитов неподтвержденных пакетов соединение будет разрушено

Значение 2, в примере выше, не подтверждает доставку. Мы можем потерять данные навсегда.

Я не знал о SIOCOUTQ. Думаю, это решит проблему, если данные терять нельзя.

Есть мысль, что это компромисс на который разработчики ядра идут, позволяя буферизировать данные и таким образом считая их отправленными (write возвращает 2).
Это позволяет значительно ускорить передачу и только в таких редких случаях, см. пример выше, потерять данные размером не выше буфера TCP сокета.

> Я не знал о SIOCOUTQ. Думаю, это решит проблему, если данные терять нельзя.
это ничего не решит )

данные были отправлены, получены, ack потерялся, связь порвалась (свичи сгорели)

15 минут примерно, да.
приложение получит сигнал, но как и какой -- зависит от оси, api итп.
нормально, просто закроется файл/дескриптор/сокет. лови закрытие файла.

и что должно быть в этом случае?

или c selective ack - когда ackи вообще не были отправлены (еще), а канал уже порвался

Если читать/писать асинхронно через select() никаких блокировок не будет

разговор не про это

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

если надо гарантию доставка/получение, надо поверх tcp городить MQ какое-то.

в общем, о том, что получено достоверно может знать только получатель. грубо говоря, именно клиент запрашивает Content-Range для докачки, а не сервер контролирует что дал что не дал для *разных* сокетов

sctp можн

@insoln по sctp я не обманул? )

я хз :)

вообще с ним не сталкивался

C такой проблемкой столкнулся, сделал vpn тонель на францию на адреса VK, mail ru, но на одном тике браузеры жалуются на сертификат, в чем может ыть проблема?