Запитання та відповіді

Електронна черга Q-net призначена для автоматизації процесу обслуговування відвідувачів. Система управління чергою управляє всім процесом прийому відвідувача: від моменту постановки в чергу до моменту обслуговування з усіх питань, що його зацікавили. Завдяки вбудованим алгоритмам, що оптимізують процес обслуговування та дозволяють зробити цей процес прозорим, час очікування прийому скорочується.
Деякі з недоліків «живої черги», які вирішує впровадження системи управління чергою:

  • відвідувачу не потрібно впізнавати, і запитувати у яке вікно зайняти чергу, за допомогою підказок меню сенсорного терміналу він сам вибере потрібне обслуговування;
  • не потрібно займати чергу в кілька вікон і бігати перевіряти чи не підійшла вона, система управління чергою відповідно до заданого алгоритму викличе відвідувача з одним і тим же номером талона в різні вікна в потрібній послідовності і при цьому ніколи не викличе одночасно в два вікна!
  • обслуговування стає повністю конфіденційним, всі питання вирішуються з оператором тет-а-тет;
  • якщо з'явиться потреба, відвідувач буде перенаправлений в іншу чергу, і при цьому не потрібно знову брати талон;
  • система електронної черги виключає конфлікти між відвідувачами та зводить їх до нуля, система справедливо розподілить потік запитів на обслуговування, і якщо передбачено пільговий прийом окремих категорій громадян – обслуговуватиме з певним пріоритетом;
  • список можна продовжувати…

Який папір використовується у електронних чергах Q-net? Чи обов'язково її купувати саме у вас?

В електронній черзі Q-net , На відміну від більшості зарубіжних аналогів, в терміналах для друку талонів використовується стандартний термопапір для касових апаратів, доступний в будь-якому канцелярському магазині. Також термопапір можна придбати і в нашій компанії.

Чи є ви самі виробниками систем управління чергою Q-net, чи ви її тільки перепродаєте?

Компанія «МТГ. Бізнес-рішення» є авторизованим дистриб'ютором компанії «SPB ltd.» (Угорщина) – виробником (повного циклу) систем управління чергою Q-net . Як авторизований дистриб'ютор, наша компанія ставить основною метою створення партнерської та сервісної мережі, технічної підтримки продукції під маркою Q-net . Таким чином, ми далеко виходимо за межі просто рітейлерів продукції.

Виходить, що електронна черга Q-net – це імпортне рішення. Напевно, вартість велика, і ми можемо не вкластися в бюджет?

Компанія-виробник "SPB ltd." розробила чотири варіанти систем управління чергою Q-net , які повністю задовольняють потреби замовників:

  • Q-net Basic – Найбільш бюджетна автономна система електронної черги з однією чергою;
  • Q-net Basic Plus – також бюджетна система електронної черги, але дозволяє використовувати до трьох черг;
  • Q-net Standard – ця система управління чергою підійде більшості замовників. Тут реалізовані всі стандартні функції і при цьому рішення є досить демократичним за вартістю;
  • Q-net Pro – має розширені можливості моніторингу та статистики, заснована на базі ПК та легко адаптується під потреби Замовників, дозволяючи змінювати налаштування в режимі реального часу. У ній вже реалізовано багато нестандартних функцій.У своєму роді це конструктор, з якого можна зробити свою унікальну систему!

Таким чином, будь-який замовник зможе вибрати для себе систему управління чергою згідно з вимогами та розміром бюджету. Зверніться до наших менеджерів, і вони підберуть для Вас найбільш оптимальне за співвідношенням ціна-якість рішення.

Якщо Q-net – європейська система, то вона вся англійською мовою і не адаптована під російську специфіку?

Системи Q-net Standard і Q-net Pro повністю перекладені російською мовою: сама програма, вибір мови обслуговування, посібники користувачів та технічний опис.
Завдяки тому, що система дозволяє запрограмувати мову обслуговування, Ваші відвідувачі не мають проблем мовного бар'єру. Якщо вибрано ту чи іншу мову система направить відвідувача до оператора, який володіє цією мовою (цей момент враховується і при перенаправленні в інше вікно або до іншого оператора).

Нам необхідно інтегрувати електронну чергу зі своєю внутрішньою інформаційною системою (внутрішнім документообігом, системою підрахунку відвідувачів, CRM, ERP тощо). Чи це можливо?

Система керування чергою Q-net Pro має розвинені можливості налаштування під вимоги до функціоналу. Заснована на базі ПК архітектура дозволяє легко доопрацьовувати та інтегрувати програмне забезпечення з інформаційними системами Замовника.

Чи не знайшов прайс-лист у вас на сайті. Як дізнатись ціну на електронні черги?

Система управління чергою є технічно складним програмно-апаратним проектним рішенням, і в усіх виробників будується з урахуванням різних архітектур. Тому ми не розміщуємо прайс-листи, т.к.існує безліч варіантів складання системи електронної черги, згідно з побажаннями Замовника, але ми завжди готові оперативно надати різні варіанти розрахунків на першу ж вимогу.

Чи потрібно відвідувачеві брати талон електронної черги, якщо немає черги?

У системах електронної черги Q-net існує можливість налаштування пульта оператора для автоматичного виклику відвідувача до першого вільного оператора. Як тільки відвідувач зареєструється в черзі, і отримає талон, він буде викликаний на обслуговування без будь-яких дій з боку оператора (особливий режим роботи пульта).

У нашій організації є безліч філій, і наше керівництво хотіло б бачити, як працює кожне відділення. Чи це можливо?

Нема проблем. Рішення Q-net Pro дозволяє аналізувати статистичні звіти не тільки по одному відділенню, але і відразу по кількох, при цьому адміністратор центрального офісу має можливість аналізувати статистику, як глобально по всій філії, так конкретно по кожному оператору, кожній послузі і навіть по конкретному інциденту (по талону черги ). Даний програмний комплекс надається у версії Pro БЕЗКОШТОВНО!

Запитання та відповіді - Druzhba

Сподіваюся, що довгоочікуване продовження циклу нотаток про операційну систему реального часу QNX. Цього разу я хотів би розповісти про Qnet — власний мережевий протокол QNX. Відразу уточню, що крім рідної мережі Qnet, у QNX підтримується стек протоколів TCP/IP, робота з яким загалом має бути знайома адміністраторам Unix-подібних систем. Тому в замітці спочатку трохи розповім про мережевого адміністратора io-pkt, а потім детальніше про протокол Qnet.У ході оповіді на нас також чекають чотири ліричні та один технічний відступ.

Що таке Qnet?

Мережа QNX є групою з'єднаних між собою цільових систем, кожна з яких працює під управлінням ОСРВ QNX Neutrino. У такій мережі будь-яка програма має доступ до будь-якого ресурсу на будь-якому вузлі (node, так називаються окремі комп'ютери в мережі). Як ресурс може виступати файл, пристрій або процес (у тому числі забезпечується і запуск процесів на іншому вузлі). При цьому цільові системи (ті самі вузли) можуть бути комп'ютерами різних архітектур — x86, ARM, MIPS і PowerPC (поточна реалізація Qnet працює в тому числі і в cross-endian середовищі). Але ніби цього мало, будь-який POSIX-додаток, портований в QNX (для перенесення часто потрібно тільки перескладання) без будь-якої доопрацювання буде мати перераховані вище здібності роботи в мережі Qnet. Заінтриговані, як це виходить?

Протокол Qnet розповсюджує механізм обміну повідомленнями на мережу мікроядер QNX Neutrino. Ось і розкритий найбільший секрет Qnet, далі в замітці ми розглянемо, як це працює.

Ця замітка про QNX 6.5.0, але іноді я згадуватиму про інші версії QNX6 і навіть QNX4. Ось і зараз згадалося… Схожий підхід із власною мережею був і в QNX4, де мережа називалася FLEET. Протоколи Qnet і FLEET не сумісні між собою, позначаються відмінності у реалізації ядер. Також є відмінності у адресації вузлів. Проте основою покладено той самий принцип — поширення механізму обміну повідомленнями на мережу мікроядер.

Мережева підсистема io-pkt

Мережева підсистема є типовим представником однієї з підсистем QNX, тобто.складається з адміністратора io-pkt* (побудованого за технологією менеджера ресурсів QNX), модулів пристроїв (драйверів), наприклад, devnp-e1000.so , модулів протоколів, наприклад lsm-qnet.so , а також утиліт, наприклад, ifconfig і nicinfo . До речі, у QNX три менеджери мережі: io-pkt-v4, io-pkt-v4-hc та io-pkt-v6-hc. Суфікс v4 говорить про те, що цей менеджер підтримує лише IPv4, а варіант з v6 підтримує IPv4 та IPv6. Суфікс hc (high capacity) означає розширений варіант із підтримкою шифрування та Wi-Fi. Тому іноді в літературі можна зустріти назву io-pkt*, але ми називатимемо менеджер io-pkt (без зірочки), т.к. у нашому випадку не важливо, про яку версію TCP/IP йдеться, адже ця замітка про Qnet.

У попередніх версіях QNX6 мережевий менеджер називався io-net, і модуль протоколу TCP/IP не був об'єднаний з io-net, а був самостійним модулем на зразок lsm-qnet.so. Хоча заждіть, адже й модулі тоді мали інший префікс, так TCP/IP модулі називалися npm-tcpip-v4.so і npm-tcpip-v6.so, а Qnet – npm-qnet.so. Хоча останнє теж не зовсім вірно, у стародавні часи (в епоху QNX 6.3.2) було два модулі Qnet – npm-qnet-compat.so (для сумісності з старішими версіями QNX6) і npm-qnet-l4_lite.so (новий протокол , що підтримується модулем lsm-qnet.so зі складу QNX 6.5.0). До речі, npm означає Network Protocol Module, а lsm – Loadable Shared Module.

За часів io-net модулі мережевих драйверів носили гордий префікс devn. Драйвери для io-pkt мають інший префікс – devnp. Старі драйвери можна підключати і до io-pkt, при цьому автоматично використовується модуль прошарку devnp-shim.so.

Мал. 1. Деталізоване уявлення архітектури io-pkt.

Архітектура io-pkt представлена ​​на рис.1.На нижньому рівні розташовані драйвери дротової та бездротової мереж. Це модулі, що підвантажуються (DLL, розділяються бібліотеки). Крім Ethernet підтримуються й інші середовища передачі. Наприклад, драйвер devn-fd.so дозволяє організувати передачу та прийом даних використовуючи файловий дескриптор (fd це якраз file descriptor), таким чином можна організувати роботу мережі, наприклад, по послідовному порту. Швидкості, звісно, ​​будуть відповідні, але іноді це дуже рятує. Драйвери пристроїв підключаються до багатопотокового компонента другого рівня (стеку). Стек, по-перше, забезпечує можливість мостового з'єднання та ретрансляції. По-друге, стек надає уніфікований інтерфейс керування пакетами та обробку протоколів IP, TCP та UDP. На верхньому рівні розташований менеджер ресурсів, який реалізує передачу повідомлень між стеком і додатками користувача, тобто. забезпечує роботу функцій open(), read(), write() та ioctl(). Бібліотека libsocket.so перетворює інтерфейс io-pkt на BSD socket layer API, який є стандартом для більшості сучасного мережного коду.

Стек також надає інтерфейси для роботи з даними на Ethernet та IP рівнях, що дозволяє протоколам (наприклад, Qnet) виконаним у вигляді DLL з'єднуватися з необхідним рівнем (IP або Ethernet). Якщо потрібна взаємодія із зовнішніми програмами протокол (наприклад, Qnet) може включати власний менеджер ресурсів. Крім драйверів та протоколів стек включає засоби пакетної фільтрації: BPF (Berkeley Packet Filter) та PF (Packet Filter).

Приклад запуску io-pkt за допомогою протоколу Qnet:

io-pkt-v4-hc -d e1000 -p qnet

Опція -d вказує драйвер мережевого контролера devnp-e1000.so, опція -p завантажує модуль Qnet. Насправді при установці QNX з інсталяційного диска мережа стартує автоматично зі стартових сценаріїв, ручний запуск зазвичай потрібен у разі вбудовування QNX і для зменшення швидкості завантаження системи.

Крім роботи з кадрами Ethernet, протокол Qnet може також інкапсулюватися в IP пакети. Це може бути зручно, наприклад, під час роботи у розподілених мережах. Слід враховувати, що накладні витрати у разі збільшуються. Приклад запуску для роботи Qnet поверх IP:

io-pkt-v4-hv -d e1000 -p qnet bind=ip,resolve=dns

Якщо з якихось причин io-pkt був запущений без підтримки Qnet, модуль lsm-qnet.so можна підвантажити пізніше, наприклад:

mount -Tio-pkt lsm-qnet.so

Більш повну інформацію про io-pkt можна отримати у довідковій системі QNX, а ми перейдемо до основної теми нашої нотатки.

Як працює Qnet?

З точки зору користувача Qnet працює повністю прозоро. Стоп. А чи не час пояснити значення слова прозоро у цьому контексті? Мабуть, настав час. Термін «прозорість» у нашому випадку означає, що для доступу до віддаленого ресурсу не потрібно вживати якихось додаткових дій у порівнянні з доступом до локального ресурсу. Спробую пояснити на прикладах трохи нижче.

Після запуску Qnet створює каталог /net, де відображається файлова система кожного вузла мережі в окремому каталозі з ім'ям вузла. Якщо ім'я вузла (hostname) не встановлено (тобто використовується стандартне ім'я localhost), то в каталозі /net він буде обзиватись ім'ям складеним з MAC-адреси. Наприклад, наступна команда виведе на екран вміст кореневого каталогу вузла zvezda:

Наступна команда дозволяє відредагувати один із стартових сценаріїв на вузлі zvezda:

vi /net/zvezda/etc/rc.d/rc.local

З доступом до файлів розібралися, нічого дивного тут немає. Доступ до пристроїв працює аналогічно. Ось так, наприклад, можна працювати з послідовним портом на іншому вузлі:

qtalk -m /net/zvezda/dev/ser1

А ось приклад цікавіший:

phcalc -s /net/zvezda/dev/photon

Зазвичай програми Photon (це штатна графічна віконна підсистема QNX) дозволяють вказати сервер, до якого будуть підключатися (опція -s). У цьому випадку програма запускається на локальному вузлі, а графічне вікно відображатиметься на вузлі zvezda. На локальному вузлі не потрібно навіть запуск графічної підсистеми. Це може бути зручно в ряді випадків, наприклад, коли вузол не має графічного контролера, але потрібне графічне відображення зібраних даних із датчиків або налаштування системи. Також такий підхід може дозволити розвантажити центральний процесор графічного сервера.

Описаний підхід може бути застосований не лише до графічної підсистеми, а й до будь-якої іншої, у т.ч. як не дивно до мережевої. І навіть іноді застосовувався в QNX4, в якій потрібна окрема ліцензія на кожен модуль, у тому числі окрема ліцензія на TCP/IP стек. Менеджер Tcpip можна запустити лише на одному вузлі в мережі FLEET, і всі запити бібліотеки socket направляти на цей вузол. Не лякайтеся, QNX6 зазвичай так не роблять. Та й у випадку з io-pkt у цьому нема рації, т.к. TCP/IP стек невіддільний від самого io-pkt.

З файлами та пристроями, сподіваюся, розібралися. А як же бути із процесами? Із цим теж все просто.Ряд системних утиліт надає опцію -n , яка говорить про те, що потрібно працювати на віддаленому вузлі, або збирати інформацію з віддаленого вузла. Наприклад, отримати список запущених процесів з аргументами командного рядка можна так:

Якщо якась утиліта або програма не підтримує опцію -n, то на допомогу приходить штатна утиліта on, яка якраз і призначена для запуску додатків на іншому вузлі, наприклад:

У цьому випадку утиліта ls запускається на вузлі zvezda, а висновок утиліти відображається у поточному терміналі.

Насправді утиліта on надає багаті можливості з управління параметрами процесів, що запускаються. Можна не лише запускати процеси на віддаленому вузлі, а й змінювати рівень пріоритету, дисципліну диспетчеризації, запускати процеси від іншого користувача і навіть прив'язувати процес до певного процесорного ядра. Докладніше можна почитати у довідці на утиліту.

Зупинити процес також легко, т.к. утиліта slay підтримує опцію -n. Наприклад:

Так само за допомогою slay можна надіслати і будь-який інший сигнал, не тільки SIGTERM.

Як працює Qnet з погляду програміста?

У попередньому розділі ми розглянули роботу Qnet з погляду користувача ОСРВ. У більшості випадків не потрібно навіть доопрацювання програмного забезпечення для підтримки Qnet. Невже це правда? Тобто. для створення мережного додатка не потрібна робота з якимись спеціальними фреймворками та бібліотеками? Так, не потрібно. Якщо ви працюєте з POSIX, ви навіть не помітите різницю. Але щоб не бути голослівним, наведу код невеликої програми, яка як приклад зберігає рядок у файл (у тому числі і на віддаленому вузлі):

#include #include #include #include int main(int argc, char *argv[]) < int fd; specify file name.\n"); exit(1); >if ((fd = open(argv[1], O_RDWR|O_CREAT, 0644)) < perror("open()"); exit(1); );

Цей код сумісний з Qnet. Адже дійсно немає різниці, в який файл зберігається рядок, в /tmp/1.txt або /net/zvezda/tmp/1.txt. тільки в імені файлу):

fd = open("/dev/ser1", O_RDWR); 
fd = open("/net/zvezda/dev/ser1", O_RDWR);

За рахунок чого досягається подібна простота роботи з мережею? , тому що використовується локально. по мережі путове ім'я буде містити ім'я вузла. машини результатом пошуку буде дескриптор вузла, ідентифікатор процесу та ідентифікатор каналу У випадку мережі Qnet результат буде той самий, тільки дескриптор вузла буде ненульовим (тобто не дорівнює ND_LOCAL_NODE, а це і говорить про віддалене з'єднання). дбати, якщо ви просто використовуєте open() .

Що приховано за простою функцією open()?

Розглянемо ситуацію, коли програмі на вузлі node1 потрібно використовувати послідовний порт /dev/ser1 на вузлі node2 . На рис. 2 показано, які операції виконуються, коли програма викликає функцію open() з ім'ям /net/node2/dev/ser1 .

Мал. 2. Обмін повідомленнями через мережу Qnet.

  1. Програма надсилає повідомлення локальному менеджеру процесів із запитом про дозвіл дорожнього імені /net/node2/dev/ser1 . Т.к. за простір імен /net відповідає lsm-qnet.so , менеджер процесів повертає повідомлення переадресації, в якому вказує, що додаток повинен звернутися до локального адміністратору мережі io-pkt .
  2. Програма надсилає повідомлення локальному адміністратору мережі io-pkt з тим самим запитом про дозвіл путнього імені. Локальний адміністратор мережі повертає повідомлення переадресації із зазначенням дескриптора вузла, ідентифікатора процесу та ідентифікатора каналу менеджера процесів вузла node2 .
  3. Програма створює з'єднання з менеджером процесів вузла node2 і в черговий раз надсилає запит на дозвіл дорожнього імені. Менеджер процесів на вузлі node2 у свою чергу повертає ще одне повідомлення переадресації із зазначенням дескриптора вузла, ідентифікатора процесу та ідентифікатора каналу драйвера послідовного порту на власному вузлі (node2).
  4. Додаток створює з'єднання з драйвером послідовного порту на вузлі node2 і отримує ідентифікатор з'єднання, який може використовуватися для подальшого обміну повідомленнями (наприклад, виклики read() , write() та інших POSIX-функціях).

Ще раз підкреслю, що для програміста, що використовує POSIX, функцію open() всі ці низькорівневі виклики приховані. В результаті виклику open() буде отримано файловий дескриптор, або код помилки.

При дозволі імені на кожному кроці із запиту автомагічно видаляються компоненти імені, які були дозволені. У прикладі вище на кроці 2 запит до локального адміністратора мережі містить тільки node2/dev/ser1 . На кроці 3 ім'я містить лише dev/ser1 . На кроці 4 – тільки ser1.

Політики якості обслуговування

Протокол Qnet підтримує передачу кількома каналами. Для вибору режиму роботи під час використання кількох каналів застосовуються політики якості обслуговування (QoS, Quality of Service). У мережах Qnet служба QoS насправді вибирає середовище передачі. Але якщо в системі лише один мережний інтерфейс, QoS не працює. Підтримуються такі політики якості обслуговування:

  • loadbalance — Qnet буде використовувати будь-які доступні канали зв'язку і зможе розподіляти передачу даних між ними. Ця політика використовується за умовчанням. У цьому режимі пропускна здатність між вузлами дорівнюватиме сумі пропускних здібностей по всіх доступних каналах. Якщо один із каналів обривається, Qnet автоматично переключиться на використання інших доступних каналів. На несправний канал автоматично надсилатимуться службові пакети, і коли зв'язок відновиться, то Qnet знову використовуватиме цей канал.
  • preffered — використовується лише один зазначений канал зв'язку, а решта ігнорується доти, доки основний не вийде з ладу. Після виходу з ладу основного каналу зв'язку Qnet переходить у режим loadbalance із використанням усіх доступних каналів. При відновленні основного каналу Qnet переходить у режим preffered.
  • exclusive — використовується лише один вказаний канал зв'язку, а решта каналів не використовуватиметься навіть у тому випадку, якщо основний вийде з ладу.
/net/zvezda~exclusive:en0/dev/ser1

Коли використовувати Qnet?

Вибір тієї чи іншої протоколу залежить від низки чинників. Протокол Qnet призначений для мережі довірених комп'ютерів, які працюють під управлінням ОСРВ QNX Neutrino і мають однаковий порядок байт. Протокол Qnet не виконує аутентифікацію запитів. Захист прав доступу виконується за допомогою звичайних прав доступу користувачів та груп файлів. Також протокол Qnet це протокол із встановленням з'єднання, повідомлення про мережеві помилки передаються клієнтському процесу.

Якщо в мережі працюють комп'ютери з різними операційними системами або ступінь довіри до мережі невисока, варто розглянути використання інших протоколів, з якими QNX також працює, наприклад, TCP/IP, зокрема, FTP, NFS, Telnet, SSH та інших.

Замість епілогу

У замітці, звичайно, розглянуті не всі можливості та особливості Qnet, але дано загальний опис можливостей протоколу. Якщо вас зацікавила технологія Qnet або QNX загалом, то докладніше з матеріалом з цієї та інших тем можна ознайомитись у Системній архітектурі (System Architecture) QNX Neutrino. Документація доступна в електронному вигляді на сайті www.qnx.com (англійською мовою), частково переклад доступний на сайті www.kpda.ru. Також є російський переклад у друкованому вигляді:

Операційна система реального часу QNX Neutrino 6.5.0 Системна архітектура. ISBN 978-5-9775-3350-8
Операційна система реального часу QNX Neutrino 6.5.0 Посібник користувача. ISBN 978-5-9775-3351-5