Статус: Сотрудник
Группы: Участники
Зарегистрирован: 26.07.2011(UTC) Сообщений: 12,691 Сказал «Спасибо»: 500 раз Поблагодарили: 2044 раз в 1585 постах
|
// тот же файл описания, но расширение другое, для отправителя (клиент с linux в примере). |
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз Поблагодарили: 394 раз в 366 постах
|
Андрей, ну что Вы мне рассказываете )))) Работает конечно, но какой процент лишних телодвижений во всем этом? PHP скрипт может генерировать описание xml\json на лету в памяти без медленных файловых операций и соответственно мелкий временный файл описания также можно поймать в память в стороне клиента. Как бы незачем его писать на диск.
У меня самого программа синхронизации надцать лет была написана по такому принципу: был файл со списком файлов в папке и их характеристик (crc32 в том числе) и был "файл блокировки" списка (просто пустой). пока он есть другой экземпляр программы синхронизации файл со списком не трогал. Понятно что по разным причинам частенько все крашилось и файл блокировки оставался. Потому программа еще и его дату время создания сравнивала с текущей датой временем - если больше некого предела предыдущая сессия считалась "погибшей на боевом посту" и файл блокировки удалялся и создавался заново.
C NTFS это стало сложнее, так как эта система еще и кэширует файловые атрибуты на какое-то время, то есть переместил файл на другой диск - он типа удалился, переместил обратно через минуту - вуаля, у файла старое время создания, кэш минуту продержался и героически восстановил время. А я сижу и тихо матерюсь, так как перемещал как раз чтобы время создания изменилось. Значит надо либо ждать либо явно поменять время.
В этом году переписал программку для СМЭВ на уведомления нтфс, но "боевого теста" пока не было, терзают сомнения.
Для одиночного файла все работает годами и прекрасно. Но... уже ощущается почти как работа с мсдос. Больше всего меня удивляет в описанном то, что указываете про хэш и xml\json - так и просится http для связки с ними. http работает по TCP, то есть там уже встроен контроль правильности пакетов, зачем хэш; если считаем хэш, то почему не посчитать по гост-2012 256, тогда нам и файл не нужен; есть события по завершению http - не надо думать как просканировать папку или отфильтровать лишнее, придет событие именно файла который загружаешь.
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 26.07.2011(UTC) Сообщений: 12,691 Сказал «Спасибо»: 500 раз Поблагодарили: 2044 раз в 1585 постах
|
Автор: two_oceans Андрей, ну что Вы мне рассказываете )))) Работает конечно, но какой процент лишних телодвижений во всем этом? PHP скрипт может генерировать описание xml\json на лету в памяти без медленных файловых операций и соответственно мелкий временный файл описания также можно поймать в память в стороне клиента. Как бы незачем его писать на диск.
У меня самого программа синхронизации надцать лет была написана по такому принципу: был файл со списком файлов в папке и их характеристик (crc32 в том числе) и был "файл блокировки" списка (просто пустой). пока он есть другой экземпляр программы синхронизации файл со списком не трогал. Понятно что по разным причинам частенько все крашилось и файл блокировки оставался. Потому программа еще и его дату время создания сравнивала с текущей датой временем - если больше некого предела предыдущая сессия считалась "погибшей на боевом посту" и файл блокировки удалялся и создавался заново.
C NTFS это стало сложнее, так как эта система еще и кэширует файловые атрибуты на какое-то время, то есть переместил файл на другой диск - он типа удалился, переместил обратно через минуту - вуаля, у файла старое время создания, кэш минуту продержался и героически восстановил время. А я сижу и тихо матерюсь, так как перемещал как раз чтобы время создания изменилось. Значит надо либо ждать либо явно поменять время.
В этом году переписал программку для СМЭВ на уведомления нтфс, но "боевого теста" пока не было, терзают сомнения.
Для одиночного файла все работает годами и прекрасно. Но... уже ощущается почти как работа с мсдос. Больше всего меня удивляет в описанном то, что указываете про хэш и xml\json - так и просится http для связки с ними. http работает по TCP, то есть там уже встроен контроль правильности пакетов, зачем хэш; если считаем хэш, то почему не посчитать по гост-2012 256, тогда нам и файл не нужен; есть события по завершению http - не надо думать как просканировать папку или отфильтровать лишнее, придет событие именно файла который загружаешь.
1. Где в моих сообщения есть упоминание про хеш? 2. Я предлагаю варианты на выбор и web-сервис был: Web сервис или утилита 3. Некоторым программистам проще записать в файл\прочитать ответ (разработчики ИС\1С), чем изучать WebAPI какого-то сервиса. У каждого подхода свои возможности\ограничения. Косвенный пример: вместо использования phpcades вызывают утилиты, порождая дальнейшие вопросы (как получить время подписания из ЭП?) |
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз Поблагодарили: 394 раз в 366 постах
|
Автор: Андрей * 1. Где в моих сообщения есть упоминание про хеш? Автор: Андрей * Записывается его описание (небольшой файл, xml\json, в котором перечислены доп данные (номер\дата\сумма) Вероятно, я тогда не до конца понял и домыслил. Самые простые хэши md4, md5, sha1 среды программирования считать умеют сразу, а где не умеют, там есть модули, есть реализации для JavaScript и php. Соответственно вместо "длинных" контрольных сумм повсеместно используют хэши, сейчас уже фактически в смысловом поле сравнялись понятия "[контрольная] сумма" и "значение хэш-функции". С той же CRС суммой я недавно заинтересовался и обнаружил, что это "семейство" функций и совершенно не обязательно брать определенные константы. Исходник на Си CRC32 нашелся, а на паскале не повезло. В итоге пришел к выводу, что для моей цели в аналогичной программе хэш sha1 от файла посчитать на Microsoft CryptoApi будет быстрее и надежнее чем реализовать CRC32 или таскать с программой Zlib.dll. Про подходы и ограничения согласен - люди разные, кому как кажется удобнее. В месте с тем не могу не отметить, что функциональность плагина в нескольких местах ограничена и оставляет желать лучшего. Навскидку припомню, что были проблемы: поддержка не всех вариантов регулировки включения цепочки сертификатов (не включать/включить конечный/включать кроме корневого/включать все); некоторых полей отсутствовавших в Cadescom, но бывших в Capicom, в частности просмотра содержимого расширений сертификата и т.д. Вроде как сделать их не так и сложно (формат сертификата и общий формат расширений известен - оид, признак критичности, значение). По крайней мере, хотелось бы увидеть их для стандартных расширений сертификата, использующихся в гост-сертификатах (в одном сертификате видел вместе десяток расширений, порознь наберется десятка полтора). На Windows можно было открыть тот же сертификата через CAPICOM и посмотреть чего нужно, но вот с phpcades вряд ли так получится. Поправьте меня, если в этом плане произошли какие-то улучшения за 5 лет.
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 26.07.2011(UTC) Сообщений: 12,691 Сказал «Спасибо»: 500 раз Поблагодарили: 2044 раз в 1585 постах
|
Автор: two_oceans Автор: Андрей * 1. Где в моих сообщения есть упоминание про хеш? Автор: Андрей * Записывается его описание (небольшой файл, xml\json, в котором перечислены доп данные (номер\дата\сумма) Вероятно, я тогда не до конца понял и домыслил. Самые простые хэши md4, md5, sha1 среды программирования считать умеют сразу, а где не умеют, там есть модули, есть реализации для JavaScript и php. Соответственно вместо "длинных" контрольных сумм повсеместно используют хэши, сейчас уже фактически в смысловом поле сравнялись понятия "[контрольная] сумма" и "значение хэш-функции". С той же CRС суммой я недавно заинтересовался и обнаружил, что это "семейство" функций и совершенно не обязательно брать определенные константы. Исходник на Си CRC32 нашелся, а на паскале не повезло. В итоге пришел к выводу, что для моей цели в аналогичной программе хэш sha1 от файла посчитать на Microsoft CryptoApi будет быстрее и надежнее чем реализовать CRC32 или таскать с программой Zlib.dll. нет.. всё проще и о другом... номер\дата\ сумма - сумма в контексте с номером и датой документа... сумма = деньги), а не хеш. // p.s. речь в примере про файловые АРМ, в интеграциях с операторами ЭДО... отправляется документ № ххх от хххх на сумму ххххх... |
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close