По диаграмме клиенты постоянно работают через серверы, так что не так.

nornad, ха! а как тогда узнать IP получателя? причем политика системы такова, что отправитель может узнать IP получателя только с его согласия, и как вы предлагаете образовывать какой-то там туннелинг, если не знаете IP?

Добавлено через 47 секунд
И к тому же семая нижняя стрелочка между двумя клиентами - это и есть туннелинг между пользователями.

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

ее легко вычленить из моей схемы сервер1 -> кластер-менеджер -> сервер2

уух, прям глаза загораются, можно же сделать елочку ^_^ подробности в новых схемах

При чем ПолуКластерМенеджер реализует функциональность КластерМенеджера и Сервера одновременно. Т.е. серверу нет разницы к кому он коннектится: к истинному кластер-менеджеру, или сурогату. ПолуКластерМенеджер владеет только частью северов, это позволит распределить нагрузку кластер-менеджера.

Масштабно.

Maksym, ну, на самом деле, я видел подобную схему по предмету ОС, ассоциативная память.
Более того, мне кажется, по этой схеме работает сеть Интернет.

Ррррррррррррр 
Клиент1 жмёт кнопку "послать" (файл, а не клиента   ). Сервер1 через сервер2 сообщает об этом клиенту2. Далее 2 варианта:

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

Чего тут непонятного-то?

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

Угу, особенно если добавить ещё пару уровней - ЧетвертьКластерМенеджер и ТриЧетвертиКластерМенеджер.  

Рррррррррррр, еще больще
А я уже какой пост о чем втираю? У меня на диаграмме всё это описано.

и мне непонятно




Философски   


На это и расчитано, вложенность сурогатных кластер-менеджеров будет любая.
Вот наглядное изображение:

Ну, не вижу я этого на диаграмме. Извините, раз уж не умею читать диаграммы. 
Ррр   

Да это-то понятно. Я так, прикалывался.   

Я так полагаю первый этап проектировки системы закончен? Пришли к общему мнению по всем вопросам. Теперь Диаграммы классов и следований для каждого из участников коммуникации?

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

Добавлено @ 14:07
Приватное сообщение


Сообщение-уведомление


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

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

Единственный минус что клиенты к примеру Протокола1 не смогут взаимодействовать с клиентами Протокола2, но тут конечно можно с бубном поплясать и на уровне сервера сделать конвертацию в нужный протокол, если протокол известен системе. Сервер может догадаться с какими протоколами ему надо будет работать из авторизационной информации. Всё, ваши предложения и замечания ^_^

nornad, так как ты единственный мой дельный собеседник, к тебе и обращаюсь ^_^

Это сообщение отредактировал(а) Platon - 11.1.2008, 14:17

Черт подери!!! Серверу по сути не надо искать пользователя!!! Тепрь я понимаю силу проектирования, если бы я стал сразу кодить, то система бы получилась бы совсем ущербная.

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

Вот эта мысль не ясна. У меня в принципе нет никакого протокола, сторонние разработчики смогут сделать всё, что захотят, игры One-On-One, IM, голосовую штуку, и прочее. конвертировать эти вещи 1 в другое сложно и нет смысла.

Добавлено через 2 минуты и 45 секунд
Моя текущая задача заключается в том, чтобы разыскать пользователей онлайн. Правда появляется проблема того, что пользователю могут приходить голосовые сообщения, когда он сам не имеет такой возможности, клиент не поддерживает такое.

Добавлено через 6 минут и 6 секунд
мда, я что-то уже перегибаю палочку... это тупиковая ветка.

Добавлено через 13 минут и 59 секунд
это заставляет поменять протокол отправки приватного сообщения, добавляется флажек, оставлять сообщение на сервере или нет. К примеру  , если пользователь отправил запрос на принятие файла, то его не нужно сохранять в БД, а обычные сообщения надо оставить в БД.

ЗЫ: можно куда-нибудь поприватней нас переправить, чтоб не весь инет видел, что мы тут обсуждаем...