соединений используется ranch. Но дело в том, что у этого сервера вообще никогда не будет большого количества соединений и поэтому тащить в приложение целую библиотеку ради accept'а не хочется. С другой стороны, есть вот такая реализация https://saleyn.github.io/non-blocking-tcp-server.html которую я не против адаптировать под себя, но уже здесь смущает, что автор использует недокументированные функции которые могут менять своё поведение в следующих, а возможно и в текущем, релизах erlang. Что посоветуете выбрать?
В чем проблема тащить библиотеку?
проблемы нет, и как я уже написал выше - сейчас так и сделано
У меня тоже иногда руки чешутся сломать то что работает
Я так понимаю этот пост устарел с какой-то версии OTP. Cейчас можно сделать аналогично, но с гарантией совместимости на модуле socket. Но вообще сначала стоит задаться вопросоми (а) А чем ранч плох? (б) Зачем в этом проекте полностью неблокирующий сервер?
Спасибо за наводку, почитаю. Если есть примеры был бы рад. Отвечая на ваши вопросы: а) ranch полностью реализует требуемый функционал, но здесь видимо проблема во мне - целая библиотека для реализации одной "простой" функции - избыточно, imho. б) хороший вопрос! Видимо даже и не нужен. Думал в этом ключе исходя из соображений best practice. На этом pet-проекте я изучаю elixir, вот и пробую разное
В чем проявляется избыточность?
Ranch богатая функционалом библиотека, мне необходим один лишь accept. Это избыточно. Именно так дистрибутивы софта стали весить гибибайты и depedency hell ногами растёт оттуда же
Там не так уж и много функционала Там динмаический пул tcp-обработчиков + несколько удобных функций Пул пришлось бы в любом случае пришлось бы реализовать, только тут уже за тебя набили все шишки. А остальными фичами можно просто не пользоваться. А касательно "дистрибутивы софта стали весить гибибайты и depedency hell ногами растёт оттуда же", это как раз идёт от NIH и желания написать тот код, который уже написан, но по-своему
Статья так-то списана с ranch, он первым вроде-бы этот трюк применил. И смысл его основной - не писать самому развязку транспорт-протокол, так что в случае чего убережёт от переписывания и пару клиент-сервер для тестов можно получить почти бесплатно.
Обсуждают сегодня