|
|
|
ZeroMQ - сокеты на стероидах, часть 3 (а для чего?).
|
|||
|---|---|---|---|
|
#18+
чччД, Ага, у меня и такой подход есть, но для дерева (тоже VTV использую). Нет, записей меньше ))) до 20 тысяч, это если справочник номенклатуры, а обычно меньше. Но тут есть две проблемы. Одна проблема - в натуральных индексах, тудыть их растудыть. Натуральный СОРТИРОВОЧНЫЙ индекс, представьте себе (например, наименование в верхнем регистре). Так повелось (nosql под названием MSM/GT.M, он сам толкает к такому дизайну). Я единственно как смог улучшить базу - это свести все места изменения ключевых данных в одно и там считать количество сущностей в каждой таблице при апдейтах, это ведёт ко второй Проблеме - при передаче всех индексов одним сжатым паком мне придётся читать всю таблицу, затягивая её в кэш (который, к слову, маленький, ибо сервера у меня - такие же рабочие станции, по железу). А так - отправил первые 25-40 строк и норм. Было время когда я почти склонился к этому решению - тянуть индексы, оно на поверхности, но отказался по соображениям выше (в основном из-за необходимости полного перебора таблицы). Есть еще и третья контра, у нас полно юзеров котоыре коннектятся через интернет (в регионах). Там метр выкачать - уже проблема, поэтому каждое открытие номенклатурного справочника, либо самой номенклатуры - это будет боль (можно тогда уж кэшировать справочник номенклатуры на клиентах, это даже реализовано но не используется пока - не понятно какая будет нагрузка в целом) Чем глубже - тем страшнее, да? Так и живём :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.06.2017, 16:25 |
|
||
|
ZeroMQ - сокеты на стероидах, часть 3 (а для чего?).
|
|||
|---|---|---|---|
|
#18+
чччДZeroMQ Особенности High-level API CZMQ : Автоматизация обслуживания сокетов. К примеру, при закрытии контекста все его сокеты обработка будут также закрываться. При этом в некоторых случаях для сокетов можно назначить таймайт. ... Интересно: Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. zthread_fork создает и запускает "прикрепленную нить", фактически запуская cdecl - функцию типа zthread_attached_fn и автоматически создавая пару сокетов для общения с нитью, как и сказано в описании выше. Так вот, контекст ZMQ (параметр ctx: p_zctx_t) не просто передается, а создается его копия в блоке данных нити. В рамках нового контекста в нити и будет создаваться новый пул сокетов и связанных с ними коннектов, очередей и т.п. Т.е., по завершении нити произойдет корректная финализация копии контекста и связанных с ним сокетов и проч. Вот ведь чушь написал-то. Контекст zmq (указатель) - естественно, копируется. Просто в czmq контекст представляет собой структуру, включающую в себя zmq контекст (в данном случае - скопированный Pointer из оригинального контекста), пул сокетов, пул вторичных контекстов и т.п. При разрушении czmq контекста сперва разрушаются все вложенные элементы, а потом, если контекст не-вторичный - разрушается и сам zmq контекст. Получается, что в czmq контексте общий zmq контекст для первичного контекста и для всех всех таких вот "прикрепленных", а вложенные объекты в каждом czmq контексте - свои. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2017, 04:35 |
|
||
|
ZeroMQ - сокеты на стероидах, часть 3 (а для чего?).
|
|||
|---|---|---|---|
|
#18+
Вот и мне понадобились ZeroMQ. Есть некий OPC-сервер, подписанный (Advise) на получение изменений тэгов. При изменении данных сервер вызывает Callback-процедуру, в которую передает массив изменившихся тэгов. Эти данные мне надо разослать на ~100 (пока) компов. Казалось все просто: используем топологию "Издатель-подписчик" (PUB-SUB), и дело в шляпе. НО. НО она (Callback-процедура) выполняется в отдельной нити. Передавать ей заранее созданный сокет низзяааа, патамушта здесь написано: "Запоминаем: не используем (и не закрываем) сокеты нигде, кроме как нитях, их создавших." , а каждый раз в начале процедуры создавать, а в конце убивать сокет как-то не айс (имхо). Вопрос к уважаемому сообществу, в первую очередь к чччД: Можно ли как-нибудь по другому решить, и если да - то как? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2017, 09:18 |
|
||
|
ZeroMQ - сокеты на стероидах, часть 3 (а для чего?).
|
|||
|---|---|---|---|
|
#18+
Вроде вырисовывается такая схема: 1. Поток - Издатель. 2 сокета: - PULL. получает по inproc сообщения от Callback-a и передает их сокету - PUB. Рассылает сообщения по TCP клиентам. 2. Callback. 1 сокет: - PUSH. Создается в начале процедуры, посылает сообщения по inproc Издателю. В конце процедуры убивается. А? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2017, 10:01 |
|
||
|
ZeroMQ - сокеты на стероидах, часть 3 (а для чего?).
|
|||
|---|---|---|---|
|
#18+
Вик Торович, оба твоих сообщения я не понял, совсем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2017, 11:13 |
|
||
|
ZeroMQ - сокеты на стероидах, часть 3 (а для чего?).
|
|||
|---|---|---|---|
|
#18+
чччД, как-то так: Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2017, 04:35 |
|
||
|
ZeroMQ - сокеты на стероидах, часть 3 (а для чего?).
|
|||
|---|---|---|---|
|
#18+
Вик Торович, Странное заявлениеПоскольку функция выполняется в контексте потока, созданного OPC-сервером, сокет надо создавать здесь, каждый раз при входе в процедуру и убивать на выходе. Неужели поток каждый раз создается в момент вызова коллбэка? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2017, 11:50 |
|
||
|
ZeroMQ - сокеты на стероидах, часть 3 (а для чего?).
|
|||
|---|---|---|---|
|
#18+
Если нити для каждого вызова коллбэка разные, я бы не стал связываться с ZMQ, ибо повторный bind() к тому же tcp порту ничего не даст, кроме ожидания момента, когда порт освободится. Мало того, что bind выполняется не мгновенно, потом к нему должны выполниться connect()'s клиентов со стороны SUB, потом еще придется при зверешении коллбека ждать завершения рассылки (задавать ненулевое значение linger для сокета). Если нить одна и тот же - сокет можно создать и настроить однократно, (например при первом коллбэке). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2017, 14:17 |
|
||
|
ZeroMQ - сокеты на стероидах, часть 3 (а для чего?).
|
|||
|---|---|---|---|
|
#18+
чччДВик Торович, Неужели поток каждый раз создается в момент вызова коллбэка? Конечно же нет :) Поток создается OPC при подписке на данные (Advise). Но о нем ничего неизвестно до первого изменения данных, читай - вызова коллбэка. чччДЕсли нить одна и тот же - сокет можно создать и настроить однократно, (например при первом коллбэке). Ага. Именно так и сделал. Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Осталось понять, где делать закрытие сокета. Закрыть-то его из другого потока тоже нельзя. Или если очень хочется - то можно? (с). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2017, 04:09 |
|
||
|
ZeroMQ - сокеты на стероидах, часть 3 (а для чего?).
|
|||
|---|---|---|---|
|
#18+
чччД, при разрушении контекста сокеты закрываются? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2017, 05:17 |
|
||
|
ZeroMQ - сокеты на стероидах, часть 3 (а для чего?).
|
|||
|---|---|---|---|
|
#18+
Вик Торович, можно попробовать схитрить, вызвав деструктор самому: поменять хитрый тег, сервер вызовет коллбэк, а там этот тэг, вот и все, все разрушаешь и на всякий выставляешь флаг: "больше работать не хочу"... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2017, 05:18 |
|
||
|
ZeroMQ - сокеты на стероидах, часть 3 (а для чего?).
|
|||
|---|---|---|---|
|
#18+
Вик ТоровиччччД, при разрушении контекста сокеты закрываются? Да, закрываются, но операция разрушения контекста переходит в режим ожидания завершения ввода-вывода сокетами. Время ожидания задается в параметре linger для сокета, по умолчанию = -1 ("ждать вечно"). Вот тут 20599592 , кроме всего прочего, есть простейшая объектная оболочка, где все сокеты я создаю с linger = 0 ("не ждать, завершаться сразу"). Кстати, Linger в 0 рекомендует устанавливать и автор (исходный создатель) библиотеки zmq. Кстати, сам контекст - он вполне себе thread - safe, его можно передавать в треды, поэтому просто разрушь "главный" контекст, а в коллбэке анализируй коды завершения работы с сокетами (если = -1 - это разрушение, делаем Exit например) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2017, 05:24 |
|
||
|
ZeroMQ - сокеты на стероидах, часть 3 (а для чего?).
|
|||
|---|---|---|---|
|
#18+
Да, нашел в описании функции zmq_ctx_term. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2017, 05:34 |
|
||
|
ZeroMQ - сокеты на стероидах, часть 3 (а для чего?).
|
|||
|---|---|---|---|
|
#18+
чччД, Ага, я уже скачал это. Спасибо за инфо о Linger. пишу потихоньку. Вроде получается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2017, 05:39 |
|
||
|
ZeroMQ - сокеты на стероидах, часть 3 (а для чего?).
|
|||
|---|---|---|---|
|
#18+
чччДВик Торович, можно попробовать схитрить, вызвав деструктор самому: поменять хитрый тег, сервер вызовет коллбэк, а там этот тэг, вот и все, все разрушаешь и на всякий выставляешь флаг: "больше работать не хочу"... Хм. мысли сходятся не только у дураков. Как раз сижу и излагаю коллеге этот сценарий :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2017, 05:42 |
|
||
|
ZeroMQ - сокеты на стероидах, часть 3 (а для чего?).
|
|||
|---|---|---|---|
|
#18+
Вик Торович, к сожалению, об особенностях схемы pub-sub я знаю не больше, чем написано ранее про модель "метеостанция": попробовал, повертел и отложил. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2017, 08:52 |
|
||
|
ZeroMQ - сокеты на стероидах, часть 3 (а для чего?).
|
|||
|---|---|---|---|
|
#18+
Про XPUB и XSUB полный бред написал: 16623545 16623546 Даже не могу вспомнить, с чего это я вдруг решил, что пара XPUB-XSUB каким-то чудесным образом реализует прямую связь между издателем и подписчиком. ... ~~~~~~~~~~~~~~~~~~~~~~~~ В действительность, пара XPUB-XSUB всего лишь является концентратором сообщений для схемы PUB-SUB , когда издателей несколько, и их адреса могут достаточно часто меняться. Предположим, есть не один издатель, а несколько. Используем схему PUB-SUB . Никаких проблем: каждый подписчик коннектится не одному, а к нескольким издателям. Одним и тем же сокетом. Но, когда издатели появляются и исчезают заранее неизвестно когда, данная схема становится неудобной: каждый подписчик должен знать адрес всех издателей. Вот для этого случая и нужна схема XPUB-XSUB (см. картинку ниже). Есть один подписчик "proxy" с сокетами PUB , который знает адреса всех издателей, и коннектится к ним сокетом XSUB . Он получает все входящие сообщения. Он их публикует, используя сокет XPUB . Все остальные подписчики подписываются лишь к одному издателю - "прокси", используя сокеты SUB . Таким образом, при изменении списка издателей, нужно всего лишь изменить "прокси". Подписчики менять не нужно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2017, 09:25 |
|
||
|
ZeroMQ - сокеты на стероидах, часть 3 (а для чего?).
|
|||
|---|---|---|---|
|
#18+
Возникает вопрос - почему бы не использовать в '"proxy" обычную пару PUB-SUB ? Можно. Но XPUB-XSUB умеет делать интересный фокус с подписками. Издатель подписывается на определенные сообщения, XPUB транслирует эти подписки в специальные сообщения и передает их в XSUB . То есть, "proxy" пересылает эти спец.сообщения со стороны абонентов на сторону издателя. Вот для этого и нужны XSUB и XPUB . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2017, 09:36 |
|
||
|
ZeroMQ - сокеты на стероидах, часть 3 (а для чего?).
|
|||
|---|---|---|---|
|
#18+
Вик Торович, есть отдельная глава, посвященная особенностям схемы "издатель-подписчик": http://zguide.zeromq.org/page:all#Chapter-Advanced-Pub-Sub-Patterns Прочитал с удовольствием, правда, пока не придумал - куда применить... :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2017, 09:44 |
|
||
|
ZeroMQ - сокеты на стероидах, часть 3 (а для чего?).
|
|||
|---|---|---|---|
|
#18+
Здравия всем. Почитал. Интересно. Мне наиболее подошел бы Radio-dish pattern. Но печалька - Radio-dish is still in draft phase. . Кто-нибудь в курсе - проект умер или будет таки развитие? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2018, 08:53 |
|
||
|
ZeroMQ - сокеты на стероидах, часть 3 (а для чего?).
|
|||
|---|---|---|---|
|
#18+
_Читатель_Кто-нибудь в курсе - проект умер или будет таки развитие? Какой конкретно "проект"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2018, 09:43 |
|
||
|
ZeroMQ - сокеты на стероидах, часть 3 (а для чего?).
|
|||
|---|---|---|---|
|
#18+
чччД, ZeroMQ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2018, 11:00 |
|
||
|
ZeroMQ - сокеты на стероидах, часть 3 (а для чего?).
|
|||
|---|---|---|---|
|
#18+
_Читатель_, А ты, про это. Не знаю, там на английском все, я не понимаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2018, 11:25 |
|
||
|
ZeroMQ - сокеты на стероидах, часть 3 (а для чего?).
|
|||
|---|---|---|---|
|
#18+
Почитал тут про ZMQ и возник один вопрос по безопасности: вот в обычном TCP, как было сказано в начале статьи, в случае если нам передали неверный заголовок сообщения мы можем либо сбросить подключение вообще, либо прочитать испорченные данные в /dev/null и приступить к обработке следующего сообщения. А вот вопрос: какова будет реакция ZMQ, если злоумышленник, зная его протокол, попытается передать валидный пакет, объемом 100500 гигабайт (объёмом, гарантированно большим чем оперативная память + своп на сервере)? Можно ли как-нибудь лимитировать допустимый размер сообщений? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2018, 16:43 |
|
||
|
|

start [/forum/topic.php?fid=58&msg=39483172&tid=2039957]: |
0ms |
get settings: |
11ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
190ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
64ms |
get tp. blocked users: |
1ms |
| others: | 245ms |
| total: | 550ms |

| 0 / 0 |
