Распределённая обработка данных на множестве серверов.

Apache Thrift RPC Server и не парься. Эффективный бинарный протокол, множество ЯП, готовый сервер и клиент, синхронная и асинхронная работа клиента, блокирующий или неблокирующий сервер, сериализация сообщений, кеширование соединений, поддержка версий протоколов и совместимости между разными, оптимизация по скорости или по размеру.

Apache Thrift RPC Server и не парься.

Не очень понятно как это на gambas использовать.

http://www.youtube.com/watch?v=LLk9_EH6Pfo

Хоть бы тег проставил ) Не все ходят по ссылкам

Apache Thrift RPC Server

Почему Thrift, а не protobuf? Или, ТНБ спаси, Cap'n'Proto?

Нет проблем, Thrift vs Protobuf - оба нормальные. Да хоть Avro. Я даже за protobuf в большей мере по определенным причинам :D

Но тогда прийдется писать сервер. В Thrift он готов сразу для множества ЯП и официальный. Для protobuf тоже есть вроде сторонние, например для netty, но тут уже поискать нужно для желаемого ЯП или платформы

Cap'n'Proto

Какие у него плюсы, кроме «мы пользуем C++11, поэтому невъебенно круто»?

Как-то пытался его юзать, он тёк, потом падал, потом падал им тёк. одно хорошо - разрабы реагируют быстро.

Какие у него плюсы, кроме «мы пользуем C++11, поэтому невъебенно круто»?

Ну это как бы protobuf done right от автора protobuf.

Как-то пытался его юзать, он тёк, потом падал, потом падал им тёк. одно хорошо - разрабы реагируют быстро.

Он еще в разработке фактически.

Вот это с наскоку не понял, нужно перечитать

http://kentonv.github.io/capnproto/rpc.html

Но есть доставляющие вещи

Cap’n Proto is INFINITY TIMES faster than Protocol Buffers.

/dev/null?

Но есть доставляющие вещи
INFINITY TIMES

там же объяснено, почему так :)

а не смутило, что это RPC для путешественников во времени?

обычные маркетоидные выкидоны :D там смысл в том, что в RPC можно отдавать «будущий результат» другого вызова. Но это можно хоть и на XML-RPC замутить..

а скорость сериализации яб и не сказал что сильно выше. скорее такая же получалась, сколько не гонял.

а скорость сериализации яб и не сказал что сильно выше.

по сравнению с протобуфом, есессно.

а не смутило, что это RPC для путешественников во времени?

Именно это смутило в первую очередь. Но я уже прочитал как оно работает и в чем суть, реально маркетинг. Но фича неплохая

Да вот я бы факты хотел почитать, а так это парень петросянит, а мне выковыривать из текста то, как оно реально работает

Но фича неплохая

Это да .. но именно с ней у меня куча проблем когда-то была. багов 5 им по этому поводу накатал :))

Ну что же поделаешь, куда без них. Фича фичей, но имплеметация должна становиться стабильной

Почему Thrift, а не protobuf?

Ну ты и сказал. Это всё равно что сравнить колесо с целой машиной.

Не очень понятно как это на gambas использовать.

через либу? я не в курсе про этот gambas, но там нет разве возмодностей пользовать *.so, *.dll?

через либу? я не в курсе про этот gambas, но там нет разве возмодностей пользовать *.so

Документации на русском про это нет толком. Хотя примеры вроде нашёл. Всё же фреймворк это не то что я хочу. Да и для моей задачи нет нужды в таком средстве.

Почему Thrift, а не protobuf?

Ну ты и сказал. Это всё равно что сравнить колесо с целой машиной.

Из очередности я так понял, что Thrift - это колесо? %)

Если серьезно, ТС не озвучил нужду в RPC-, а что там еще есть в Thrifty по сравнению с protobuf?

а что там еще есть в Thrifty по сравнению с protobuf?

реализация транспорта.

Если серьезно, ТС не озвучил нужду в RPC-

Он также не озвучил, что ему нужна только сериализация.

Ну он обсудал как ему обрабатывать десериализированые сообщения из сокета, очень похоже на RPC

Честно говоря сравнения можно отковырять, но в целом разницу между Thrift и Protobuf нужно смотреть под микроскопом, потому твои сравнения Thrift с колесом не понятны, не говоря уже о том, что там таки есть RPC, что не слабо. Религия? Это у меня она должна быть

Ну как бы сериализация - единственное, что явно нужно. Поэтому и protobuf. А дальше... может, он сделает REST с application/x-protobuf.

REST с application/x-protobuf.

С чего ты взял что сообщения большие? Иначе бред. Если уже вебня пошла, то WebSocket+Protobuf

REST с application/x-protobuf.

С чего ты взял что сообщения большие?

Я этого не брал.

Иначе бред

С чего ты взял, что это бред?

Если уже вебня пошла

А это ты с чего взял?

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

А это ты с чего взял?

Иначе неясно зачем такой франкенштейн. Если бинарь уже, то мы экономим для кучи траффика, иначе зачем? Если REST, то нужно проходить внешние прокси, иначе зачем, если есть уже готовые бинарные быстрые сервера? Более менее живучий сценарий тут - вебсокет+protobuf, там хотябы не будет overhead

Мотивируй короче свой дизайн.

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

Ммм... напомни.

Если REST, то нужно проходить внешние прокси

Что за странные стереотипы?

иначе зачем, если есть уже готовые бинарные быстрые сервера?

Поставим вопрос по-другому: зачем нужны «быстрые бинарные сервера», если есть старый добрый HTTP, поддерживаемый всем, что может послать хоть байт по сети?

Мотивируй короче свой дизайн.

Кхм. Ты называешь «дизайном» очевидную идею использовать protobuf поверх HTTP и REST как основу прикладного протокола? Окей, мотивация - простота, наличие кучи программных средств и литературы.

Ммм... напомни.

Может кто-то другой был, не уверен что ты

Поставим вопрос по-другому: зачем нужны «быстрые бинарные сервера», если есть старый добрый HTTP, поддерживаемый всем, что может послать хоть байт по сети?

Потому что это твоя внутрення инфраструктура и поднять на ней голый thrift-rpc/netty-protobuf не сильно сложнее чем HTTP. Когда нужно. В целом если не нужно (90%), тогда и сам protobuf не нужен, можно гонять HTTP+JSON.

что может послать хоть байт по сети?

Ведь не понятно, зачем заворачивать 1 байт в 40 байт оверхеда

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

это твоя внутрення инфраструктура и поднять на ней голый thrift-rpc/netty-protobuf не сильно сложнее чем HTTP

Не сильно сложнее _кому_ - тебе? ТС совершенно очевидный нуб.

можно гонять HTTP+JSON

Можно. Только после этого нельзя говорить об оверхеде %)

зачем заворачивать 1 байт в 40 байт оверхеда

Оверхеда чего по сравнению с чем? Каков оверхед, когда нужно послать не 1 байт, а 100? 1000?

Все же не понятно, почему не использовать просто Thrift RPC во внутренних риалтайм системах вроде игр

Можно, наверное.

и какие уникальные плюсы даст protobuf поверх других транспортов.

Плюсы этих транспортов, очевидно же. Вдруг кому-то нужен zeromq.

Можно. Только после этого нельзя говорить об оверхеде %)

Именно. Тут два варианта

1) оптимизиция по скорости и трафику. Никакого HTTP

2) пофиг. Никакого protobuf, ибо зачем.

3) Сообщения большие.

Каков оверхед, когда нужно послать не 1 байт, а 100? 1000?

Ну да, если сообщения доходят до килобайтов, тогда можно делать HTTP+Protobuf. Это уже называется «большие», так как большинство сообщений в приложениях - несколько сотен байт. Если мы не сошлись в терминологии «большие» или «небольшие», тогда извиняйте

С чего ты взял что сообщения большие?

1) оптимизиция по скорости и трафику. Никакого HTTP

Это почему? Оверхед HTTP фиксирован и невелик. Понятно, что по байту передавать не следует, но в хедпосте речь о «локациях» - как-то сомнительно, что они маленькие.

Я не против Thrift и RPC, просто не вижу выигрыша для «гусара-одиночки с мотором».