makurov Jun 3 2021 at 11:20

Опыт написания асинхронного поллинга сетевых устройств

6 min

5.9K

Programming*IT Infrastructure*C*Network hardware

+16

Comments 10

Slach Jun 3 2021 at 12:09

Отличная статья, спасибо

Slach Jun 3 2021 at 12:09

Но не помешают ссылки на gitlab

makurov Jun 3 2021 at 12:14

Читал что это «не по правилам», вот и не стал писать
А вообще https://gitlab.com/mikler/glaber

linuxoid Jun 3 2021 at 17:26

Так-то да, если цель — продать продукт. У вас же чисто инженерное "смотрите, как я сделал". ИМХО, именно для этого и есть Хабр.

makurov Jun 4 2021 at 02:43

Ну черт знает. По честному, там же все равно какой то личный профит в конце, даже если он в том, чтобы «сделать мир лучше».

event1 Jun 3 2021 at 15:23

Сколько нужно потоков, чтобы увидеть, что они заработали в течении 30 секунд? — Около 7 тысяч.

Вот этот момент смутил. Неужели 10к потоков, спящих на сокетах, являются проблемой для современного сервера?

linuxoid Jun 3 2021 at 17:15

вообще, спавнить нативные потоки на такую нагрузку — предельно странное решение. Нативные потоки очень дорогие.

makurov Jun 4 2021 at 02:37

У меня нет цифр под рукой, но когда то посчитал, что «дорого» получится. И потоками и форками тем более. Там два очевидных ресурса — память, и ресурсы процессора на переключение контекста.

linuxoid Jun 3 2021 at 17:10

А зачем мы пишем шедулер сами?

Почему не взяли GO? Он прям для этого сделан. Спавним горутину на сокет/устройство. Из коробки шедулинг, параллелизация. Если надо, можно шардировать горизонтально кучей разных способов/библиотек. Нативная сборка, можно собрать, чтоб хоть на ведроиде работать будет...

Куча библиотек сервисного уровня для легкого fallback, short-circuit и т.д.

makurov Jun 4 2021 at 02:42

Очень в тему, спасибо.

Да, я бы сказал так — тогда был выбран такой путь, сейчас решение расширения функциональности на Go мне кажется самым верным и так оно и делается для нового функционала. Но я этот путь чуть позже асинхронного SNMP осознал, поэтому там осталось на С.

На самом деле на Go я одновременно с реализацией 4 прорабатывал. Но там копились разные мелочи — то мибы не транслируются, то поддержки v3 нет, то что то еще. В общем, учитывая опыт в С и отсутсвие такового в Go, решил в какой то момент оставить реализацию на С.

А так то было бы очень интересно сравнить ресурсы на Go и на С (память и CPU) на одинаковой задаче. Учитывая скорость разработки и количество библиотек, выбор очевиден.

А сейчас расширение функционала (адаптеры к разным системам хранения, сервера, воркеры) именно так и делаются — все на Go