Извини, коллега, но это словесный понос ...
Что значит "потоки данных"? - Тебе риал-тайм синхронизация нужна (Комет)? Или судя по следующим предложениям, банальное получение данных с сервера и отправка запросов? Определись, плиз, и не кидайся словами, особенно терминами.
Далее очень смахивает на то, что ты не очень представляешь что есть MQ и в частности, его взаимодействие с клиентом (кстати, действительно есть версия ActiveMQ под С?- не знал).
Ну и напоследок, а есть технологии в вебе, альтернативные протоколу сетевого уровня TCP/IP? А ну-ка, ну-ка ...

kT_________По поводу протокола... альтернативного протоколу сетевого уровня, ты вменяем???
Речь о том что можно передавать напрямую в сокет, можно на уровнях повыше(АктивМКу).
TCP/IP (когда пишут вместе) - согласно принятой модели (типа модели OSI) это протокол третьего - сетевого уровня (поверх канального и физического). Фактически популярных протоколов там больше нет, на слуху только ICMP, ARP и устаревший IPX. В любом случае любое соединение, которое ты попытаешься сделать со странички, будет базироваться именно на TCP/IP и альтернативы нет.
А вот TCP/IP (или просто IP) уже имеет протоколы четверного - транспортного уровня - TCP, UDP (остальные даже на слух ни о чем не говорят) и фактически тут тоже нет альтернативы для веба. И опять-таки, использование UDP - это передача с потерями, хотя и быстрее, поэтому используют для потокового видео или аудио, но для передачи данных он не подходит. Так что тут тоже без альтернатив.
И на последнем - седьмом, прикладном уровне - уже появляется разнообразие: HTTP, SSH, FTP, SMTP, Telnet, SNMP. Но даже при этом разнообразии выбор веб-программиста крайне скуден - на 95% HTTP, 5% SSH (HTTPS) и редчайшие индивидуумы пытаются прикрутить что-то большее, не универсальное и сложное, типа SNMP.

Так что, дорогой, чем бы ты не пользовался, тебе прийдется либо базироваться на HTTP/SSH (все комет-технологии), либо использовать Sockets - протокол пятого, сессионного (обычно тоже включают в общий прикладной уровень) уровня, банально тоже входящий в TCP. Поэтому вопрос о вменяемости по данному вопросу, я думаю, излишен.

kT_________Товарищи в Фриско пользуют это , представляешь, можно вызвать от туда АктивМКу ..прикинь?!
Я активно использовал ActiveMQ - как напрямую через сокеты коммутацией через Спринг, так и банальными ajax-запросами через Apache Camel для сериализации и маршрутизации запросов. Остался доволен работой, хотя очень глубоко (с подключением спецбазы и протоколированием) влазить не стал.

Другое дело - не совсем понятно, как использование (или неиспользование) того же ActiveMQ влияет на выбор сетевого, транспортного или прикладного протоколов? Ему-то все равно, он получит на входе сообщение, доставит по адресу и заставит обождать в очереди, пока другие будут обрабатываться.

kT_________И оффтоп)) ..АктивМКу который поверху тспайпи, он ощутимо на производительность влияет, чем если просто в сокеты голые писать-читать???
Ёпсель-мопсель! Да возьми ты хоть Википедию почитай ... протоколы - это одна плоскость, диспетчер очередей (MQ) - другая, они так же увязываются как "быстрый" и "красный" ... Протокол - это фактически транспорт, с помощью которого ты доставляешь данные с клиента на сервер, основные потери (при устойчивой физической связи) - это время на коммутацию с веб-сервером (выделение порта если надо, создание потока в многопоточной среде, парсирование заголовков запроса, и лишь потом чтение из потока), сокеты фактически устанавливают это при его создании и тратят время только на чтение из потока, поэтому быстрее. Однако некоторые технологии, базирующиеся прямо поверх HTTP, не сильно уступают сокетам по времени потерь, однако являются более универсальными при разнообразии браузеров, и гораздо проще в реализации (смотри комет-технологии).

И вот то, что ты получишь на входе веб-сервера, ты сериализуешь (если надо) и направляешь "на вход" MQ, чтобы обработать. Основным достоинством брокера является не скорость (просто обработать запрос веб-сервером будет быстрее), а гарантия (!) того, что запрос достигнет цели за счет создания и хранения сообщения в очереди - не зря же называется он Message Queue, плюс ветвление по критериям, плюс наличие кластеризации для крупных систем, плюс способность защищать данные путем помещения их во внутреннюю (Kaha, кажется) или внешнюю базу, а также возвращение ответа обратно "на выход" для последующей отправки его клиенту (в рамках нашего веб-проекта).

Я почему спросил, работает ли ActiveMQ с С, - он реализует стандарт JMS (Java Message Service), вроде как все завязано на Java-технологиях. Отсюда недоверие к тому, как он сможет работать с другими ЯП (в частности с node.js). На Java же работа с тем же ActiveMQ, особенно с фреймворком Spring, - это почти удовольствие - десяток строк конфига XML и он работает. Как быть с остальными - не знаю.

Надеюсь, ты понял негодование и возмущение твоими терминологическими "экзерсисами" - ты берешь последовательные и независимые друг от друга понятия и пытаешься их плотно переплести. Судя по вопросам и "подкованности", с наскока овладеть этими высокими технологиями у тебя не получится. Начни с малого: варенье отдельно, мухи отдельно - интерактивность реализуй с помощью банального Long Polling, а данные базы получай параллельными асинхронными запросами. Вроде как это разные вещи. А сокеты и MQ обождут ... Тем более, веб - такая штука, когда в любом случае есть задержки, абсолютного real-time не получится (даже в Скайпе иногда видны такие задержки, несмотря на специальные протоколы передачи видео), поэтому при пинге 20 мс (сделаем тебе подарок, хотя не поверю) получишь ты ответ не через 60 мс (20 туда, 20 назад, 20 на сервере), а через 80 мс (на обработку заголовков добавим 20 мс) - не велика потеря ... А реальные "бытовые" пинги большинства провайдеров находятся далеко за сотню.

P.S. Ух, не думал, что до сочинения сказок для объяснения проблемы дойду ...
P.P.S. от модератора. Или задавай КОНКРЕТНЫЕ вопросы по HTML, JavaScript, VBScript, CSS, или я буду прикрывать эту пустую болтовню (в которую сам вовлекся).

Не могу. С node.js и С++ не работаю.