Пришла мысль по упрощению схемы авторизации пользователя.

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

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

Что-то я тебя не пойму - то нет протокола, то его придётся уже поменять... 

Да вока, вроде, ничего секретного.

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

Извиняюсь, что туго излагаю мысли.

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

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

Это сообщение отредактировал(а) Platon - 12.1.2008, 16:24

Почему?

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

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



Это сообщение отредактировал(а) Platon - 13.1.2008, 11:48

Так, еще весьма интересный вопрос встал...

При взаимодействии серверов должен ли обмен данными быть синхронным? В диаграмме видно, что авторизация проходит асинхронно, это конечно хорошо, не надо ждать. Теперь представим ситуацию отправка сообщения. сервер не нашел у себя получателя, обращается к главному серверу с просьбой доставить сообщение. (Супер-сервер содержит много серверов) он должен опросить сервера, у кого находится получатель? И вот тут проблема, как лучше сделать синхронно или асинхронно?
Синхронно: 
+ не надо делать лишних сообщений,
+ легче реализовать, прозрачность действий
- итоговое ожидание получения ответа ниже, чем при асинхронном, что является, наверно, самым главным фактором

господа вы же протокол XMPP обсуждаете.
xmpp.org/rfcs - открываем, читаем - всё уже придумали до нас).

Platon, я не очень понимаю твой UML. Connection действительно является частью User и вне его существовать не может? И вообще, у тебя тут столь массово встречается отношение агрегации... Это необычно.

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

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

Добавлено через 2 минуты и 44 секунды

На сколько я понят ты про стрелку которая идет от AuthManager к User? Это стрелочка инстанцирования.

Добавлено через 4 минуты и 13 секунд

Ну, на самом деле может. Connection существует и без User, но потом прикрепляется к нему.

Добавлено через 6 минут и 48 секунд

Хм, извиняюсь, я слабоват в UML, а какие связи должны быть?
Чувствую, что система сильно связная, но легче придумать не могу.

Ну вот, не дадут человеку велосипед изобрести. 

nornad, кратко, лаконично, а главное в точку   

Тогда это не агрегация, а обычная ассоциация, на мой взгляд. Со стереотипом uses, который обычно не указывается.


Нет, я про ту, которая, например, идёт от MinaConnection к Connection. А та стрелка, которую ты назвал "инстанцированием" по стандарту называется "зависимость"  То есть у тебя сейчас написано, что AuthManager как-то зависит от User. На практике это означет, что изменения в классе User повлекут за собой изменения в AuthManager.


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

Более того я хочу пройти весь процесс разработки ПО. От проектирования до реализации