Подскажите библиотеку или как это делается (RPC, Network shared memory, или что-то из клястеров)

kerrighed.org ?

> kerrighed.org ?

Не то. Нужно не всю систему расшаривать, а только одно приложение. Чтобы к примеру buf1[123] = 312; это запись 312 на компьютер 1, и buf2[123] = 123; это запись 123 на компьютер 2. И чтобы в случае невозможности записи/чтения, я получал отлуп, причем не фатальный, сразу.

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

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

Лучше на ZeroC ICE посмотри, но это тоже RPC, а не разделяемая память.

Посмотри распределенную службу обмена сообщениями spread.org Хотя это только транспорт.

Может посмотреть в сторону Erlang в купе с каким-нибудь MQ?

Кстати, у эрланга достаточно простая интеграция с явой (для гуя, например), в том плане что пишешь на яве ноду, которая от родной эрланговской, с точки зрения кода на эрланге, не отличается.

У эрланга классно сделана возможность обмениваться его выражениями, хранить их в БД, бинарном логе и т.п.

Можно покопать в сторону Google Protocol Buffers (http://code.google.com/apis/protocolbuffers/docs/overview.html) + что-то типа boost::asio

> Посмотри распределенную службу обмена сообщениями spread.org Хотя это только транспорт. Не то: Не нужны боардкасты, групы юзеры итд. Не нужно шифрование итд. Нужно предельно просто, быстро и надежно.

Гугл, совсем не при чем.

Эрланг тоже не то, но ближе. Нужен обмен, между двумя рядом стоящими компютерами, причем быстро, надежно и просто. Хотелось бы к примеру нормальную shared memory, желаетльно не через перегрузку функций на С++, и обмен через tcp/ip.

> Не то: Не нужны боардкасты, групы юзеры итд. Не нужно шифрование итд. > Нужно предельно просто, быстро и надежно.

Дело конечно твое, но у нас в паре проектов Spread используется именно для синхронизации общей памяти на нескольких управляющих ПК и обмена между АРМ и управляющими ПК. Как только серваков становится больше 2-х - сразу же возникает вопрос про разделение функционала на группы пользователей. Шифрование в открытой версии отсутствует! Да есть Secure Spread - но он закрытый и коммерческий.

И если ты посмотришь пользователей Spread - то они в основном находятся именно в области обмена информацией в кластерах компов или репликации баз данных.

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

Так что я могу сделать обмен сообщениями через голый TCP, или опустится до UDP/IP вплоть до ethernet frames и ниже. Растояние между компами очень не большое - в пределах киллометра. Но нужно сделать так, чтобы была надежная связь, коммуникации между разными компютерами, и чтобы оно работало даже если любой из компов сгорел (другие должны сразу же (к примеру через 100 милисекунд) об этом узнать). Я не могу понять, зачем мне spread, если голого TCP мне с головой хватит. Прописать на каждом компе вручную (без DHCP) IP адресса и общаться прямо поверх TCP, меня устроит. Но ей богу мне кажется что я изобретаю велосипед. А XML-RPC больше на круизный лайнер похоже, который мне тоже не нужен. Мне нужен просто велосипед, чтобы связать две задачи на разных компах.

Есть какие-то идеи?

mpich2 ?

> mpich2 ? Собрал. Весьма интресно, но, снова не то. Мне бы готовые библиотеки для вызова функций на удаленном компе, которые могут большие массивы возвращать. Не запустить одну задачу на 100 компах, а подключиться к уже работающей задачи, получить мозможноть получить данные из той задачи, итд. Покопаю еще, довольно близко к тому что нужно, но совсем не ясно как поведет эта система, если (грубо говоря) я сделаю mpiexec -n 2 моя задача, а один из двух серверов на которых моя задача будет крутится, внезапно помрет. Есть подозрение что при этом сдохнет вся система.

О_о. Сама задача оформляется в виде приложения-сервера, пускается в окружении mpich2. Следующий логический уровень - отказоустойчивость кластера - никак с выполнением самого приложения не связан. Ничего у тебя что-то повалится при отпадении одной ноды.

И как долго я буду ждать MPI_Recv от умерший ноды? Пока TCP таймаут не пройдет? И главное - чем это будет лучше обычных тупых сокетов?

ИМХО с mpich2, я максимум что получу, это возможность отказаться от TCP в пользу чего-то более быстрого, и менее нагружающего процессор.

2 Алл, XML-RPC, JSON-RPC, CORBA. Что-то еще под Linuxом живет?

А memcached для shared memory не смотрел?

> А memcached для shared memory не смотрел?

Посмотрел. Не подходит. Кеш вообще исключен. В памяти результаты вычислений. Их кешировать нельзя.