[hwd]

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

но... этот подход плох по следующим причинам:
1. если мне нужно обновить какой-то плагин или шаблон, то я не могу это сделать до тех пор, пока все пользователи, загрузившие этот плагин, не завершат сеансы своей работы, или до тех пор, пока пользователи, создавшие чертёж, на основании шаблона, не сохранят его под некоторым именем.
2. для dotnet-плагинов НА КАЖДОМ КОМПЬЮТЕРЕ я должен С ПРАВАМИ АДМИНА один раз вызвать некоторую команду, с определёнными параметрами, дабы фрэймворк позволил запускать плагин, расположенный не на локальной машине (это зашито в политику безопасности фрэймоворка - он сеть воспринимает как источник угрозы).
3. Временами права, назначенные в п.2 почему-то перестают работать. Повторная инициализация прав не даёт результата. Приходится давать права с др. уровнем доступа. Но это не дело, ибо х.з. когда и почему могут отвалиться права и с этим уровнем доступа.
Поясню на конкретном примере:
Если изначально это:
"C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CasPol.exe" -m -ag 1.2 -url "file://\\hyprostroy/dfs/SystemFolder/tools/AutoCAD tools/AcadPlagins/*" FullTrust
давало нужное разрешение, и всё прекрасно запускалось, то на некоторых машинах, разрешение вдруг ни с того ни с сего переставало работать. повторный запуск выше приведённой строки положительного результата не давал. Но если её немного изменить, запустив такой вариант:
"C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CasPol.exe" -m -ag 1 -url "file://\\hyprostroy/dfs/SystemFolder/tools/AutoCAD tools/AcadPlagins/*" FullTrust
всё снова начинает работать. Не хочется ждать, когда и для "1" перестанет работать...
Если дотнет библиотеки будут расположены на локальной машине, то проблемы пунктов 2 и 3 автоматом отпадают.
4. Временами юзеры сталкиваются с тем, что в чертеже вдруг шрифты начинают отображаться неверно - показывают симплекс, вместо нужного. Оно и понятно: симплекс установлен как используемый по умолчанию. В таком случае я советую перегрузить автокад. Как правило это помогает, но бывали неоднократные случаи, когда симплекс видимо насильно прописывался в свойствах примитивов, хотя в их свойствах фигурирует нужный мне текстовый стиль, а тот имеет нужный шрифт. Думаю, что проблема отображения шрифтов связана с перебоями в сети. Но то, что временами шрифт не удавалось вернуть обратно - это очень хреново. Т.о. делаю вывод, что шрифты лучше хранить на локальной машине.

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

я написал код, который это выполняет, протестировал, на небольших объёмах данных - остался доволен результатом. Но, как оказалось - рано радовался:
У меня в репозитории имеется два каталога, в которых хранятся файлы шрифтов и штриховок...
Это маленькие файлы, но их ОЧЕНЬ много:
Шрифтов - 334 шт.
Штриховок - 677 шт.

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

Сообщение от Обнаружено событие ContextSwitchDeadlock Message: CLR не удалось перейти из COM-контекста 0x183f18 в COM-контекст 0x183da8 за 60 секунд. Наиболее вероятно, что поток, владеющий контекстом/апартаментом назначения, находится в режиме ожидания или выполнения очень длительной операции без прокачки сообщений Windows. Обычно эта ситуация отрицательно влияет на производительность и даже может привести к зависанию приложения или чрезмерному расходованию памяти. Чтобы избежать этой проблемы, все потоки однопоточного апартамента (STA) должны использовать примитивы ожидания для прокачки (например, CoWaitForMultipleHandles) и периодически прокачивать сообщения во время длительных операций.

Т.о. и второй мой вариант меня не устраивает... Я подумал о третьем варианте:

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

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

т.о. если кратко, то мне нужно придумать, как решить приведённые мною выше 4 пункта. Пока что я думаю реализовать два репозитория (серверный и локальный) и выполнить механизм синхронизации. Но подводные камни этого решения я указал выше. Может у кого-то есть более лучшая идея? буду признателен за неё.

[hwd]

Сообщение от gomer каждому юзеру нужно определеннное количество настроек, он их определяет в (3), остальные являются "по умолчанию"... для системы нужны все поэтому недостающие она должна брать из (2) и (1) по очереди... Такая система более гибкая... хотя, не скрою, возможно, в таком случае вероятность поломки выше...

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

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

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

Сообщение от gomer Вы все с ног на голову перевернули... так жить нельзя...

Без комментариев...

[gomer]

Сообщение от hwd Под словом "сервер" я понимаю не дохлый x386, поэтому он однозначно не зависнет.

Подсервером я понимаю программу, а не железо, вне зависимости от платформы...

Сообщение от hwd Вы можете теоретизировать сколько угодно, а я делаю и оно работает.

Тогда не задавайте глупых вопросов...

зы

Сообщение от hwd Ну перечислили вы мои три пункта в обратном порядке, а разница-то в чём? Грузить сначала с (1), потом с (2), потом с (3) или наоборот: грузить с (3) потом с (2), потом с (3) - разницы никакой. Тем более, что загрузка начинается только после того как будет составлен полный список загружаемых файлов (собранный из всех трёх конфигурационных файлов) и отброшены дублирующиеся записи.

Если настроить (3) как нужно (2) и (1) можно не проверять... это экономит время...

Сообщение от hwd Которая к тому же почему-то выше (этого вообще не понял)...

Вероятность того что юзер ткнет не туда больше вероятности системной ошибки...

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

[Pastor]

А почему нельзя без всяких MD5-хэшев просто сравнивать время последней модификации файла на сервере и файла в локальном кэше.?

[hwd]

Сообщение от gomer Если настроить (3) как нужно (2) и (1) можно не проверять... это экономит время...

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

Сообщение от gomer Тогда не задавайте глупых вопросов...

Пожалуй... Ибо мне несколько надоело читать лично ваши "умные" ответы, даваемые в поучающей форме и зачастую вообще не в тему.

Сообщение от gomer Вероятность того что юзер ткнет не туда больше вероятности системной ошибки...

Какой юзер? Куда ткнёт? Хватит ерунду писать.

Сообщение от Pastor А почему нельзя без всяких MD5-хэшев просто сравнивать время последней модификации файла на сервере и файла в локальном кэше.?

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

[Дима_]

Сообщение от hwd Сравнение хешей - самый надёжный способ проверки файлов на идентичность

ну не считая сравнения целиком

[ShaggyDoc]

Вообще не понимаю, что такое администратор САД??? Вот Администратор сети - понимаю, а САД не понимаю... Да юзеру о вас 100 лет не знать и он будет работать... Он и в голом акаде будет работать... А если все работа будет двумя кнопками делаться, то он и вовсе себя не нужным почувствует и обозлится на вас.

Администратор CAD - чрезвычайно необходимая фигура. Замечательно, что у hwd это есть. Именно он и должен обеспечить, чтобы у юзеров всё было "двумя кнопками". Это не "администратор сети" (сисадмин) - у того совсем другие задачи и он может вообще мало чего понимать в AutoCAD - для него это "процесс". Но системный администратор и администратор САПР должны тесно взаимодействовать.

Серьезное проектирование можно сравнить с конвейерным производством. Там нет места кустарям-одиночкам. Все должны работать по единым стандартам предприятия, с едиными программами, библиотеками. Нету здесь места "демократии". Такие порядки, конечно не нравятся "слесарям-интеллигентам" наподобие незабвенного В.М. Полесова.

Как работу сборочного конвейера организую технологи, так и работу "проектного конвейера" должен организовывать технолог проектирования.

Что касается технических сторон:

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

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

Можно основные моменты. Почему? Или, если в "Сапр на базе" этот момент разжеван, тогда не надо, посмотрю сам.

Там как раз предусматривался вариант с максимальным выносом общих файлов на сервер. И с различными вариантами прав пользователей на разные действия внутри CAD. Такое надо делать, когда в организации отлажена правильная система работы.

Однако в большинстве случаев работа ведется бессистемно, да и внутри даже приличных на вид организаций процветает сепаратизм. Грубо говоря, никто ни с кем не хочет делиться. Работа дублируется. Например, вместо ведения единой базы оборудования и изделий для СО каждый делает свою локальную.

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

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

[hwd]

Сообщение от Дима_ ну не считая сравнения целиком

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

Сообщение от ShaggyDoc При синхронизации надо использовать ZIP, причем с небольшим сжатием (средним). Даже если вообще не сжимать, то операции упаковки-распаковки занимают времени намного меньше, чем при множестве файлов. Ведь каждый файл надо записать в таблицу, присвоить атрибуты и прочее. Это независимо от организации самого процеса. Попробуйте хотя бы синхронизировать с помощью TotalCommander - разница очевидна.

Спасибо. Сегодня реализую это. О результатах (скорости синхронизации) отпишусь.

Offtop: п.с. Плохо, что в AutoCAD 2009 нельзя использовать .Net Framework 4.0 - можно было бы с помощью PLINQ раскидать процесс синхронизации не только по разным потокам, но и по процессорам - прирост в скорости был бы значительный... (((

[Дима_]

Сообщение от hwd Я никому не навязываю проверку идентичности именно с помощью сверки хешей по алгоритму MD5,

Да пошутил я, конечно правильней по хешу.

[Pastor]

Сравнение хешей - самый надёжный способ проверки файлов на идентичность. Это не так затратно по ресурсам и времени, как вы можете подумать

Всё познаётся в сравнении. Может проверка времени последней модификации окажется еще мене затратной? А вдруг, в разы менее затратной?

[hwd]

Сообщение от Pastor Всё познаётся в сравнении. Может проверка времени последней модификации окажется еще мене затратной? А вдруг, в разы менее затратной?

Можете не гадать, а попробовать, если у вас есть такое желание.
Дело ведь не только в скорости, но и в достоверности проверки.

[Pastor]

Можете не гадать, а попробовать, если у вас есть такое желание.

А разве я автор темы? И если вы уже пробовали и знаете результат, то почему об этом нельзя просто сказать, без наездов.

Дело ведь не только в скорости, но и в достоверности проверки.

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

[Александр Ривилис]

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

Тут есть нюансы и с логикой работы, и с синхронизацией времени PC<->сервер.

[hwd]

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

А если новый файл оказался "кривым" и следует откатиться к прежней версии?

Сообщение от Pastor А разве я автор темы? И если вы уже пробовали и знаете результат, то почему об этом нельзя просто сказать, без наездов.

Я не "наезжаю" - выше уже писал, что отдаю предпочтение сравнению хешей по MD5, а сравнение дат модификации мне не интересно, поскольку не считаю его достаточно надёжным (имхо).

[Pastor]

А если новый файл оказался "кривым" и следует откатиться к прежней версии?

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

[zamtmn]

hwd
Рассмотрите возможность применения для синхронизации какой либо системы контроля версий, например SVN. Это конечно лишняя зависимость, но вопросы типа кривых файлов и времени модификации отпадут сами собой

[hwd]

Сообщение от zamtmn hwd Рассмотрите возможность применения для синхронизации какой либо системы контроля версий, например SVN. Это конечно лишняя зависимость, но вопросы типа кривых файлов и времени модификации отпадут сами собой

Интересная тема, почитаю, спасибо!

[ShaggyDoc]

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

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

Я бы советовал иметь одного доверенного юзера-тестировщика. Вот с ним можно и синхронизировать. А уж когда и через него отработано - всем другим. Но по-простому, не заморачиваясь сравнениями. Заменять всё, за исключением файлов, специально предназначенных для пользовательских настроек.

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

[hwd]

Сообщение от ShaggyDoc Но по-простому, не заморачиваясь сравнениями. Заменять всё, за исключением файлов, специально предназначенных для пользовательских настроек. Да и здесь путь известный - создание инсталлятора, который, при необходимости, будет делать и обновления. Он знает, как это делать, надо только в сценарии задать, и не тратить силы на изобретения. Вот инсталлятор может и в сети лежать. А наличие разных версии инсталляторов позволяет и откатить установленное до любого уровня.

Честно говоря, изначально я надеялся, что сверка хешей поможет сэкономить время, т.к. придётся копировать не всё подряд, а лишь выборочные файлы. Но пока что результаты моих тестов сводятся к тому, что банальная замена всего подряд (распаковывая из несжатого zip-архива) выполняется быстрее. (((
Здесь выложил один из тестов. Результат не порадовал...
ShaggyDoc, я так понял, что ваш инсталлятор заменяет абсолютно всё, а не выборочные файлы?
Пожалуй да, с инсталлятором и заменой всего - самый простой и надёжный вариант будет. И всё же мне жаль, что идея с проверкой хешей не подошла... (((

[ShaggyDoc]

Но пока что результаты моих тестов сводятся к тому, что банальная замена всего подряд (распаковывая из несжатого zip-архива) выполняется быстрее

Ну так я сразу так советовал.

я так понял, что ваш инсталлятор заменяет абсолютно всё, а не выборочные файлы?

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

Детали зависят от используемой программы для создания инсталляций. Я использую InnoSetup. Он, кстати, и с permissions может работать. Важно ведь ещё кто владельцем файлов будет. В принципе все современные инсталляторы должны это делать, но InnoSetup в исходниках, поэтому я знаю ещё и как именно он что-то делает.

[hwd]

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