Быстрые TCP сокеты на Erlang

[@firsttimecxx]

Замечание. Не «быстрые TCP-сокеты» и не «оптимизация TCP-сокетов», а быстрые биндинги/обёртки и оптимизация биндингов/обёрток. К сокетам это отношения не имеет.

[@alexeiromanoff]

s/с наростающей скоростью/с нарастающей скоростью/

[@parsifal]

спасибо, исправил

[@erlyvideo]

> Если ваш протокол может обрабатывать частичные сообщения

а причем тут TCP? В нём ведь нет сообщений

[@parsifal]

всё правильно, сообщения появляются на уровне приложения, а передаются они через TCP. Когда приложение может обработать неполное сообщение, полезно знать сколько было обработано

[@erlyvideo]

я всё равно не понимаю, о чём вы пишете.

по TCP передается поток байт. Никаких полных или неполных сообщений в нём нет, пока вы передаете целостные данные.

Я надеюсь вы не считаете, что в {tcp, Socket, Bin} приходят какие-то сообщения, которые можно обрабатывать без накапливания в буфере?

[@parsifal]

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

[@UA3MQJ]

Требую добавить тесты с {active, true} и {active, once}! :)

[@EvilBlueBeaver]

Тогда уж и {active, N} надо добавлять

[@UA3MQJ]

А что может дать {active, N}?

[@EvilBlueBeaver]

По логике позволяет более гибко реализовывать flow control. Я сам не использовал, но если топикстартер добавит в сравнение — узнаем лучше с ним или нет.

[@erlyvideo]

не могу сказать почему именно, но с ним работает лучше, чем без него.

Речь идет о трафике порядка 500 мбит/с и выше.

[@UA3MQJ]

Вот поэтому хотелось бы тесты и с этими параметрами

[@erlyvideo]

честно говоря, непонятно как такие вещи воспроизвести.

Разницу между active,once и active,N мы видим только и исключительно на продакшне. Воспроизвести это даже на 10-гигабитном офисном стенде не получается