Pull to refresh

Comments 14

Замечание. Не «быстрые TCP-сокеты» и не «оптимизация TCP-сокетов», а быстрые биндинги/обёртки и оптимизация биндингов/обёрток. К сокетам это отношения не имеет.
s/с наростающей скоростью/с нарастающей скоростью/
> Если ваш протокол может обрабатывать частичные сообщения

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

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

Я надеюсь вы не считаете, что в {tcp, Socket, Bin} приходят какие-то сообщения, которые можно обрабатывать без накапливания в буфере?
я не считаю что можно обрабатывать без накопления, там несколько уровней буферов и может возникнуть ситуация, когда сокет закрылся, но часть данных приложения уже ушла. Можно просто выкидывать такие куски на другой стороне, а можно пытаться продолжить после открытия нового сокета
Требую добавить тесты с {active, true} и {active, once}! :)
А что может дать {active, N}?
По логике позволяет более гибко реализовывать flow control. Я сам не использовал, но если топикстартер добавит в сравнение — узнаем лучше с ним или нет.
не могу сказать почему именно, но с ним работает лучше, чем без него.

Речь идет о трафике порядка 500 мбит/с и выше.
Вот поэтому хотелось бы тесты и с этими параметрами
честно говоря, непонятно как такие вещи воспроизвести.

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

Articles