2

Ситуация. Происходит обработка исходных данных множеством потоков-обработчиков, выстроенных в в несколько параллельных цепочек/конвейеров. В некоторых местах обмен до 50 метров/сек. Данные - где-то поток байт, где-то пакеты (структуры в памяти тупо) фиксированной/переменной длины.

Какую схему взаимодействия(IPC) выбрать, учитывая:

  • С++ + Qt + boost
  • возможность задержки на каком-то этапе, т.е. должна присутствовать буферизация
  • при возникновении задержки не должна нарушаться целостность передаваемых данных
  • обязательно схема 1 производитель - N потребителей
  • возможна работа по локальной сети

Чем не нравятся:

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

Правильно ли я смотрю на все это? Какую схему подобрать?

Судя по всему передача данных потоком через boost::lockfree::queue невозможна, единственный вариант - разбивать на части. Т.е. принял 50 метров, разбил по 1 метру, отправил в очередь. Хотя по сути с new выделится еще столько же...Будет ли поток успевать прокачивать 50М таким образом каждую секунду?

Обновление

Короче, буст локфри, элемент - структура [размер, указатель]

Указатель при этом можно делать шаред_арра

Господа, вы меня ловко обвели вокруг пальца.

Нужен механизм !!!межпроцессного!!! взаимодействия! N производителей, N параллельных потребителей. Потребляют одну и ту же инфу одновревенно. "Бесконечная" буферизация!

Что не так с буст::локфри::кью - как я в другом процессе открою ее?

Кьюб
  • 3
Кьюб
  • 21
  • Если нужна большая скорость, то межпроцессное взаимодействие, вероятно, не лучший выбор. А способ организации внутри процесса сильно зависит от языка. – VladD Jun 28 '15 at 22:25
  • подправил) а вообще С++ – Кьюб Jun 28 '15 at 22:28
  • Внёс вашу платформу в метки. – VladD Jun 28 '15 at 22:30
  • А чем вам не подходит стандартный producer/consumer через очередь? (Наверняка в boost'е есть что-то специально для вашего сценария.) – VladD Jun 28 '15 at 22:33
  • Вот, например: http://www.boost.org/doc/libs/1_58_0/doc/html/boost/lockfree/queue.html – VladD Jun 28 '15 at 22:34
  • Да, готовое решение "бесконечной буферизации" с множественным доступом. Вопрос. Как работать с такой очередью, если мне нужно записать массив байт заранее неизвестной длины? – Кьюб Jun 28 '15 at 23:33
  • Если нужна работа в т.ч. и по локальной сети, то однозначно сокеты (хотя это и может прятаться какой-нибудь MPI) – avp Jun 28 '15 at 23:35
  • дописал в основной вопрос – Кьюб Jun 29 '15 at 00:22
  • Да не получите Вы ответа на свой вопрос - тут только пробовать и тестировать. Никто Вам не скажет, что будет быстрее - это можно только измерить для конкретного случая. Единственно, что я бы сказал - в общем случае boost написан лучше Qt, и от него можно ожидать большей производительности. – ixSci Jun 29 '15 at 05:00
  • @Кьюб: записывать в очередь указатель на структуру? – VladD Jun 29 '15 at 07:59
  • @Кьюб: не вижу причин, по которым нельзя shared_array. – VladD Jun 30 '15 at 10:20
  • @Кьюб: Ну, снова-таки, вопрос как в начале: Если вам реально нужна большая скорость, почему многопроцессное решение? Почему не в одном процессе? – VladD Jul 01 '15 at 14:43
  • У Вас в заголовке " потоками /процессами/программными модулями". Как вопрос зададите, так ответ и получите. Средств IPC вагон и маленькая тележка. Какой выбрать? Решайте сами, этот вопрос слишком общий. Поэтому я голосую за его закрытие – ixSci Jul 01 '15 at 15:10
  • Уточните схему с N производителями и одновременно потребляющими эту инфу N потребителями. Вы передаете некие "пакеты" или неструктурированный поток? Если пакеты, то прочитанный потребителем пакет остается доступен другим? В общем, распишите сценарии обмена и поподробней, а то одни догадки... – avp Jul 01 '15 at 17:30

2 Answers2

1

После обновления вопроса, думаю, вам все-таки стоит глянуть в сторону ZeroMQ. Может и внутрипроцессное взаимодействие, и межпроцессное, и по сети, все довольно эффективно. N-to-N легко. Буферизация есть, но не бесконечная, если, конечно, сами оную не реализуете. Порог вхождения не сказать, что низкий, сходу, посмотрев на пару-тройку примеров, не получится скорее всего написать все правильно, придется вдумчиво почитать руководство.

ØMQ (also known as ZeroMQ, 0MQ, or zmq) looks like an embeddable networking library, but acts like a concurrency framework. It gives you sockets that carry atomic messages across various transports, like in-process, inter-process, TCP, and multicast. You can connect sockets N-to-N with patterns like fan-out, pub-sub, task distribution, and request-reply. It's fast enough to be the fabric for clustered products. Its asynchronous I/O model gives you scalable multicore applications, built as asynchronous message-processing tasks. It has a score of language APIs and runs on most operating systems.

Vadim Shender
  • 2,533
0

Во-первых, есть MPI. Большую часть математики на кластерах реализуют с его помощью - это стандарт де-факто для вычислительных кластеров. 50 мег в секунду - это смешно, там десятки гигабит по инфинибэнду прокачивают.

Во-вторых, нужно отделить сетевой транспорт от локального.

  • Локально нужно использовать lockfree в пределах процесса.
  • В сети, в случае задачи "Один ко многим", самые лучшие результаты достигались (у меня) при помощи самодельного велосипеда на базе UDP-Multicast - одновременная заливка с центрального хоста пары гигабайт на весь кластер - это красиво! Понятно, что коммутаторы должны быть в состоянии все это протащить.
gbg
  • 22,253