! Модератор: Начало темы было тут
--------------



Ну, это уже на усмотрение разработчиков. Я указал, что HTTP сервер может быть Embedded. Но ничто не мешает этот HTTP сервер разместить на другой машине.

Но открывать внешнему миру лучше доступ к 1 машине, чем к 2, или я тут заблуждаюсь?

Это сообщение отредактировал(а) powerOn - 9.9.2008, 09:19

При увеличении количества клиентов рано или поздно придется точки доступа добавлять. Если у клиента нет ограничения, что он имеет право соединяться только к тому серверу, с которого загружен, то совсем хорошо - если один сервер "затонет", то у его клиентов есть шанс перескочить на оставшиеся на плаву.    

точки доступа добавлять однозначно надо будет ^_^ но это будет кластеризация, или как правильно сказать... и тогда, опять-таки будет выгодно иметь embedded HTTPServer

Представим картинки
1. HTTPServer и SocketServer на одной машине Server
    

2. WebContainer (WC) и SocketServer (SS) на разных машинах



Как видим связей во второй схеме больше. Больше накладных расходов на взаимодействие. Больше соединений к главному серверу.

К сожалению, компетентности не хватит подсчитать в точных цифрах сколько надо Серверов 1-й схемы, чтобы была эквивалентная схема.
Но думаю на 6 пар WC--SS нужно в 1.5 раза больше серверов Server, т.е. 9 серверов.

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

Я так полагаю, в скором будущем мы сможем увидеть эти драгоценные мысли в блоге?

Возможно, что нагрузка на WC будет меньше (однократные эпизодические запросы), чем на SS. Вроде их число не обязательно должно совпадать с SS. Но это уже фантазии. Заранее все не предусмотришь  .  
P.S. А "драгоценную" мысль (про минусы embedded на сервере),  я уже "увековечил" здесь. Спасибо за предоставленную возможность  .

Это сообщение отредактировал(а) COVD - 6.9.2008, 19:51

Новая схема общего случая получается такой, на группу S-серверов приходится 1 W-сервер

Во-первых, даже такая схема, я считаю, имеет много сетевых связей, и это не показатель для гордости. KIS ^_^
Во-вторых, не вижу никаких преград выделить Sun HttpServer в отдельное приложение
В-третьих, если при проектировании системы закладывается ее неимоверное разрастание и распределение, можно ведь заложить интерфейсы взаимодействия S и W частей.

Добавлено через 3 минуты и 15 секунд
На схеме под client понимается группа клиентов с соединениями к одному и тому же SS и WS

Я и не говорил, что есть "преграды". Я хотел сказать, что на серверной стороне я бы лучше сразу делал отдельно. Что "embedded" - это решение скорее для клиента. Если на сервере будет расти количество обслуживаемых клиентов, то всякие "embedded" решения на сервере возможно придется отсоединять и переносить на другие компьютеры.  Конечно, это повлечет за собой увеличение сетевого трафика между серверными компонентами, но это локальный трафик, который контролируем (в отличии от интернета).



Закладывается не "неимоверная" возможность расширения, а по необходимости: растет кол-во обслуживаемых клиентов -> добавляем пару компьютеров на сервере.

Мы как-то абстрактно тут обсуждаем, но S и W не должны между собой никак взаимодействовать. Это независимые точки доступа в систему. W - это например, Томкат, который выдает клиенту статическую информацию по запросу.  А S - это например, MINA, который дает клиенту поток данных через постоянное соединение. И этот поток является обновлением статической информации, полученной от W.    



Это сообщение отредактировал(а) COVD - 22.9.2008, 13:43

Как построить ведь. Представим ситуацию, когда авторизацию проводим через S, получаем session_id, и эта сессия является общей для W и S, т.е. мы не отправляем W запросы с логином и паролем, а только текущую session_id, в такой схеме я вижу целесообразным объединение W и S 

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

проведем параллели: есть Embedded DB, есть Server DB. Дизайн хорошо спроектированной программы позволяет нам изменить тип взаимодействия с БД 1 строкой.

 
Они не должны напрямую общаться по причине, если один из них помрет, то клиент может быть обслуженным другим аналогичным компонентом. У них должен быть общий ресурс, с которым они могут общаться. Например, база данных. Там session_id и хранить (в основной и дублирующей базах). Тогда неважно будет где клиент логинился.



да я не против. Наверное, бывает что 1 строкой. Все EE для того и придумано, чтобы 1 строкой . 

так не интересно  спора так не выйдет.


А в моей схеме так же. Только нагрузка "катания шаров" session_id отсутствует. В случае отказа клиент переподключается к другому аналогичному компоненту.

 

т.е. вот здесь :



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

Да собственно, философия в том, чтобы сократить накладные расходы (локальный траффик)

Добавлено @ 14:10

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

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

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



Я предполагал, что W и есть просто веб-контейнер, который ни данных ни логики не содержит. Аналогично и S. Я бы так и делал.

PS. 
Platon. Красивое название топику придумали  Но знатоки наверное скажут, что все это реализовано в EE:  сервер приложений для W и система сообщений ( ActiveMQ, Tibco,..) для S. И все это, конечно, "одной строчкой"  . Так чем нам по окопам бегать, не лучше ли сразу армиями командовать?     




Это сообщение отредактировал(а) COVD - 25.9.2008, 17:49