Да, пожалуй, так и сделаю.

Вот как я анализировал пакеты, посылаемые АРМ «Каталогизатор» на сервер:

1. Скачал и установил WireShark, установил в нём фильтр "tcp.port == 6666", чтобы отсечь лишний трафик.

2. Захват пакетов включал непосредственно перед изучаемой операцией, например, сохранением записи, иначе придётся продираться через огромное число пакетов, не относящихся к делу.

3. Отыскивал нужный пакет (в данном случае "D" - сохранение записи). Видно, что в нём 1156 байт данных, из них 4 - длина пакета и перевод строки \x0A.



4. Для более удобного изучения экспортировал данные в двоичный файл irbis.bin, который открыл в мощном редакторе 010 Editor (он мне нравится тем, что мощно работает с кодировками, включая UTF, даже в двоичных файлах).

5. Служебные байты подсветил салатным цветом, так что стали видны переводы строки (в том числе "ирбисовские").




Таким образом, стало ясно, что пакет типа "D" выглядит следующим образом:

1151     - длина пакета. Дальше все переводы строки только \x0A
D        - команда
C        - код АРМ "Каталогизатор"
D        - повторение команды
974677   - идентификатор клиента
84       - номер команды
1        - пароль
1        - логин
         - пустая строка
         - пустая строка
         - пустая строка. Конец обязательного заголовка
IBIS     - имя базы данных
0        - признак (не)блокировки записи
1        - признак актуализации
328#0    - MFN и статус. Дальше все переводы строки только \x1F \x1E
0#2      - 0 и версия записи
920#PAZK - начало полей записи
...
330#Ещё примечание - последнее поле (добавленное мной, 
                     чтобы вынудить АРМ произвести запись).
                     Строка заканчивается парой \x1F \x1E

Редактировано 1 раз. Последний раз 06.01.2015 16:55 пользователем amironov73.

Ответ сервера на запрос "D" состоит из 1184 байт:

D        - команда клиента.Дальше все переводы строки только \x0D \x0A
974677   - идентификатор клиента
84       - номер команды
1126     - судя по всему, размер данных
         - пустая строка
         - пустая строка
         - пустая строка
         - пустая строка
         - пустая строка
         - пустая строка
329      - новый максимальный MFN
328#40   - MFN и статус, похоже, почти всегда "40"
0#2      - 0 и номер версии. Дальше все переводы строки только \x1E
920#PAZK - начало полей записи
...
905#^S1^21^D3 - последнее поле в записи, завершается \x0D \x0A

Редактировано 1 раз. Последний раз 06.01.2015 17:17 пользователем amironov73.

Спасибо за подсказку. Очень здорово. О почему в ответе сервера номер версии записи такой же, как и в пакете клиента? Разве после сохранения версия записи не должна быть увеличена на 1?

Попробую пропустить трафик через этот "шпион".

artgonch написал(а):
-------------------------------------------------------
> Спасибо за подсказку. Очень здорово. О почему в
> ответе сервера номер версии записи такой же, как и
> в пакете клиента? Разве после сохранения версия
> записи не должна быть увеличена на 1?

Я сам озадачен...

Сервер ИРБИС64 – источник загадок почище Бермудского треугольника.

Кажется, пакет для отправки на сервер сформирован корректно. Вы не взгляните? Он во вложении.

amironov73 написал(а):
-------------------------------------------------------
> artgonch написал(а):
> --------------------------------------------------
> -----
> > Спасибо за подсказку. Очень здорово. О почему в
> > ответе сервера номер версии записи такой же, как
> и
> > в пакете клиента? Разве после сохранения версия
> > записи не должна быть увеличена на 1?
>
> Я сам озадачен...
>
> Сервер ИРБИС64 – источник загадок почище
> Бермудского треугольника.

artgonch написал(а):
-------------------------------------------------------
> Кажется, пакет для отправки на сервер сформирован
> корректно. Вы не взгляните? Он во вложении.

Не уверен, насколько это важно для сервера, но в Вашем пакете поля в записи разделяются парой символов \x1E \x1F, в то время как стандартный клиент (и ManagedClient) применяют \x1F \x1E.

Вот (частичный) дамп АРМ "Каталогизатор":



Вот дамп Вашего клиента:



Больше не нашёл, к чему придраться.



Редактировано 1 раз. Последний раз 07.01.2015 10:10 пользователем amironov73.

Опять мы имеем ситуацию, когда документация содержит сведения, прямо противоположные действительности. В документации сказано:

MFN#STATUS#30#310#VERSION#30#31TAG1#FIELD1#30#31 … TAG1#FIELD1#30#31

В то время как стандартные клиенты шлют:

MFN#STATUS#31#300#VERSION#31#30TAG1#FIELD1#31#30 … TAG1#FIELD1#31#30

amironov73 написал(а):
-------------------------------------------------------
> Опять мы имеем ситуацию, когда документация
> содержит сведения, прямо противоположные
> действительности. В документации сказано:
>
> MFN#STATUS#30#310#VERSION#30#31TAG1#FIELD1#30#31 …
> TAG1#FIELD1#30#31
>
> В то время как стандартные клиенты шлют:
>
> MFN#STATUS#31#300#VERSION#31#30TAG1#FIELD1#31#30 …
> TAG1#FIELD1#31#30

Получилось! Большое спасибо. Вообще, это странно. В такой ситуации правильнее было бы возвращать код ошибки WRONG_PROTOCOL, а не ошибку версии записи.

artgonch написал(а):
-------------------------------------------------------
> Получилось! Большое спасибо. Вообще, это странно.
> В такой ситуации правильнее было бы возвращать код
> ошибки WRONG_PROTOCOL, а не ошибку версии записи.

Вообще, коды ошибок ИРБИС64 и логика, согласно которой они применяются, напоминают мне китайскую классификацию собак. Согласно этой классификации, собаки делятся на:

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





Редактировано 1 раз. Последний раз 07.01.2015 16:16 пользователем amironov73.

Забавно. Но почему разработчики до сих пор не привели в божеский вид выдаваемые сервером коды ошибок? Ведь это не так уж и сложно...

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

А вот теперь я бьюсь над форматированием записи. Когда я вызываю, например, формат @brief, то все хорошо. Но вот я, например, хочу вывести все сведения об экз-рах. Для этого я в свой метод чтения записи передаю (v910^b/) и получаю подполе ^B только из первого повторения, а их в записи штук 5.

artgonch написал(а):
-------------------------------------------------------
> Забавно. Но почему разработчики до сих пор не
> привели в божеский вид выдаваемые сервером коды
> ошибок? Ведь это не так уж и сложно...

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

Возможно, Вы просто не в курсе, однако, кроме официальных, существует ещё множество клиентов от разработчиков-партнёров или членов ЭБНИТ (например, киосков самообслуживания, RFID-систем и корпоративных систем каталогизации). Радикальная переработка протокола вряд ли их (партнёров ЭБНИТ) обрадует.

Так что, как говорится, что выросло, то выросло.

> И таки да. Я читаю заново статус записи и вижу,
> что она якобы неактуализирована, хотя в
> Администраторе нет ни одной неактуализированной
> записи.

А это ещё одно неприятное открытие: в ИРБИС64 существует две копии статусов записи. Одна копия статуса хранится в XRF, вторая – в MST, и они не всегда согласованы друг с другом, как я убедился, пытаясь научиться читать файл документов напрямую (некоторые результаты этих экспериментов вошли в библиотеку).

> А вот теперь я бьюсь над форматированием записи.
> Когда я вызываю, например, формат @brief, то все
> хорошо. Но вот я, например, хочу вывести все
> сведения об экз-рах. Для этого я в свой метод
> чтения записи передаю (v910^b/) и получаю подполе
> ^B только из первого повторения, а их в записи
> штук 5.

Т. е. Вы пытаетесь воспользоваться запросом "C" для форматирования? Я никогда так не делал, так что даже не знаю, что подсказать. Я всегда пользовался для форматирования запросом "G", и он срабатывал превосходно для любых форматов, кроме "@", но это отдельный разговор.

amironov73 написал(а):
-------------------------------------------------------
> artgonch написал(а):
> --------------------------------------------------
> -----
> > Забавно. Но почему разработчики до сих пор не
> > привели в божеский вид выдаваемые сервером коды
> > ошибок? Ведь это не так уж и сложно...
>
> Переделывать протокол радикально уже поздно, а по
> мелочам он ежегодно дорабатывается.
>
> Возможно, Вы просто не в курсе, однако, кроме
> официальных, существует ещё множество клиентов от
> разработчиков-партнёров или членов ЭБНИТ
> (например, киосков самообслуживания, RFID-систем и
> корпоративных систем каталогизации). Радикальная
> переработка протокола вряд ли их (партнёров ЭБНИТ)
> обрадует.
>
> Так что, как говорится, что выросло, то выросло.
>
> > И таки да. Я читаю заново статус записи и вижу,
> > что она якобы неактуализирована, хотя в
> > Администраторе нет ни одной неактуализированной
> > записи.
>
> А это ещё одно неприятное открытие: в ИРБИС64
> существует две копии статусов записи. Одна копия
> статуса хранится в XRF, вторая – в MST, и они не
> всегда согласованы друг с другом, как я убедился,
> пытаясь научиться читать файл документов напрямую
> (некоторые результаты этих экспериментов вошли в
> библиотеку).
>
> > А вот теперь я бьюсь над форматированием
> записи.
> > Когда я вызываю, например, формат @brief, то
> все
> > хорошо. Но вот я, например, хочу вывести все
> > сведения об экз-рах. Для этого я в свой метод
> > чтения записи передаю (v910^b/) и получаю
> подполе
> > ^B только из первого повторения, а их в записи
> > штук 5.
>
> Т. е. Вы пытаетесь воспользоваться запросом "C"
> для форматирования? Я никогда так не делал, так
> что даже не знаю, что подсказать. Я всегда
> пользовался для форматирования запросом "G", и он
> срабатывал превосходно для любых форматов, кроме
> "@", но это отдельный разговор.

Вот я смотрю описание команды G. Как понимать такой комментарий?
Возврат функции форматирования одной записи не определен.

artgonch написал(а):
-------------------------------------------------------
> Вот я смотрю описание команды G. Как понимать
> такой комментарий?
> Возврат функции форматирования одной записи не
> определен.

Я это понял так, что если с форматированием какой-либо записи «не задалось» (например, MFN за пределами базы или неверный вызов &unifor), то общий код возврата всё равно будет "0", и клиент должен сам догадаться, что пошло не так.

По моему опыту, возвращается такой ответ (в предположении, что мы запросили формат (v907^b/)):

0 - общий код возврата "Всё хорошо, прекрасная маркиза!"
22#100500\x1F\1E100501\x1F\1E100502 - переводы строки заменены на ирбисовские
23#ERROR - "С этой записью что-то не так, но что именно, мы вам не скажем!"
24#200500\x1F\1E200501\x1F\1E200502 - тут опять всё нормально

Ситуация становится особо пикантной, если в Вашем формате штатно предусмотрена выдача строки "ERROR", например, в результате анализа записи.

amironov73 написал(а):
-------------------------------------------------------
> artgonch написал(а):
> --------------------------------------------------
> -----
> > Вот я смотрю описание команды G. Как понимать
> > такой комментарий?
> > Возврат функции форматирования одной записи не
> > определен.
>
> Я это понял так, что если с форматированием
> какой-либо записи «не задалось» (например, MFN за
> пределами базы или неверный вызов &unifor), то
> общий код возврата всё равно будет "0", и клиент
> должен сам догадаться, что пошло не так.
>
> По моему опыту, возвращается такой ответ (в
> предположении, что мы запросили формат
> (v907^b/)):
>
> 0 - общий код возврата "Всё хорошо, прекрасная
> маркиза!"
> 22#100500\x1F\1E100501\x1F\1E100502 - переводы
> строки заменены на ирбисовские
> 23#ERROR - "С этой записью что-то не так, но что
> именно, мы вам не скажем!"
> 24#200500\x1F\1E200501\x1F\1E200502 - тут опять
> всё нормально
>
> Ситуация становится особо пикантной, если в Вашем
> формате штатно предусмотрена выдача строки
> "ERROR", например, в результате анализа записи.
>


Ну это мне пока не так важно. Главное, что с помощью команды G можно и одну запись форматировать. Я прав?

artgonch написал(а):
-------------------------------------------------------
> Ну это мне пока не так важно. Главное, что с
> помощью команды G можно и одну запись
> форматировать. Я прав?

Одну запись расформатировать – можно. Ноль – нельзя (не приходит ответа от сервера, судя по всему, рабочий процесс зависает).

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

artgonch написал(а):
-------------------------------------------------------
> Вот теперь получилось. Правда, описание команды G
> для форматирования одной записи отличается от
> примера протокола...

Чем (кроме того, что традиционно перепутаны местами пароль с логином и не упомянута возвращаемая длина ответа)?

> Неужели разработчики не обновляют документ?

А зачем?

Вот теперь хочу выполнить поиск с форматированием записей (команда K). Ищу, например, по выражению "NKSU=2014/457". Формат задаю простой, например, v60. Все отлично: поиск срабатывает.

Но вот я хочу форматировать записи по такому формату (в редакторе форматов все корректно, ошибок нет):

/* Counter
(if p(v910) then if v910^u='2014/457' and v910^d='Ф3' then &uf('S1'),&uf('SA') fi fi/), '{[!]}'/
/* Inventar
(if p(v910) then if v910^u='2014/457' and v910^d='Ф3' then if p(v910^b) then v910^b else v910^h fi fi fi/), '{[!]}'/
/* Avtor
v461^x| |,v461^c,"; "v200^v,if p(v200^v) then": "d200^a fi,v700^a," "v700^b," "d700,v200^a,
         if p(v215^a) then". -"v215^a,v215^1,
            if a(v215^1) then &unifor('Korg.mnu|4')'.'
fi fi/ '{[!]}'/
/* God
(if p(v910) then if v910^u='2014/457' and v910^d='Ф3' then v910^u.4 fi fi/), '{[!]}'/
/* Razdel
v60/ '{[!]}'/
/* Cena
(if p(v910) then if v910^u='2014/457' and v910^d='Ф3' then if p(v910^e) then v910^e else &uf('Av10^D#1') fi fi fi/)

Статус операции 0, но найдено 0 записей (а в первом случае по такому же поисковому выражению результат больше 70).

Или сервер, в отличие от редактора форматов, не понимает комментарии?

artgonch написал(а):
-------------------------------------------------------
> Или сервер, в отличие от редактора форматов, не
> понимает комментарии?

Он понимает комментарии в форматах, хранящихся в файлах на сервере.

В динамических же форматах, передаваемых с командой K, не должно быть:

1. Комментариев вообще.
2. Переводов строки \n, \r\n.
3. Переводов строки \x1F\x1E.

Замените их на пробел.

amironov73 написал(а):
-------------------------------------------------------
> artgonch написал(а):
> --------------------------------------------------
> -----
> > Или сервер, в отличие от редактора форматов, не
> > понимает комментарии?
>
> Он понимает комментарии в форматах, хранящихся в
> файлах на сервере.
>
> В динамических же форматах, передаваемых с
> командой K, не должно быть:
>
> 1. Комментариев вообще.
> 2. Переводов строки \n, \r\n.
> 3. Переводов строки \x1F\x1E.
>
> Замените их на пробел.


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

Здравствуйте! У меня есть пара вопросов, поможете?

1. Заметил, что метод GetAllReaders() в ReaderManager делает Client.GetMaxMfn() + 1.
При этом он же добавляет пустую запись в массив.
Для чего так? Или я чего-то не знаю?

2. Пытаюсь собрать статистику посещаемости. Складываю уникальные даты выдачи по отделам для каждого читателя и посещения поставленные вручную.
Но у Ирбиса в стат. формах другие данные (процентов на 20 больше).
Что я делаю не так?

Barkoff написал(а):
-------------------------------------------------------
> 1. Заметил, что метод GetAllReaders() в
> ReaderManager делает Client.GetMaxMfn() + 1.
> При этом он же добавляет пустую запись в массив.
> Для чего так? Или я чего-то не знаю?

Конструктор new List<T> (int) задаёт начальную ёмкость списка (см. MSDN), чтобы избежать ненужных перераспределений памяти при дальнейшем наполнении списка. Лишних элементов в результирующем массиве, получаемом вызовом .ToArray(), от этого не возникает.

"+1" остался в библиотеке с тех времён, когда GetMaxMfn() мог возвращать -1. Добавление +1 спасало от ArgumentOutOfRangeException в конструкторе new List<T> (int).

В настоящее время "+1" не нужен, спасибо!

> 2. Пытаюсь собрать статистику посещаемости.
> Складываю уникальные даты выдачи по отделам для
> каждого читателя и посещения поставленные
> вручную.
> Но у Ирбиса в стат. формах другие данные
> (процентов на 20 больше).
> Что я делаю не так?

Не знаю, что ответить.

Доброго Времени Суток! :) Начальство поставило задачу скомпилировать простое приложение перед приобретением irbis, с первой страницы темы скопировал пример, ругается на директиву using ManagedClient; что с этим делать?
Использую microsoft visual studio ultimate 2013

Нужно добавить в проект ссылку на библиотеку ManagedClient: [yadi.sk]

а это внешняя библиотека? в среде что то не нашел ее

ADV написал(а):
-------------------------------------------------------
> а это внешняя библиотека? в среде что то не нашел ее

Вы скачали архив, прилагающийся к первому сообщению данной темы? Если нет, скачайте.

Архив с библиотекой ManagedClient можно скачать также с хостинга Assembla (бесплатно): https://www.assembla.com/spaces/arsmagna/documents. Регистрация на хостинге не требуется. Если сайт запросит логин/пароль, можно отказаться, на возможности скачивать файлы это не сказывается.

Всё необходимое для работы с библиотекой ManagedClient находится в упомянутом архиве, в том числе исходные тексты библиотеки и её откомпилированный вариант для Microsoft .NET Framework 3.5.

Также в архиве есть проект тестового приложения, который Вы можете открыть своей Visual Studio и изучить.

Спасибо Заработало :) на первой странице перекидывает в корень форума

ADV написал(а):
-------------------------------------------------------
> Спасибо Заработало :) на первой странице
> перекидывает в корень форума

А это уже вопрос к администрации форума, зачем они поломали прикреплённые файлы

Здравствуйте! Я пытаюсь смастерить ASP.NET MVC приложение, а так как я в этом деле не шибко ядрёный специалист, столкнулся с массой трудностей. Совсем запутался.
Подскажите в какую сторону следует копать?
Я вижу несколько вариантов:
- Если Библиотека остаётся такой какая она есть, то как будет выглядеть Модель?
- Переносим некоторые классы из библиотеки в Модель приложения, например: ReaderInfo, ExemplarInfo. Тогда прикрутить какой-нибудь ORM не вижу возможным.
- Можно и не использовать Модель, Не менять ничего в библиотеке, просто передавать данные из Контроллера в Представление.

Извиняюсь за сумбурную формулировку.