LINUX.ORG.RU

RPC с возможностью асинхронных посылок клиентам


0

1

Замахнулся было на Apache Thrift и их вкусную как бы автоматическую реализацию RPC вызовов, но... столкнулся с проблемой - мне нужно чтобы сервер асинхронно (периодически или нет - присылал какие-то сообщения любому клиенту). Thrift это не поддерживает, т.е. чтобы взять и не по запросу клиента, и не прибегая к поллингу на стороне клиента - сообщить «там на сервере внезапно событие произошло».

Кто знает такие кросс-языковые реализации RPC чтобы можно было асинхронные сообщения слать туда сюда? Или для Thrift как такое зарядить?

Ответ на: комментарий от I-Love-Microsoft

да я сам когда-то искал, не особенно сильно правда, задача очень быстро потеряла актуальность и так и не была решена. пришёл к выводу, что если мультиязычно и кроссплатформенно - лучше кобры с запущеным notify демоном ничего нет. кроме самописных велосипедов конечно.

nanoolinux ★★★★
()
Ответ на: комментарий от nanoolinux

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

я сейчас использую только Qt и libqxt - там замечательно - сигналы в любой момент туда сюда могут летать по сети - красота, но есть минусы, трудоемко делать много соединений разных функций с разными именами, очень трудоемко

I-Love-Microsoft ★★★★★
() автор топика
Последнее исправление: I-Love-Microsoft (всего исправлений: 2)
Ответ на: комментарий от I-Love-Microsoft

я думаю не хотят усложнять в связи с возможной dos атакой например (на правах предположения если что).

как вариант для твоего проекта: если всё сильно завязано на асинхронности и выбор языка не важен - сделай на erlang, отпадёт куча проблем.

nanoolinux ★★★★
()

thirft умеет писать/читать буфер, а буфер можно отправлять/получать самому руками. только это геморрой и сводит на нет все преимущества thrift'а, по сути от него останется только кодогенератор и сериализатор :)

Reset ★★★★★
()

Немного пионерское, но всё такое из себя асинхронное решение — socket.io и совместимые с ним библиотеки.

PolarFox ★★★★★
()
Ответ на: комментарий от Reset

вот и я про то... разве что использовать Thrift как есть, но для асинхронных сообщений клиенту - что-то отдельное прилепить

I-Love-Microsoft ★★★★★
() автор топика
Ответ на: комментарий от I-Love-Microsoft

Ну дак для более ентерпрайзных языков вполне могут найтись совместимые (ну или по крайней мере близкие по духу) библиотеки.

PolarFox ★★★★★
()

мне нужно чтобы сервер асинхронно (периодически или нет - присылал какие-то сообщения любому клиенту)

ZeroC Ice вообще и IceStorm в частности.

Begemoth ★★★★★
()
Ответ на: комментарий от Begemoth

а если коммерческое или закрытое приложение? сколько стоит лицензия? вот из-за невнятной лицензионной политики - в одной конторе при мне отказались от ZeroC ICE и т.п.

I-Love-Microsoft ★★★★★
() автор топика
Ответ на: комментарий от Begemoth

в общем да, в самом деле у ZeroC Ice есть AMI (колбэки считай), это то что надо

но вот как быть с лицензией, мне не нравится ихнее «в зависимости от доходов вашей компании, вы свяжитесь с нами и мы подумаем сколько с вас стрясти» - вот это не айс (ice) ^_^

I-Love-Microsoft ★★★★★
() автор топика
Ответ на: комментарий от tailgunner

в частности для Thrift решение такое - клиент делает запрос а сервер не отвечает сразу и клиент как бы висит в ожидании, как происходит что-то на сервере - клиенту тут же прилетает ответ

вот скажите, не пахнет ли это костылями или это вполне себе метод?

I-Love-Microsoft ★★★★★
() автор топика

Может быть стоит реализовать RPC поверх message-оринтированных сервисов типа ZeroMQ или Spread toolkit ? Кстати - для Qt есть привязка zeromq - nzmqt

sigurd ★★★★★
()
Ответ на: комментарий от sigurd

спасибо! а ведь это мысль, сериализацию можно оставить тому же Thrift, а сам механизм RPC можно бы и для 0MQ оставить! надо же осваивать прогрессивные технологии ^_^

ЗЫ сейчас я использую http://qtnode.net/wiki/QxtRPCPeer - в принципе нормально но крайне неудобно для более менее серьезного проекта

I-Love-Microsoft ★★★★★
() автор топика

SPDY такое будет поддерживать.

bk_ ★★
()
Ответ на: комментарий от I-Love-Microsoft

Зависит от ситуации. Но это не извещения, конечно. Если уж хочешь извещения именно поверх RPC, делай обе взаимодействующие программы RPC-серверами. Но лучше - просто обмен сообщениями.

tailgunner ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.