Size: a a a

2018 August 02

I

Innokentiy in Pro Telecom
но там не 30 минут совсем
источник

I

Innokentiy in Pro Telecom
намного быстрее, десяток секунд от силы
источник

I

Innokentiy in Pro Telecom
а не. наврал
источник

I

Innokentiy in Pro Telecom
источник

AE

Andrey Enshin in Pro Telecom
аха, т.е. ядро, скопировав 100 байт из буфера приложения в ядерный буфер сокета, не  скажет мне, что 100 послано, покуда не получит ACK?
а ак оно не получит никогда и нам останется ждать tcp_retries2

http://man7.org/linux/man-pages/man7/tcp.7.html
источник

I

Innokentiy in Pro Telecom
угу
источник

AE

Andrey Enshin in Pro Telecom
окай, теперь вопрос, где описано это поведение?
я имею ввиду покуда нет ACK не говорить приложению, что данные посланы
источник

AE

Andrey Enshin in Pro Telecom
ядро же может вести себя как с записью на диск с буферизацией:
приложение пишет на диск, ядро копирует в свой буфер, но на диск не пишет до следующего fsync ( так эффективнее, писать на диск батчами).
источник

AE

Andrey Enshin in Pro Telecom
при этом приложению говорит - ок, я записало на диск 100 байт
источник

V

Viktorich in Pro Telecom
Andrey Enshin
окай, теперь вопрос, где описано это поведение?
я имею ввиду покуда нет ACK не говорить приложению, что данные посланы
Скорее не посланы, а доставлены
источник

AE

Andrey Enshin in Pro Telecom
угу
источник

AE

Andrey Enshin in Pro Telecom
ааа! всё не так!

Делаем раз в одном терминале:
$ nc -kl 1234

Делаем два в другом терминале:
$ nc -v localhost 1234
шлём чо нить

Делаем три в третьем терминале:
$ sudo sysctl net.ipv4.tcp_retries2=3
$ sudo iptables -A INPUT -s 127.0.0.1 -p tcp --source-port 1234 -j DROP
$ watch "netstat -nutap | grep 1234"


Возвращаемся во второй терминал и шлём ещё чего-нить. Смотрим на третий терминал и видим приращение в Send-Q.

Для убедительности стрейсим неткат во втором терминале:
...
read(0, "6\n", 2048)                    = 2
write(3, "6\n", 2)                      = 2
poll([{fd=3, events=POLLIN}, {fd=0, events=POLLIN}], 2, -17
...


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

AE

Andrey Enshin in Pro Telecom
хе-хе
важный момент, таки неткат работает в неблокирующем режиме
fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
источник

AE

Andrey Enshin in Pro Telecom
поэтому write и возвращает 2
источник

AE

Andrey Enshin in Pro Telecom
значит пока что всё в порядке с TCP )))
источник

VG

Vladislav Grishenko in Pro Telecom
Andrey Enshin
поэтому write и возвращает 2
это не важно, не ошибка же возвращается
источник

VG

Vladislav Grishenko in Pro Telecom
см. setsockopt/SO_SNDBUF/TCP_NODELAY, getsockopt/TCP_INFO
источник

AE

Andrey Enshin in Pro Telecom
не важно для чего?
источник

VG

Vladislav Grishenko in Pro Telecom
для понимания. O_NONBLOCK тут не имеет эффекта, если с ним записалось, то и без будет
источник

AE

Andrey Enshin in Pro Telecom
да, точно, вернуло бы -1
источник