From cd14c3c1c7593ddb7095892a088d7b6034b0357e Mon Sep 17 00:00:00 2001 From: Sergey Matveev Date: Fri, 11 Nov 2022 21:52:43 +0300 Subject: [PATCH] =?utf8?q?=D0=A3=D0=BB=D1=83=D1=87=D1=88=D0=B5=D0=BD=D0=B8?= =?utf8?q?=D1=8F=20dht-bootstrap?= MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit http://www.git.stargrave.org/?p=dht-bootstrap.git;a=summary Всё не могу успокоиться играться с правкой dht-bootstrap демона (aa2617fbedd389ae134e81f8b3461f495c8cb6ef). * использование arc4random() (в GNU/Linux-ах можно getrandom()) сокращает код, плюс не требует явной работы с файлами (чтения из /dev/urandom). Более того, в glibc arc4random уже тоже добавили * состояние о количестве известных нод теперь "показываю" в названии процесса. И stdout/логи не загромождает, и посмотреть можно легко * отладочный вывод показывает конкретные IP-адреса(+порты) всего происходящего * закрываю лишние файлы, ограничиваю ресурсы rlimit-ом Всё это ещё было портабельным. Но очень хотелось использовать Capsicum. Обломался, так как посылка UDP пакета на адрес к которому прежде не было connect-а -- невозможна в Capsicum, который ограничивает доступ к global namespace, к которому относятся и IP-адреса. Сделал в итоге privilege separated решение: отдельный процесс который занимается только отправкой UDP пакетов, принимая данные из заранее связанного сокета. Основной же демон, который принимает пакеты, парсит их -- под Capsicum sandbox-ом работает. А раз всё равно я это уже перевёл на FreeBSD из-за Capsicum, то и смысла держать poll() нету. Перевёл на использование kqueue(). Происходит из-за этого дополнительное копирование содержимого исходящих пакетов, для их отсылки через сокет дочернему процессу -- но да и ладно, ибо нагрузка и так смехотворная. -- 2.50.0