[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 я написал код, который это выполняет, протестировал, на небольших объёмах данных - остался доволен результатом... ... Шрифтов - 334 шт. Штриховок - 677 шт. ... Синхронизацию файлов я произвожу путём сверки их хешей по алгоритму MD5. При таком количестве файлов синхронизация занимает от 20 сек до почти минуты... Это слишком долго.

Все то-же самое, но использовать 1 за'zip'ованный архив - при запуске - проверяешь его md5 - не совпал со своим - перезагрузка, распаковка.

[hwd]

Сообщение от Дима_ использовать 1 за'zip'ованный архив

Сиба, попробую сегодня.

[Лиспер]

Дополнительно: почему бы не объединить все штриховки в общий файл acadiso.pat?

[hwd]

Сообщение от Лиспер почему бы не объединить все штриховки в общий файл acadiso.pat?

так и сделаю - солью программно в один файл и назову acadiso+.pat

[ShaggyDoc]

Да, уж - "горе от ума"
Решение размещать все локально - правильное. Я давно к нему пришел.

Но далее:

1. Зачем автоматически синхронизировать локальный репозиторий с серверным? Да еще при каждом запуске Автокада? Где гарантия, что на сервере библиотеки "правильно исправлены"? Да и зачем все это непрерывно править? Это никогда к хорошим результатом не приводило.

А правильный путь известен - периодическое обновление по инициативе администратора.

2. Зачем при синхронизации сверять хэши? Да просто заменяйте файлы (можно только обновленные). Разумеется те, которые юзерам запрещено изменять.

3. Зачем столько файлов шрифтов и штриховок? Шрифтов - 334 шт!
Штриховок - 677 шт! Кому столько надо? Да не более 5 шрифтов достаточно, чтобы обеспечить "полную демократию". А кому нужны столько штриховок? Вот у меня в ruCAD все мыслимые (предусмотренные стандартами) штриховки, включая топографию, занимают 39 кб в одном файле и он не пополнялся уже лет 10.

То же, наверное, и с другими библиотечными элементами...

[Дима_]

Вариант второй - пользователь вначале грузит только для чтения xml (БД? - не суть) - где расписаны сетевые пути файлов настроек и в соответствии с ним идет конфигурация автокада - надо поменять - сделал новый каталог - переправил xml, а через недельку старый стер. Тогда и репризиторий не нужен.

[hwd]

Сообщение от ShaggyDoc 1. Зачем автоматически синхронизировать локальный репозиторий с серверным? Да еще при каждом запуске Автокада? Где гарантия, что на сервере библиотеки "правильно исправлены"?

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

Сообщение от ShaggyDoc Да и зачем все это непрерывно править? Это никогда к хорошим результатом не приводило.

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

Сообщение от ShaggyDoc А правильный путь известен - периодическое обновление по инициативе администратора.

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

  <!--Каталоги, которые необходимо синхронизировать между собой.-->
  <Synchronization SendRegistrationInfo="true" SynchronizeWithServer="true" SendSynchronizationInfo="true" StartingLoader="true">
    <!--Каталог, в котором содержится информация, специфичная для конкретной версии AutoCAD-->
    <SynchDir>
      <!--Каталог-источник-->
      <SourceDir>%GPSM.ServerDir%\%GPSM.AcadDirName%\etc</SourceDir>
      <!--Целевой каталог-->
      <TargetDir>%GPSM.LocalCommonDir%\%GPSM.AcadDirName%\etc</TargetDir>
    </SynchDir>
    <!--Каталог, в котором содержится информация, используемая в любой версии AutoCAD-->
    <SynchDir>
      Каталог-источник
      <SourceDir>%GPSM.ServerDir%\Common</SourceDir>
      Целевой каталог
      <TargetDir>%GPSM.LocalCommonDir%\Common</TargetDir>
    </SynchDir>   
  </Synchronization>

В приведённом выше фрагменте, если атрибуту SynchronizeWithServer назначить значение false - синхронизация не будет производиться.

Сообщение от ShaggyDoc 2. Зачем при синхронизации сверять хэши? Да просто заменяйте файлы (можно только обновленные). Разумеется те, которые юзерам запрещено изменять.

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

Сообщение от ShaggyDoc 3. Зачем столько файлов шрифтов и штриховок? Шрифтов - 334 шт! Штриховок - 677 шт! Кому столько надо? Да не более 5 шрифтов достаточно, чтобы обеспечить "полную демократию". А кому нужны столько штриховок? Вот у меня в ruCAD все мыслимые (предусмотренные стандартами) штриховки, включая топографию, занимают 39 кб в одном файле и он не пополнялся уже лет 10. То же, наверное, и с другими библиотечными элементами...

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

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

Сообщение от Дима_ Вариант второй - пользователь вначале грузит только для чтения xml (БД? - не суть) - где расписаны сетевые пути файлов настроек и в соответствии с ним идет конфигурация автокада - надо поменять - сделал новый каталог - переправил xml, а через недельку старый стер. Тогда и репризиторий не нужен.

По сути у меня так и сделано - в xml-файле можно изменить путь, указав иной каталог репозитория, но в этом случае не решаются проблемы из пунктов 2,3 и 4.

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

Такой подход однозначно на несколько порядков увеличит скорость синхронизации. Нужно посмотреть сколько времени уйдёт на распаковку - это самое узкое место в данном подходе...

Сейчас буду пробовать. Всем спасибо за идеи и замечания!

[gomer]

Посмотрите на это со стороны юзера: сегодня у меня команда работает так, завтра иначе, послезавтра вообще не работает... какая синхронизация??? Выложить дистрибутив на сервере, пусть обновляется кто хочет... а кому не надо... тому оно и не надо... чем меньше файлов на диске тем быстее работает антивирус
У каждого свои потребности и свои наработки...
Например, мне очень не нравится, что некоторые програмы вставляют в мой чертеж, без моего ведома, мусор, то бишь, слои, блоки и т.д. "шоб було" вместе с этим не имеют порой нормального обработчика ошибок...
На крайний случай, можно на панели задач выводить хинт, что доступно обновление... пусть юзер зайдет на сервер сам и обновится, если хочет...
можно сделать и систему проверки обновлений, как во всех современных программах... можно сделать систему автоматического обновления... но тогда нужно подумать о возможности откатов...
Вообще не понимаю, что такое администратор САД??? Вот Администратор сети - понимаю, а САД не понимаю... Да юзеру о вас 100 лет не знать и он будет работать... Он и в голом акаде будет работать... А если все работа будет двумя кнопками делаться, то он и вовсе себя не нужным почувствует и обозлится на вас... И даже если что работет не так, не всегда юзер вам скажет... так как это его козырь в рукаве...
Обеспечьте преемственность версий и пусть каждый работает в понравившейся... ИМХО

[Vildar]

Сообщение от ShaggyDoc Решение размещать все локально - правильное. Я давно к нему пришел.

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

Добавлено
Интересуют файлы: шаблонов dwt, стандарта dst, подшивки dst, палитр инструментов atc, плоттеров pc3 + pmp, стилей печати ctb + stb, блоки для палитр инструментов, типы линий lin и их форм shx.
Вот эти файлы настроек, сильно хочется хранить на сервере, и прописать в профиле акада к ним пути. Так проще будет контролировать их, вносить изменения.
При локальном хранении - придется обегать всех пользователей и проверять/обновлять.

Про расположение своих dll, склоняюсь к локальной загрузке их в акад, и организации обновления с сервера. Детальной реализации нет.
Эта тема убеждает поступить именно так. Спасибо Андрею )

[Дима_]

Сообщение от hwd Нужно посмотреть сколько времени уйдёт на распаковку - это самое узкое место в данном подходе...

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

[hwd]

>gomer
В рамках организации существует "Стандарт по работе с AutoCAD". Администратор CAD формирует серверный репозиторий так, чтобы он был заточен под максимально удобную работу в соответствии с требованиями указанного документа. Плодить версии - имхо не есть хорошо. Решение об обновлении принимает администратор CAD. Если такое решение принято - оно будет выполнено сразу для всех пользователей. "Мусора" (с) в чертежах не будет, т.к. они просто обязаны создаваться в соответствии с требованиями обозначенного выше стандарта.
На сервере существует HelpDesk, на который пользователи могут отправлять замечания/пожелания по работе GPSM.CAD.

Демократии не будет.
Если бы была возможность запретить пользователю загрузку плагинов не из репозитория - я бы и это сделал. Хотите использовать в своей работе стороннюю библиотеку? Через браузер оставьте заявку в HelpDesk (размещён на сервере) о том, что есть такой-то полезный модуль, делает то и то. Администратор CAD просмотрит этот модуль, сообщит о вашем предложении группе наиболее продвинутых пользователей (являющихся своего рода назначенной комиссией) и если те согласятся, что модуль действительно интересен - он будет добавлен в серверный репозиторий и станет доступным сразу для всех пользователей. Параллельно будет добавлена информация в справку по GPSM.CAD о добавленном модуле и его функционале.

DotNet программистам: если кого интересует тема упаковки/распаковки - здесь выложена интересная библиотека. В архиве имеется и файл справки, в котором определены разделы C# и VB.NET с подробными примерами кода.
Очень удобная штука (имхо).

[CB]

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

Это скорее всего правильно.

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

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

[hwd]

Сообщение от CB Почему бы в автозагрузку не поставить прогу, которая обновляла с сервера на локальном компьютере репозиторий только при загрузке/перезагрузке компа...

Думал над таким вариантом - не понравился. Предположим добавили в репозиторий библиотеку, разослали по почте сообщение, в котором предлагается опробовать её в работе. Пользователи начали пробовать, обнаружили ошибку, сообщили об этом админу CAD. Тот вытащил "кривую софтину" из репозитория. Юзер работает в той же сессии в автокаде и может продолжать испытывать последствия тестированной библиотеки. Причём чтобы она более не мешала - её нужно выгрузить. Что проще, перезапустить автокад, или перезапустить перемещаемый профиль пользователя windows? имхо гораздо проще перегрузить автокад.

[gomer]

Сообщение от hwd Демократии не будет.

А если мне не нужна в данный момент какая-то библиотека? или часть библиотек? Кто-то делает КМ, кто-то КМД, КЖ, АС... ЗАчем обновляться если все и так работает хорошо... Стандарты стандартами... это должно быть глубже... а каие библиотеки мне загружать я хочу решать сам...хоть с локальной, хоть с сетевой машины...

[hwd]

Сообщение от gomer А если мне не нужна в данный момент какая-то библиотека? или часть библиотек? Кто-то делает КМ, кто-то КМД, КЖ, АС... ЗАчем обновляться если все и так работает хорошо... Стандарты стандартами... это должно быть глубже... а каие библиотеки мне загружать я хочу решать сам...хоть с локальной, хоть с сетевой машины...

Есть несколько конфигурационных файлов:
1. общий конфигурационный файл.
2. конфигурационный файл конкретной доменной группы.
3. конфигурационный файл конкретного пользователя.

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

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

файл (2) может править руководитель этой группы.

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

Сообщение от CB Почему бы в автозагрузку не поставить прогу, которая обновляла с сервера на локальном компьютере репозиторий только при загрузке/перезагрузке компа...

Именно так я и поступил. И кроме того вывел на рабочий стол ярлык на эту прогу (точнее она сама создает ярлык на рабочем столе на саму себя при первом запуске). Так что теперь достаточно выйти из AutoCAD, клацнуть по ярлыку и готово.

[Vildar]

gomer,
В хорошей органицации максимум выполняемой работы должно быть формализовано. Т.е. по пунктам расписано, что нужно сделать при данной конкретной задаче.
Так же и работа в автокаде.
Чтобы не было, такого, что Вася заболел, а Петя не может понять, как выполнены его чертежи, и не может доделать их.
И начинается формализация работы в акаде, с принятия Стандарта работы в нем на предприятии.

[hwd]

Сообщение от Александр Ривилис Именно так я и поступил. И кроме того вывел на рабочий стол ярлык на эту прогу (точнее она сама создает ярлык на рабочем столе на саму себя при первом запуске). Так что теперь достаточно выйти из AutoCAD, клацнуть по ярлыку и готово.

Я указал, почему этот вариант мне не нравится.
Ещё ситуация:
работает за компьютером бабулька. Клацнула ваш ярлык обновления и затем клацнула ярлык автокада. Одно приложение синхронизирует данные с сервером, а другое, в это же время грузит данные в AutoCAD. Если синхронизатор не успеет сделать своё дело до того, как автокад начнёт грузить плагины, мы с большой долей вероятости получим Exception, когда синхронизатор попытается перезаписать библиотеку, уже загруженную в AutoCAD.

[gomer]

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

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