LINUX.ORG.RU

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

 , , , ,


0

4

Пишу игру http://star-engineers.blogspot.ru/ https://github.com/killofwin/star-e

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

1) Использовать класс ServerSocket, который при попытке установки соединения на прослушиваемый порт возвращает класс Socket. После добавить этот класс в массив и обрабатывать все сокеты в цикле.

2) Установить последний элемент массива сокетов в состояние прослушивания и при установке соединения добавлять новый прослушивающий элемент в массив.

Естественно каждый способ по имеет свои недостатки связанные как с обработкой закрывшихся соединений, так и с приёмом новых соединений.

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

vertexua ★★★☆☆ ()
Последнее исправление: vertexua (всего исправлений: 2)
Ответ на: комментарий от vertexua

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

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

rezedent12 ☆☆☆ ()
Ответ на: комментарий от vertexua

Apache Thrift RPC Server

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

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

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

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

vertexua ★★★☆☆ ()
Последнее исправление: vertexua (всего исправлений: 2)
Ответ на: комментарий от tailgunner

Cap'n'Proto

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

villu ()
Ответ на: комментарий от tailgunner

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

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

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

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

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

vertexua ★★★☆☆ ()
Последнее исправление: vertexua (всего исправлений: 3)
Ответ на: комментарий от vertexua

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

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

REST с application/x-protobuf.

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

vertexua ★★★☆☆ ()
Последнее исправление: vertexua (всего исправлений: 2)
Ответ на: комментарий от vertexua

REST с application/x-protobuf.

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

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

Иначе бред

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

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

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

tailgunner ★★★★★ ()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от tailgunner

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

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

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

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

vertexua ★★★☆☆ ()
Последнее исправление: vertexua (всего исправлений: 1)
Ответ на: комментарий от vertexua

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

vertexua ★★★☆☆ ()
Последнее исправление: vertexua (всего исправлений: 1)
Ответ на: комментарий от vertexua

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

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

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

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

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

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

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

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

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

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

tailgunner ★★★★★ ()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от tailgunner

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

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

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

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

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

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

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

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

vertexua ★★★☆☆ ()
Последнее исправление: vertexua (всего исправлений: 1)
Ответ на: комментарий от vertexua

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

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

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

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