Здравствуйте, pestis, Вы писали:
P>Доброго дня, коллеги.
P>Для одной интересной штуки нужно уметь передавать поток информации между расчетным модулем и слоем отображения. Но: P>
P> поток информации достаточно плотный чтобы отбить желание использовать протоколы с большим оверхедом, типа TCP. Для простоты можно считать что передается видео среднего разрешения без возможности сжатия. P> сжимать поток категорически не хочется, это сильно удорожит разработку. P> нужна тру кроссплатформенность между разными языками. Всякие решения с общей памятью не пойдут. Расчетный модуль на чистой сишечке, а слой отображения на чем угодно от JavaScript до Qt. P> нужна тру кроссплатформенность между разными OC. Все должно работать как на линуксе так и под виндой. Поэтому юникс файл сокеты или проприетарные M$ технологии не пойдут. P> все работает на одной машине, сеть не нужна P>
P>Подскажите, какие еще есть варианты?
ZeroC ICE — кроссплатформенный rpc, для вызовов в пределах одной машины сеть не используется, но нет биндов под js и сильно негуманная коммерческая лицензия.
N>А мне кажется, что тут есть всего 1 момент, который надо учитывать: N>1. если при таком интенсивном взаимодействии приходится копировать память с участием CPU (хотя бы 1 раз), то будет тормозить; N>2. если память можно копировать через DMA, то будет всё хорошо (например, запустить копирование данных в видеопамять и другим приложением подхватить текстуру); N>3. если память вообще не надо копировать, то всё будет превосходно.
N>То есть топикстартеру надо сразу отметать (что он и сделал) всякие сети и протоколы, основанные на копировании. N>В тоже самое время факт ограничения типа разработки на JavaScript чуть ли не закрывает возможность использования вариантов (2) и (3). N>По (2): умеет какой-нибудь WebGL подхватывать указатели на видеопамять? Если нет, то вариант полностью отметаем.
Спасибо за понимание. На самом деле проблема не только в копировании. Грубо приближенно мою задачу можно сравнить с моделированием на регулярной стеке. Сетка большая и ограничена только объемом памяти и производительностью CPU. Железо десктопное, без выкрутасов. Производительность чем больше тем лучше. Будет слишком быстро, можно увеличить размер сетки и получить более точные результаты. Аналогично и с памятью.
Это основная причина по которой меня не устраивают RPC-based протоколы. Мало того что нужно протаскивать изменения через протокол, так еще и придется хранить по копии сетки для каждого инструмента. Либо существенно усложнять логику расчетов вводя дополнительные понятия.
Меня бы спасла технология позволяющая клиентам засылать в расчетный модуль "послов" которые имея прямой доступ к данным предрасчитают все что им нужно и выплюнут результаты в любой RPC протокол, хоть HTTP. Желательно чтобы эти "послы" писались на чем-то более высокоуровневом чем plain C, работали в read-only песочнице и не могли влиять друг на друга. Поэтому тупое решение с динамической линковкой чужих модулей тут не пойдет.
Здравствуйте, pestis, Вы писали: P>Подскажите, какие еще есть варианты?
IPC через pipes? http://carminedimascio.com/2014/01/named-pipes-with-java/
Написать на С слой абстракции Win/*nix, если его еще нет готового (POSIX, насколько я понимаю, не подойдет), и все. Java/JavaScript/.Net прочитать смогут.
Здравствуйте, pestis, Вы писали:
P>Меня бы спасла технология позволяющая клиентам засылать в расчетный модуль "послов" которые имея прямой доступ к данным предрасчитают все что им нужно и выплюнут результаты в любой RPC протокол, хоть HTTP. Желательно чтобы эти "послы" писались на чем-то более высокоуровневом чем plain C, работали в read-only песочнице и не могли влиять друг на друга. Поэтому тупое решение с динамической линковкой чужих модулей тут не пойдет.
ну какой-нить встроенный интерпретатор, типа луа или того же питона
Здравствуйте, pestis, Вы писали:
P>Хочется не выдумывать протокол, а высунуть поток всех данных и пусть разработчики клиентов решают что им нужно, а что нет. Что udp что tcp с сырым потоком не справятся, придется городить подписки и прочие оптимизации.
Тогда берите протокол типа MQTT — клиенты подпишутся на то что захотят.
