LINUX.ORG.RU

Архитектура, клиент-серверное взаимодействие.


0

0

Имеются сервер и клиент, причём, на сервере может работать несколько клиентов одновременно. Функции клиента - загружать с сервера списки определённых структур данных и работать с ними. Всего поддерживается 4 операции: обновить список, добавить элемент, удалить и изменить существующий. Сервер абсолютно пассивен, т.е. не уведомляет одного клиента об изменениях, сделанных другими.

Данные устроены так, что структуры из одних списков ссылаются на структуры из других. Т.е. между ними есть зависимости. При этом хочется, чтобы, в коде, имея экземпляр структуры B, ссылающейся на экземпляр A, можно было бы получить из первого именно экземпляр второго, а не имя, ID или что-то такое. То есть, возникает задача разрешения зависимостей.

Если экземпляр B ссылается на экземпляр A, и этот A на сервере кто-то удалил, то B тоже удалится на сервере. Если кто-то другой после удаления обновит список A и не обновит список B, то целостность у него нарушится. Поэтому, хочется иметь возможность проверки актуальности данных. Узнать, имеем ли мы полностью актуальные данные на данный момент невозможно, но можно придумать термин: что-то вроде "данные актуальны для последнего рефреша". То есть, если у списка A значение счётчика обновлений больше, чем у B, то целостность гарантировать нельзя, и надо обновлять всю цепочку зависимотей B и сам B.

Я продумал систему с такой функциональностью, но только для однопоточного варианта. В реальности же, юзер вполне себе может нажать "refresh" на B, который зависит от A, сразу же нажать Refresh на A, а может даже и что-то там изменить во время работы. Вариантов возникает, как минимум, два: как-то хитро всё это синхронизовавыть и продумывать все возможные варианты, или использовать очередь, но оба варианта имею свои минусы.

Можно описать подробнее, но, пока, вопрос-то вот в чём. Наверняка такая задача уже кем-то решена, не одним способом и даже название имеет. Какое? Подскажите, куда копать. Ну или может кто сталкивался.

Задача бонально простая. Не понимаю чем не устроил SQL, или в крайнем случае пхп скрипт на вебсервере в связке с мускулом. Тут кода буквально на лист ИМХО.

Belevern
()

Выбери себе что-нибудь из IPC подходящее, в зависимости от, так сказать.. Да, и взаимодействия между сервером и клиентами тоже придётся пересмотреть. Копай в сторону кластерных файловых систем.

MiracleMan ★★★★★
()

> Наверняка такая задача уже кем-то решена, не одним способом и даже название имеет. Какое?

Реляционная клиент-серверная база данных.

LamerOk ★★★★★
()

> Можно описать подробнее, но, пока, вопрос-то вот в чём. Наверняка такая задача уже кем-то решена, не одним способом и даже название имеет. Какое?

The WEB! тебе нужны HTTP, hyper text, и автогенерация index.html. класть - PUT'ом, брать GET'ом, удалять DELETE'ом. ссылки <a href=...>'ом. Рефрешей всяких в HTTP до бесу предусмотрено.

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

gods-little-toy ★★★
()

Да, по поводу средств. Сервер написан на плюсах, вне моей компетенции и переписываться не будет.

Клиент - на Яве. Обмен данными - самопальный XML по сокету. Клиент - графический, swing, кроме этих списков и редакторов ничего больше не содержит.

Да, и ещё одна особенность - есть циклические зависимости. Конкретно - каждый объект User содержит список объектов Group(собственно, группы, в которых он состоит) и наоборот, группа содержит список юзеров. Редактироваться могут как группы у юзера, так и юзеры в группе.

Score-49
() автор топика
Ответ на: комментарий от gods-little-toy

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

> Существенный вопрос - открытая у тебя система (потенциально бесконечное число бесконечно тормозящих клиентов) или нет.


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

Score-49
() автор топика
Ответ на: комментарий от Score-49

Хочется простого и совсем не странного: Во-первых, в любой момент быть уверенным, что имеющийся список - актуален для момента его последнего обновления вместе со всеми его зависимостями. Например, если B зависит от A, другой клиент удалил элемент списка A(связанные элементы B тоже удалились), наш клиент рефрешнул список A и не рефрешнул B - получилась рассинхронизация, такого допускать нельзя. Во-вторых, хочется, иметь в объектах из списка B ссылки на экземпляры A, а не name, id и т.д.

Сервер поддерживает для каждого *списка объектов* только это 4 операции - получить список, добавить/удалить/изменить элемент списка.

Score-49
() автор топика
Ответ на: комментарий от MiracleMan

> Выбери себе что-нибудь из IPC подходящее, в зависимости от, так сказать..

> Копай в сторону кластерных файловых систем.


Спасибо, смотрю.

> Да, и взаимодействия между сервером и клиентами тоже придётся пересмотреть.


Вот тут я ничего не решаю, это вряд ли.

Score-49
() автор топика
Ответ на: комментарий от Score-49

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

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

А какие функции у этой прокси?

Меня многопоточность смущает больше всего. Для однопоточного случая всё уже готово. Список B зависит от A. Пользователь может рефрешнуть B (что повлечёт рефреш A), а во время этого ещё запросить рефреш A. Так-же, он может это всё параллельно изменять, например, запросить рефреш B и, во время его, удалить какой-то из списка A и т.д.

И вот тут непонятно: или как-то ограничивать пользователя (сейчас ограничений нету, может быть, это просто не продумано) или как-то мучаться с синхронизациями, или укладывать всё в очередь...

Score-49
() автор топика
Ответ на: комментарий от Score-49

>укладывать всё в очередь...

Ну да, если только к клиентам доступ.

>А какие функции у этой прокси?

Это зависит от функций вашего сервера.

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

> Ну да, если только к клиентам доступ.

Это хорошо, но тут тоже возникает проблема. После логина, клиенту нужно загрузить все данные. Самый простой вариант - рпобежаться тупо по всем спискам и запросить рефреш. Но, когда у списков есть зависимости, получается, что одно и то-же рефрешнется несколько раз за очень короткий промежуток времени. Это нежелательно, т.к. излишне. Тут нужно или блокировать всё дерево зависимостей на время рефреша, или как-то упрощать очередь, например, так: когда туда пытаются добавить то, что там уже есть - не добавлять это.

> Это зависит от функций вашего сервера.


Сервер поддерживает те 4 операции для списков, это главное, что используется в этом клиенте.

Score-49
() автор топика
Ответ на: комментарий от Score-49

> Вот тут я ничего не решаю, это вряд ли.
...
> А какие функции у этой прокси?

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

В целом - это идиотизм высшей степени.

> Меня многопоточность смущает больше всего.


И правильно смущает. Почитай хотя бы про блокировки на таблицах/записях в mysql, чтобы понять, как крутятся колеса у этого велосипеда.

LamerOk ★★★★★
()
Ответ на: комментарий от Score-49

>Сервер поддерживает те 4 операции для списков, это главное, что используется в этом клиенте.

Т.е. это просто хранилище данных? Тогда, как тут уже советовали, подумай о том, чтобы поставить реляционную БД, переписать клиент для работы с ней, и сделать репликацию с основным сервером (если он вообще после этого будет нужен).

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

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

То есть, задача - обеспечить связность данных именно на этих четырёх операциях.

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