Допустим, есть сервер на крестах, и его нужно выставить каким-то чистым апи в интернет.

Ну возьми кобру. Или sunrpc. Но это уже не модно.

сервер на крестах

Пиши на йаве лучше. Или на эрланге.

Дай ссылку на кобру? По запросу «C++ cobra» первые несколько страниц какой-то треш про танки и голодающих детей в африке

CLI + CGI :)

corba, а не кобра ) но с ней просто не выйдет, это тяжёлая артиллерия с огромным оверхедом.

Мы сделали в виде модулей на nginx + ExtJs на клиенте. Модули отдают или принимают json. Все через него и сделано.

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

В виде модулей на nginx? Вы в свою софтину вконпеляли nginx? Или nginx в софтину? Или модули как-то с софтиной общаются - как?

быстро и без багов.
с++

Мухаха! Шутка года, бро. Ты с языком ошибся.

Я бы делал фронтэнд на йаве или эрланге и коммуницировал бы с сиплюсом через jni/порт.

sunrpc

«However, RPC is extremely dangerous when left exposed to the Internet, which leads to frequent compromise of servers based upon Sun Solaris and Linux. RPC should never be exposed to the Internet.»

ШТА?

кстати, вот такой вопрос: две софтины на одной машине общаются между собой. Например, одна софтина - извращенный союз vertx/jetty/netty (что там сейчас популярно) или nginx с моим модулем. Вторая софтина - собственно игра. Как/через что сделать, чтобы они общались побыстрее? Если сделать тупо TCP/IP, оно же будет лагать, верно?

Если делаешь онлине шутер, то да, тсп тормозит. Обычно юдп используют. Слышал что в кваке, когда ивентов нету, передают нули, что бы латентность не терять. Не знаю на сколько это правда.

Но я также думаю, ты понимаешь, что про всякие хмл и прочие мыльные технологии придётся забыть и юзать родной бинарный формат предположительно с четырьмя байтами длины пакета в сетевом порядке байт и опционально с контрольной суммой в конце пакета?

Да, есть такое дело. Сесуриту и всё такое.

на одной машине

Не заметил. В случае если через loopback, то там тормозов вообще не будет. А доставка для udp под линуксом вообще гарантируется.

zeromq?

Не шутер, что-то типа RTS. Вот еще идея: а неплохо было бы транслятор классов в опкоды/пакеты. Можно сразу не заикаться, потому что крестовики - проприетарщики и такими штуками не делятся? Ну наверняка же это уже написали более 9 тысяч раз!

вау, вау, вау, люто лайкаю эту ссылку!

Общаются через базу данных и шаред память.

Protobuff?

Учти, ты сказал интернет, а он любит веб стандарты. Что есть клиентское приложение?

Проблема раз: опкод для чего? Для llvm? Если продолжить размышления, то придёшь к йаве где можно сериарилизировать любой объект и передать его по сокету вместе с методами например, а потом заюзать рефлекшин и всё такое. Или любому другому вм бейсед языку.

(На счёт йавы я может бред написал, т.к. на ней не пишу)

а он любит веб стандарты

Вы любите розы?
а я на них срал!
стране нужны паровозы,
нам нужен металл!
товарищ!
не охай,
не ахай!
не дёргай узду!
коль выполнил план,
посылай всех
в man (?? прим. перев.)
не выполнил -
сам
иди
на
фиг.

Маяковский

Лучший стандарт - автоматически сгенерированная документация по API на сайте проекта

Стандарт - это то, что экспозит мое приложение.

Что есть клиентское приложение?

Игровой движок Unity3d, и встроенный в него код на C#

чтобы узнать состав полей не нужна вм, не? Выставить требование, что, например, классы которые используются для генерации апи обязаны быть подами. А потом вручную распарсить этот код и сгенерить дальше что нужно. Без всякого рефлекшена итэпэ.

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

юзай protobuf

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

Мне кажеться так и делают. Вопрос в том, что с кодом методов делать?

опкод для чего? Для llvm?

опкод для парсера протокола, который на клиенте будет превращать поток в объекты. Т.е. смысл реюзабельной библиотеки для этого (если бы она была) как раз в том, чтобы она осмысленно могла разобрать код класса и решить, как оптимально ужать его в бинарные куски для tcp, и потом оптимально разжать на клиенте, сгенерив под распаковку код на не-C++.

Поздравляю, ты придумал кобру.

ничего не делать. Пропускать. Перечисленные для экспорта по сети классы - это просто данные. Классы-бины. Ну, максимум, геттеры, с условием что они не имеют сайд-эффектов, и все геттеры во время экспорта будут обяхательно дернуты. Если надо переслать алгоритмы - то, например, написать алгоритмы на javascript, залить их в строки, и на клиенте отдать строки в v8 или что там будет под рукой. Блин, ну как в жаве же.

алгоритмы на javascript

Вот скука. Не язык, а раковая опухоль какая-то.

Блин, ну как в жаве же.

Ну так её родную и используй, я же тебе это с самого начала написал. Нафиг тебе эти чудоюдо++?

как Ъ - разработай бинарный протокол, реализуй, продумай и проверь на предмет возможных уязвимостей

Чтобы сэкономить память и проц, и запустить тыщи людей на железе с помойки.

Чтобы сэкономить память и проц, и запустить тыщи людей на железе с помойки.

Ну тогда надо явно не ормы или какие то генераторы протоколов юзать, а спроектировать и релизовать свой протокол, оптимизированный под конкретную задачу.
Только для такого свершения нужно глубокое знание tcp/ip стека и прочих знаний вагон - игрушка того не стоит:)

А вообще protobuf самое оно.
Особенно в свете:

ну вообще, клиенту хорошо бы быть заменяемым.

Ибо есть например тыц и ещё пара тройка реализаций, только для js.

посмотри сетевой код проекта mangos, сервер world of warcraft опенсурсный

А игруха то опен сурс или проприетарщина?

Если по фану кстати делаешь, можно придумать какую нибудь забаву с clang например...

я писал код другого «опенсурсного» сервака - дедушки aspire. Вопрос в том, что весь aspire и потомки созданы целиком из говна. Хрен что проссышь, шаг в сторону - сегфолт всего сервера, палец постоянно на красной кнопке. Причем жрет это дичайшие гигабайты рамы и отъедает процессор как воду галлонами. Две тыщи человек онлайн - и привет профайлер. Как там в мангосе - не знаю, но есть предположение, что он так же состоит целиком из самописного глючного бажного говна. А мне нужны готовые, отлаженные, production-ready технологии, в том смысле, как это понимается в мире жавы. Если пацан сказал работает - значит работает, без всех этих гнилых отмазок.

Скорее всего, серверное ядро и ресурсы - проприетарщина на закрытых серверах (надо же как-то простимулировать игроков, чтобы донатили бабло), клиент - BSDv3 (+релицензия под iOS), а тулзы - Apache/BSD/MIT. Так что если кто-нибудь скажет, например, что наш редактор - говно, и там нет кнопки «покрасить юнита в зеленый цвет» - может пройти в код редактора и впихнуть сколько ему угодно любых кнопочек.

Делаю по фану, но в строгом расчете на бабло. Без бабла люди не живут.

Вообще, чото с этими крестами столько проблем вырисовывается, что чото ссыкотно стало. Может ну его нафиг, реально только поле боя с чилодробилкой на крестах, а все остальное на яве. Последних несколько проблем из /development на яве нет вообще как класса уже лет сто как.

А вебсокет вообще бы прокси

эээ. не распарсил

подумай как прикрутить zeromq

а у него как с натом?

http://www.leadwerks.com

Сам не пользовался, ничего сказать не могу. Linux-версия (включающая среду разработки, а не только билды как в Unity) сейчас в бете.

Блин, промахнулся вкладкой. Это было в 3d game engine (offline)

Просто случайные мысли, после беглого прочтения треда:

1. Protobuf или Thrift. Лучше первый, если нужна только сериализация и RPC поверх нее ты осилишь сам. 2. Если хочется RPC из коробки - откажись от C++. Посмотри, например, Finagle. 3. TCP вполне себе шустр, если отключить Нейгла. 4. ZeroMQ - говно.

Есть что-нибудь мягкое и пушистое

http://www.zeroc.com/features.html пойдет?

а почему зеромкю говно? пока не начал в него забуряться)

http://www.zeroc.com/features.html пойдет?

открыл страничку. читаю.

Ice is available under the terms of the GNU General Public License (GPL).

закрыл страничку. дальше не читал, поэтому не знаю, что это такое.

дальше не читал, поэтому не знаю, что это такое.

Не знаешь что такое GPL - а не много ли ты выпил с утра?

Нет, что такое GPL я знаю - это такая отметка на сайте, показывающая, что сайт можно дальше не читать. (т.к. использовать этот код в своем продукте все равно нельзя).

Пришёл жабакодер и спрашивает не написали ли ещё жвм на крестах...

отвечаем: написали. покойный сан. сейчас оракл допиливает.

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

но если жизни без крестов себе не представляешь, то читай это: http://msdn.microsoft.com/ru-ru/library/ee872418.aspx

это такая отметка на сайте, показывающая, что сайт можно дальше не читать. (т.к. использовать этот код в своем продукте все равно нельзя).

Вот оно чё... Зря ты дальше не почитал, там специально для тебя написано Commercial licenses are available for customers who wish to use Ice in proprietary products

Никогда лицензий на воздух не покупал и не буду. Честные люди выкладывают на гитхабе под Apache/BSD/MIT или не выкладывают вообще.

В целом, разработчики ZeroMQ попытались классифицировать все возможные паттерны сетевого взаимодействия и завернуть их в одинаковый и простой API. В результате, на мой взгляд, библиотека не умеет ни один из этих паттернов достаточно хорошо.

Основные проблемы и неудобства, с которыми пришлось столкнуться:

– Нет никакой встроенной возможности отследить отвалившееся соединение. Придется городить костыли с heartbeat-сообщениями.

– Request/reply API синхронный: нельзя отправить второй реквест, пока не получишь ответ на первый. Ответ, при этом, может не прийти никогда, поэтому всегда приходится использовать zmq_poll(), т.к. таймауты есть только там. Простота API и читабельность кода стремительно испаряются.

– Если к request/reply нужно подмешать еще и publish/subscribe, то придется открывать отдельное соединение.

– Publish/subscribe работает только по начальным байтам сообщения. Каких-либо встроенных адресов у подписчиков нет. При этом каждое опубликованное сообщение доставляется каждому подписчику, и уже подписчик решает, предназначалось ли сообщение для него (это настолько позорно, что я надеюсь, в какой-то момент это все же пофиксили).

– Под виндой используется select.