Re: Большая история о маленьких проблемах



Posted by Борис, Киев. on December 20, 2000 at 14:20:32:

In Reply to: Большая история о маленьких проблемах posted by Valery Krumeng on December 20, 2000 at 11:35:44:

Приветствую Вас.

Замечу по Вашим выводам:

: Вывод
: Мне кажется, что было бы очень здорово, если бы можно было манипулировать правилами ФБП прямо из клиента.

Это повлечет приличную работу по объему над клиентом. Были предложения по доработке локала к клиентскому поведению(многострочник, формы в ветвях, отдача директив из форм), это проще и может расширить круг настройщиков(т.к. будет удобней удобного) и одновременно пользователей, т.к. значительная масса бухгалтеров просто боится сети, а функционально клиент-сервер прилично обскакал локал и сегодня приходится сложно отвечать локальщикам что, как и почему в ФБП.

:Мне кажется, что было бы очень здорово, если бы были установлены такие же правила и для самого клиента, т.е. можно было "изменять" поведение и внешний вид самого клиента.

Не понял, что имеется ввиду, если можно конкретнее?

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

Смотря какие данные. Относительно вероятно пересекающихся - это было и наверное останется проблемой от природы.

:А вот, что касается траффика сети, то (снова заранее прошу прощения, если чего-то безграмотное скажу), то мне кажется, было бы здорово, чтобы не клиенты обращались в один каталог обмена, а сервер отсылал "письма" об изменениях в каталоги клиентов, и только если клиенты вдруг вносят изменения, то в этом случае, они отсылали "письма" об этих изменениях в каталог сервера. Мало того, было бы очень здорово (как мне кажется), если бы эти письма были бы "шифрованы".

По поводу шифрования - отлично.

По поводу каталогов - немного сложнее.

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

Не все так просто с каталогами. По мнению многих, камнем преткновения является сканирование UPTY, т.е флага изменения состояния сервера.

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

В итоге:
1. для сервера ничего не меняется.
2. появится еще один резидент на сервере, постоянно(или с какой-то устанавливаемой периодичностью) обновляющий UPTY для клиентов.
3. клиент будет сканировать UPTY не в сетевом, а в локальном каталоге.

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


С ув. Борис.

P.S. Возможно, что существующая технология сетевой работы гораздо сложнее, чем нам кажется, а может пора серьезно подумать о терминальной версии NT? Кажется, что размеры наших исполняемых модулей многообещающи в такой постановке. У кого есть реальные внедрения, может поделитесь.


Пpишедшие ответы: