Наверное, стоит всё же перестать носом воротить, и начать смотреть, как остальные кэш ивентов оборудовали. Потому что я, по всей видимости, охуею разбираться, почему еполл - настолько ущербный и поломанный. Нет, ну реально, он отправляет EPOLLRDHUP ивенты даже тогда, когда ты их и не просил вовсе! Так ладно это. Он это делает избирательно! Не всегда! Он, сука, НЕКОНСИСТЕНТНЫЙ!!!

Надеюсь, что это я его просто не осилил, но это всё ещё какой-то пиздес.

https://idea.popcount.org/2017-03-20-epoll-is-fundamentally-broken-22/

продолжение охуенной серии статей. Здесь, конечно, не описывается моя проблема, а только то, что, несмотря на заявления в мане, удалять сокет из еполла перед close() необходимо. А теперь осталось понять, КАКИМ ОБРАЗОМ МНЕ ДУБЛИРУЮЩИЕСЯ ИВЕНТЫ ПРИЛЕТАЮТ

https://yarchive.net/comp/linux/splice.html

Линус против sendfile(2), спешите видеть

https://snai.pe/posts/c-smart-pointers

Изврат

какой-то странный способ делать многострочные комментарии, конечно

Linear Algebra Done Wrong (2004)
Article, Comments

Заебись. Вводим транспозицию, чтобы место на бумаге сэкономить

https://opennet.ru/61685-ladybird

ну пащиму блять

Так атаки с амплификацией трафика - это просто отправка IP пакетов с полем source address жертвы? А разговоров-то было...

Я наконец допёр (с помощью умного поляка), почему при инстанциации сокета мы не указываем условно socket(AF_INET, SOCK_TCP), а SOCK_STREAM, SOCK_DGRAM. Сетевой стэк следует той философии, что ты выбираешь не столько протокол, сколько требуемую семантику от подключения. Соответственно, семантика SOCK_STREAM может быть реализована и по другому семейству, и не по TCP. Всё тот же AF_UNIX к примеру.

Ещё у AF_UNIX есть интересная штука - SOCK_SEQPACKET, которая по своим свойствам чётко между udp и tcp. То есть, оно даёт те же гарантии доставки и сохранения очередности, что и tcp, но сигнализирует об окончании пакета (в оригинале они это называют record) явно, как и udp. При том, что такая удобная и очень дружелюбная к программисту штука есть, в целом-то, только для AF_UNIX, в AF_INET/6 аналогичного транспортного протокола нет. Хоть его и можно имитировать на уровне tcp, что, отнюдь, всё ещё приводит к костылям. Возможно, на этом этапе уже действительно проще вынести это как часть собственного протокола над tcp (который у тебя есть примерно всегда).

Кому интересно, вот текст, описывающий всё это, только языком более компетентного человека: https://urchin.earth.li/~twic/Sequenced_Packets_Over_Ordinary_TCP.html

Вот с таким лицом я пощу свою хуйню

> In short, this principle argues that important functions (e.g., error control, encryption, delivery acknowledgment) should usually not be implemented at low levels (or layers; see Section 1.2.1) of large systems. However, low levels may provide capabilities that make the job of the endpoints somewhat easier and consequently may improve performance. A nuanced reading reveals that this argument suggests that lowlevel functions should not aim for perfection because a perfect guess at what the application may require is unlikely to be possible.

А я знал! Я знал! Индига шла по правильному пути.

М, забавно.

TL;DR заметная доля well-known портов, зарегистрированных в IANA, нечётные. Потому что они существуют ещё со времён arpanet, в которой подключения были унидирекционные (полудуплексными), т.е. односторонними, для чего для каждого приложения резервировалось сразу два порта - один для IN, второй для OUT

https://www.youtube.com/live/6ghNSnsEL0Q

мужик злится смешно

Прилетел, спиздил и улетел

https://github.com/golang/go/issues/19623

Ёбаный позор.

Просто для справки: после этого ишшуя, пройдёт 3 года до того, как в го1 появятся дженерики. НУ ТО ЕСТЬ ДАВАЙТЕ ДОБАВИМ ЭТОТ ЁБАНЫЙ СТЫД В ГО2 ВМЕСТО ДЖЕНЕРИКОВ В ГО1

Начинаю подозревать, что уход Пайка с поста - это хорошее решение