Стратегия сетевого приложения., Помогите определиться, какой путь надежней. Опции

[Litkevich Yuriy]

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

dzyk, а как устроены таблицы БД заранее известно?

[dzyk]

Еще есть вариант того, что 1П и 2П работают в офлайне, оба изменяют одну и ту же запись, что ты будешь делать(значения записи разные)?

Если синхронизовать ОС(либо приложения) по времени, то апдейтится последний вариант из "стека триггеров"

[Andrew Selivanov]

Имеется приложение. Ядро - база данных SQLite(информация в таблицах изменяется 20-30 раз в день). Сейчас необходимо реализовать одновременное использование БД на нескольких компьюетрах "сети"(постоянных соединений нет, кто-то подключается, кто-то отключатеся, IP динамические, всего 5-6 машин).

Вот мои варианты.

1. Связать приложения по UDP и отсылать каждые х-минут контрольную сумму файла БД SQLite. Если не совпадает то коннект по TCP и клонирование самого свежего файла БД SQLite.

2. Поставить сервер MySQL|PostgreSQL|other (нереально, нет выделенного сервера)

3. Ваше предложение

При подключении посылаем широковещательный пакет смысл которого сводится к фразе "Есть кто главный?"
Если главного нет, становимся главным и начинаем отвечать на подобные запросы.
Если главный есть, открываем с ним постоянное соединение и засасываем изменения к базе (или всю базу)
На каждой машине своя актуальная копия данных, но изменения происходят только через главный сервер (нажатием жирной кнопки ДОБАВИТЬ ИЗМЕНЕНИЯ).
Если сервер умирает - происходят выборы нового на основании например приоритета (не давать пользователям ничего изменять в такие моменты, просто лочить нахрен форму с надписью обрыв связи ждите итп)
Короче смысл такой - динамический главный сервер и все изменения только через него, а иначе секс с внедрением механизма транзакций, причем думаю придется все равно с ним что то придумывать, т.к. сервера могут отвалиться, и в то время как они отваливаются отваливается главный сервер, неожиданный shutdown, итп.

[Novak]

Всё равно плохо, ибо ситуация, когда все компы не работают, один включился, потом выключился. потом врубились остальные, приводит к потере данных.
Хотя можно предусмотреть, что запись возможна только при рабочем главном сервере, а передача роли главного сервера возможна только добровольная (т.е. гарантированном копировании данных).
Остальные пусть при отсутствии главного сервака пишут в кеш, или что-то подобное файрберда (Firebird) в плане версионности замутить

[Litkevich Yuriy]

Всё равно плохо

Да!
А идея Мастер-Браузера (главного компа) вообще плохая, намой взгляд. Реализацией арбитража приходилось заниматся в сети из 128 устройств. Отлаживаться долго пришлось.

Надо думать как изменения регестрировать надежно. Тогда можно будет и обмен без блокировок наладить и без главной машины.

[Tonal]

Мне всё-таки кажется, что проще/быстрее/дешевле/надёжнее купить машинку под сервер.
Ну или уж поднять честный кластер на этих 5-7 машинках.

[Andrew Selivanov]

Всё равно плохо, ибо ситуация, когда все компы не работают, один включился, потом выключился. потом врубились остальные, приводит к потере данных.
Хотя можно предусмотреть, что запись возможна только при рабочем главном сервере, а передача роли главного сервера возможна только добровольная (т.е. гарантированном копировании данных).

Именно это я и имел ввиду под:
но изменения происходят только через главный сервер (нажатием жирной кнопки ДОБАВИТЬ ИЗМЕНЕНИЯ).

А идея Мастер-Браузера (главного компа) вообще плохая, намой взгляд. Реализацией арбитража приходилось заниматся в сети из 128 устройств. Отлаживаться долго пришлось.

Для 5-7 машин и редких изменений данных IMHO покатит схема с блокировками. Все же 128 машин это уже в несколько раз больше.

Теперь про идею в целом - да я и не претендовал на самую лучшую идею Высказал свои соображения. Вообще мне кажется очень полезно было бы изучить логику работы протоколов Gnutella, eDonkey, DCPP(ADC) даже там используются серверы. Лично мне особенно нравится как написан DCPP (каждый кто озадачится написанием своего протокола - очень рекомендую!)

[Litkevich Yuriy]

Есть приборная сеть, в которой реализована идея респределенной БД (название на языке крутится, но вспомнить не могу), узлы могут использовать любые даннын из нее, но там помоему тоже централизованая система.
Реализуется на микроконтроллерах, как следствие не должно требовать ресурсов и т.д. и т.п.

[Novak]

В приципе, очевидно, что для общего случая решения нет, потому нужны данные по фактической работе машин и БД - сколько в среднем работают вместе, бывают ли случаи работы только одной машины или можно при этом лочить БД. В общем, при пределённых условиях "плавающий" сервек - вполне нормальное решение.

[Tonal]

Да, ещё можно поднять на машинах распределённую БД. Например Mnesia из стандартной поставки Erlang-а такой является.
Т.е. поднимаем на всех машинах Mnesia - если я ничего не путаю, она сама является отдельным Erlang приложением.
Пишем адаптеры для работы с ней и всё готово.
Т.е. на конкретной машине Наша прожка коннектится к локальной Erlang-овской ноде на которой крутится Mnesia.
А она уже заботится о всей распределёнке.

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