Здравствуйте, уважаемые.

Попробую еще раз поднять свою проблему. Меня интересует как правильно организовать работу серверной сети. К примеру ICQ, как она выдерживает такие огромные нагрузки?
Вот мой вариант, смотреть только на первые 5 объектов: клиент, кластер менеджер, кластер сервер, БД


Так вот мне интересно, к примеру я хочу организовать сервис на подобии ICQ, БД, естественно, только в моем владении (неточность картинки, только Кластер-менеджер работает с БД), сервера от сторонних пользователей, как я понимаю допускаются к моему кластер-менеджеру не от балды, а чуть ли не официально подписывая бумаги о непричинении вреда работе сервиса(???)
Я так понимаю, сначала идет коннект т кластерменеджеру, он же авторизационный центр, потом приходит сообщение, что пользователь направлен на такой-то сервер.
Представим ситуацию: одного пользователя направили на 1 сервер, а другого на другой.
И каким образом организуется работа передачи письма от пользователя(отправителя) к пользователю (получатель)?
как я понимаю, сначала сервер роется в своих пользователях, нет ли кого, кому предназначается это письмо, если не нашел, запрашивает у кластерменеджера все работающие сервра и начинает спрашивать каждого, нет ли у него такого-то пользователя? если есть, сообщение передается к этому серверу, сервер передает сообщение клиенту, просто ^_^
А если пользователь не в сети? Где должно остаться сообщение? Если все непринятые сообщения перенаправлять кластер-менеджеру, то получится громоздкая работа +_+ для него.
Есть вариант: оставлять сообщения на том сервере, с которого отправитель слал письмо. Потом если получатель заходит в сеть, его сервер опрашивает все известные сервера, не оставлял ли кто сообщения этому пользователю? В принципе разряженная система получается, минус такого подхода очевиден, сервер, на котором хранятся непринятые сообщения, может быть отключен от сети, и пользователь сможет получить эти сообщения только когда сервер вновь подключится к сети...

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

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

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

Можно просто размножить сообщение по всем серверам. Пользователь вошёл в сеть, прочитал сообщения и его сервер (который кластер) разослал остальным, что клиент получил сообщения.

888 красивое число.

Это ваше предположение? Или общая практика? В принципе весьма логичная схемка.

Знаете, наверное это не лучшая практика... я тут прикинул, какая же это каша получится, если всем серверам раздать письма, потом получится чт оу некоторых серверов будет не хватать определенных писем, которые лежат только на другом. И что получается, серверу придется сгребать эту кучу корреспонденции и фильтровать уникальные? что-то я слабо представляю себе такое дело...

677 тоже неплохо 


Это скорее мои размышления на тему.


Думаешь, сервера будут постоянно включаться-выключаться? Они на то и сервера, чтобы работать практически непрерывно.
Кроме того, никто не запрещает складывать ожидающие сообщения на отдельном "системном" сервере (или на том же сервере регистрации-авторизации).

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

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

недавно было число зверя ;)

А почему не должен? Сомневаюсь, что все разом решат оставить сообщения кому-то, кого нет в системе. А если и решат, то не спасёт уже никакая схема. 
Опять же - если нагрузки становятся большими, то делается второй сервер и функции распределяются между ними.

Речь идет о сторонних пользовательских серверах, которые непредсказуемо вкл/выкл.
Я полагаю, есть какой-то костяк всей этой системы: Кластер-менеджер, БД и, как оказалось, сервер приема непрочитаных сообщений, ну, и несколько серверов для первоначальной работы, это всё в штаб-квартире и на замок


Об этом и речь. Каким образом должно происходить распределение?

Ну, не будут же их выключать каждые полчаса, в конце концов. 

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

Так, ладно пока пусть будет 1 сервер непринятых сообщений.

У меня тут назрели 4 принципиальные схемки работы системы (другие будут копировать друг друга). Прошу оценить, подсказать, что не так?

Диаграмма авторизации пользователя


Диаграмма передачи сообщения



Диаграмма отправки файла


Диаграмма изменения статуса


Это сообщение отредактировал(а) Platon - 10.1.2008, 20:08

При передаче сообщения я бы сделал поиск сервера так:
Ищем пользователя у себя (это быстро). Если нет - спрашиваем основной сервер (куда пошло сообщение о событии авторизации клиента) о том, на какой сервер он его послал (кстати, и от "подделок" это немного защитит).
Таким образом серверу совершенно не обязательно знать, какие кроме него есть сервера.
Да, кстати, стоит сделать таблицу клиентов сервера под тип таблиц DNS - и своих там хранить, и чужих туда же пихать на некоторое время (до 15 минут максимум, но лучше на пару минут).
При непосредственной отправке сообщение доставлять с сервера не прямо клиенту, а его серверу, который уже и доставит его клиенту.

Отправку файла я бы вообще сделал мимо сервера. Пусть клиенты делают между собой туннель - так оно и безопаснее (в плане конфиденциальности), и быстрее.

При смене статуса я также изменил бы в сторону унификации. Пусть сервер1 говорит центральному, что его клиент сменил статус. После этого центральный сообщает остальным статус клиента (кому не надо - нет такого клиента в таблице - игнорирует).

Боюсь я нагружать основной сервер лишней работой, авторизация то кажется мне весьма массовой, + еще обязательно будут обрабатываться все изменения статусов, анкет и прочей лабуды, не много ли это для 1 сервера? Хотя выглядит куда правильней и безопасней, остается видимо только один вопрос: не многовато ли?*


Совсем не понял как это и к чему?



каламбур какой-то
после того что описано выше передача будт следующего вида: клиент1 -> сервер1 -> кластер-менеджер(!)* -> сервер2 -> клиент2

* и тут(!) я понял что можно разделить полномочия: логин-сервера(авторизация) и кластер-менеджера(маршрутизация между клиентами)


никак не получится!!! ведь клиенту1 надо знать IP клиента2, а он будет передаваться только в том случае, если клиент2 нажмет на кнопку принять файл.



да, согласен.

Добавлено через 11 минут и 53 секунды
Пришла мысль по упрощению системы:
Получается в штабквартире в локальную сеть можно объединить всего 3 разновидности серверов: кластер-сервер и БД (1 .. N), серверы-работники.

Мы видим, что тут отсутствует логин-сервер и сервер непринятых сообщений, я подумал, что если нагрузка будет действительно большой, таблицы можно разделить между несколькими СУБД на разных машинах, к примеру СУБД на авторизацию, СУБД на непрочитанные сообщения и прочее. Как на такое смотрите?

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

Не смешивай схему получения адреса сервера/клиента и непосредственно передачи.

Я тебе это уже давно предложил 

Парой строк выше 

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

Смотри. Клиентов сервера надо где-то хранить, так? Так. Хранить их лучше либо в бд, либо в файле. Я бы выбрал бд - удобнее, да и при большом количестве - быстрее.

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

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

P.S. "Вот что крест животворящий делает" (царь Иоан I (с) "Иван Васильевич меняет профессию)    

Ну так по нажатию кнопки принятия не приём начинать, а устанавливать туннель и передавать файл. Всё равно пока клиент2 не нажмёт кнопку, файл ему доставлять не стоит (иначе он сильно разозлится и будет кидаться в нас тапочками).

А разве по диаграмме у меня не так?!