Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 12
Легкая, надёжная, но с Python 3 не совместимая из-за свой зависимости на gevent. Жаль.
С недавних пор gevent работает под py3.3+
С каких пор? На сколько мне известно это еще в девелопмент состоянии.
Да и эта ошибка как бы намекает на синтаксис питона 2.x
File "/private/var/folders/5m/hhwdehdewhdwed/T/pip-build-bp461rpq/gevent/setup.py", line 111, in make_universal_header
print >>f, line
TypeError: unsupported operand type(s) for >>: 'builtin_function_or_method' and '_io.TextIOWrapper'
поставить попробовал только что.
Да и эта ошибка как бы намекает на синтаксис питона 2.x
File "/private/var/folders/5m/hhwdehdewhdwed/T/pip-build-bp461rpq/gevent/setup.py", line 111, in make_universal_header
print >>f, line
TypeError: unsupported operand type(s) for >>: 'builtin_function_or_method' and '_io.TextIOWrapper'
поставить попробовал только что.
Кроме того под asyncio есть aiozmq в которой есть аналогичный RPC через эти же — zmq и msgpack.
Меня больше всего волновал этот вопрос, ибо в моей реализации я уперся в то, что при большой нагрузке я терял больше 40% сообщений на udp сокетах, что собственно не очень-то удивительно…
А вы пробовали увеличить буфер сокета?
Не знаю как в питоне, но в C это выглядит как-то так:
int sock = /* инициализация сокета, бинд */;
int new_size = 1024*1024;
setsockopt(sock,SOL_SOCKET,SO_RCVBUF,&new_size,sizeof(new_size));
или в QT:
QUdpServer *udp = new QUdpServer();
udp->bind(....);
udp->setSocketOption(QAbstractSocket::ReceiveBufferSizeSocketOption, 1048576);
Мне очень интересно проблема только в этом была или еще в чем-то.
Проблем было несколько.
С изменением буфера самого сокета, честно говоря, не пробовал.Возможно это бы решило проблему, но сеть мне не подсказала о таком решении в тот момент. Постараюсь в ближайшие дни попробовать проверить.
А основные проблемы были связаны с потерей пакетов и разрывом соединения (в случае tcp). Также несколько раз упирался в перемешивание сообщений, вот тут уж с чем это связанно, я честно признаться, совсем не знаю.
С изменением буфера самого сокета, честно говоря, не пробовал.Возможно это бы решило проблему, но сеть мне не подсказала о таком решении в тот момент. Постараюсь в ближайшие дни попробовать проверить.
А основные проблемы были связаны с потерей пакетов и разрывом соединения (в случае tcp). Также несколько раз упирался в перемешивание сообщений, вот тут уж с чем это связанно, я честно признаться, совсем не знаю.
Если перемешивание сообщений было в udp то это нормально. Связано чаще всего с одной вещью — параллельные пути внутри сети. Часто бывает так, что пакет, который отправили позднее — пришел раньше.
Или же QoS (что редко встречается в современных сетях) — один пакет по какой-либо причине попридержали в буфере перед отправкой.
Или же QoS (что редко встречается в современных сетях) — один пакет по какой-либо причине попридержали в буфере перед отправкой.
Понятно. Да именно с udp такое и происходило…
А случайно не подскажите, что почитать по теме, дабы таки разобраться в вопросе как следует?
А случайно не подскажите, что почитать по теме, дабы таки разобраться в вопросе как следует?
По теме сетей? Тут очень обширно. Когда то (в 2000 году кажется) мне очень понравились Олиферы. Но вряд ли там будет объяснено про параллельные пути.
Давайте я коротко вам тут попытаюсь объяснить.
1. Как работает роутинг в Интернет: много много сетевых устройств соединены друг с другом. Объединение этих устройств образует граф. Чтобы дойти из одной точки графа в другую точку графа надо пройти какой-то путь в этом графе. Чаще всего таких путей может быть несколько. Но не все пути будут одинаковыми, один путь будет короче, другой длинее (как физически, так и по задержкам). Понятно, что чем короче путь — тем быстрее пакет дойдет до адресата. И было бы выгодно использовать этот маршрут. Но когда стали использовать этот принцип, быстро выяснилось, что некоторые дуги в этом графе (физические линки, оптика) не загружены трафиком, а некоторые перегружены трафиком. Поэтому с помощью некоторых технолочиских ухищрений трафик в этом графе научились отправлять по паралельным линкам. И иногда так получалось, что один пакет из tcp сессии шел через одного провайдера, а второй пакет через другого (обычно пытаются сделать так, чтобы одна tcp сессия шла всегда одинакова, но я видел огромное количество противоположенных примеров). Понятно, что сети у разных провайдеров разные, и часто так получалось, что у одного провайдера пакет подзадерживался то тут, то там (особенно если сеть у провайдера перегружена), а у другого провайдера пакет пролетал со свистом через всю сеть. И получалось, что пакеты приходили в разное время, хотя, казалось бы начинали они идти по сети почти одновренно.
2. Что касается QoS — Quality of Service то тут все просто. QoS обычно настраивают для того, чтобы обеспечить заданное качество обслуживание на сети. Одна из политик QoS — буферизация трафика. Как оно работает — когда видим, что линк у нас на 100Mb/s, а в него пытается проползти 1Gb/s, мы засовываем в линк столько, сколько влезет, а остальное складываем в буфер с мыслью: «а вдруг этот 1Gb/s станет жалким 1Mb/s, а мы потом успеем все в линк покидать». Буферизация приводит к тому, что один пакет задержался в буфере, а второй под шумок пролез параллельным путем.
Или был такой механизм как WFQ — когда маленькие пакеты получали приоритет перед большими при отправке через низкоскоростные интерфейсы. На более высокоскоростных интерфейсах это стало неважно.
Все что я попытался объяснить тут справедливо для Интернета и мало справедливо для обычной локальной сети (хотя для локальной сети большого предприятия это тоже может быть справедливо).
P.S.: Кстати еще по сетям очень рекомендую цикл статей на хабре — Сети для самых маленьких. Начало я не читал, честно говоря, но вот часть про MPLS написана просто очень отлично habrahabr.ru/post/246425
Давайте я коротко вам тут попытаюсь объяснить.
1. Как работает роутинг в Интернет: много много сетевых устройств соединены друг с другом. Объединение этих устройств образует граф. Чтобы дойти из одной точки графа в другую точку графа надо пройти какой-то путь в этом графе. Чаще всего таких путей может быть несколько. Но не все пути будут одинаковыми, один путь будет короче, другой длинее (как физически, так и по задержкам). Понятно, что чем короче путь — тем быстрее пакет дойдет до адресата. И было бы выгодно использовать этот маршрут. Но когда стали использовать этот принцип, быстро выяснилось, что некоторые дуги в этом графе (физические линки, оптика) не загружены трафиком, а некоторые перегружены трафиком. Поэтому с помощью некоторых технолочиских ухищрений трафик в этом графе научились отправлять по паралельным линкам. И иногда так получалось, что один пакет из tcp сессии шел через одного провайдера, а второй пакет через другого (обычно пытаются сделать так, чтобы одна tcp сессия шла всегда одинакова, но я видел огромное количество противоположенных примеров). Понятно, что сети у разных провайдеров разные, и часто так получалось, что у одного провайдера пакет подзадерживался то тут, то там (особенно если сеть у провайдера перегружена), а у другого провайдера пакет пролетал со свистом через всю сеть. И получалось, что пакеты приходили в разное время, хотя, казалось бы начинали они идти по сети почти одновренно.
2. Что касается QoS — Quality of Service то тут все просто. QoS обычно настраивают для того, чтобы обеспечить заданное качество обслуживание на сети. Одна из политик QoS — буферизация трафика. Как оно работает — когда видим, что линк у нас на 100Mb/s, а в него пытается проползти 1Gb/s, мы засовываем в линк столько, сколько влезет, а остальное складываем в буфер с мыслью: «а вдруг этот 1Gb/s станет жалким 1Mb/s, а мы потом успеем все в линк покидать». Буферизация приводит к тому, что один пакет задержался в буфере, а второй под шумок пролез параллельным путем.
Или был такой механизм как WFQ — когда маленькие пакеты получали приоритет перед большими при отправке через низкоскоростные интерфейсы. На более высокоскоростных интерфейсах это стало неважно.
Все что я попытался объяснить тут справедливо для Интернета и мало справедливо для обычной локальной сети (хотя для локальной сети большого предприятия это тоже может быть справедливо).
P.S.: Кстати еще по сетям очень рекомендую цикл статей на хабре — Сети для самых маленьких. Начало я не читал, честно говоря, но вот часть про MPLS написана просто очень отлично habrahabr.ru/post/246425
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
ZeroRPC — легкая, надежная библиотека для распределенной связи между серверами