Головна · Здоров'я · Процес підписання перервано з ініціативи користувача. Хто розпочав аналіз журналу реєстрації? Основні способи підтримки постійного з'єднання

Процес підписання перервано з ініціативи користувача. Хто розпочав аналіз журналу реєстрації? Основні способи підтримки постійного з'єднання

COMET технології дозволяють організувати оновлення даних на сторінці без участі користувача.

Чати, інтернет-пошта і розраховані на багато користувачів адмінки - далеко не повний список, де вони застосовні.

У цьому циклі статей - докладно описані численні тонкі моменти та вирішення частих проблем.

Що таке COMET?

COMET (або "server push") - спосіб передачі даних із сервера на клієнт, з ініціативи сервера.

Наприклад, у вас є електронний магазин і менеджер може відстежувати переходи клієнта.
COMET дозволяє менеджеру відразу, онлайн, запитати клієнта про щось, запропонувати цікавий варіант.

"З ініціативи сервера" означає, що клієнт сам не запитує сервер, він просто знаходиться на сторінці.

Найстаріший приклад COMET – чат. Людина просто знаходиться на сторінці та отримує нові повідомлення.

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

Способи реалізації

Способів реалізації COMET досить багато. У них - різні характеристики, переваги і недоліки.
Є два основні класи.

За повідомленням на запит

Кожна подія на сервері браузер отримує окремий запит. Тут є два основні методи.

  1. Часте опитування (polling)
  2. Довге опитування (long-poll)

Щоб зменшити кількість необхідних з'єднань та затримки, повідомлення про події пакують у спеціальні пакети, "датаграми".
Наприклад, одне XML-повідомлення може виглядати як:

Vasya Вітання! processing Обробку завершено

При черговому підключенні браузер отримує відразу весь пакет подій на даний момент.

Браузер тримає постійне з'єднання з сервером, так званий канал, і отримує через нього події.

Канал зв'язку розривається іноді:

  • щоб проксі не подумав, що настав тайм-аут з'єднання і не порвав його за нас
  • для очищення пам'яті від сміття старих повідомлень

Крім того, для вимірювання мережних затримок та контролю з'єднання сервер може періодично посилати по цьому каналу ping-пакети.

Основні способи підтримки постійної сполуки:

  1. Нескінченний IFrame
  2. XMLHTTPRequest, interactive
  3. Multipart XMLHTTPRequest
  4. Event-source

Ви знайдете їх у інших статтях цього розділу.

Загальні для постійних з'єднань проблеми

Протокол HTTP спочатку створювався так, щоб один запит повертав одну одиницю інформації. А ми хочемо – багато, звідси й деякі складнощі.

Буферизація проксі

Таке зустрічається рідко, але проксі може буферизувати певну кількість даних перед передачу клієнту. Наприклад, приймати та віддавати відповідь блоками по 2К. У цьому випадку повідомлення залишатимуться на проксі, і чекатимуть, доки їх не набереться 2К (або який там розмір буфера) байт, і лише тоді – передаватиметься клієнту.

Рішення – додавати до кожного повідомлення 2K пробілів.

Невідомо, чи торкнеться Вас ця проблема. Сподіваюся, що ні, але мати на увазі буферизацію проксі як можливу причину скарг користувачів – треба обов'язково.

Не можна GZIP

IFrame, який використовується для передачі повідомлень, НЕ повинен стискатися gzip/deflate. Інакше кажучи, для службового URL повідомлень стиснення має бути вимкнено.

Увімкнений стиск передбачає, що браузер чекає кінця завантаження, а потім - розпаковує і показує користувачеві. В нашому випадку це категорично протипоказано, а стискати шматочки сторінки (повідомлення) окремо не можна.

Це - неприємний наслідок хакерської натури iframe. Наприклад, в long poll стиск проходить на ура, тому що події не є частиною однієї сторінки.

Буферизація сторінки сервером

Не забудьте вимкнути буферизацію сервером. У зв'язці Apache/PHP - відключіть output buffering і увімкніть ob_implicit_flush:

While (@ob_end_flush()) () ob_implicit_flush(1); // і прибрати ліміт на час виконання скрипту set_time_limit(0);

COMET: Часте опитування VS постійне з'єднання

Як завжди, під час написання веб-програми постає питання про вибір архітектури. З одного боку, рішення на довгих з'єднаннях (усі, крім частих опитувань) забезпечують швидке повідомлення. З іншого... Чи завжди довге з'єднання краще за часті опитування?
Рішення з довгими сполуками на вигляд оптимальніше, але набагато складніше і має ряд особливостей.

  1. Реалізація довгого коннекту, зазвичай, ускладнює архітектуру. Можливо, можна обійтися простіше рішення?
  2. Ряд веб-серверів погано оптимізовано під велику кількість довгих з'єднань. Наприклад, використовуються потоки або процеси, які від'їдають фіксовану кількість ресурсів і не звільняють їх до кінця з'єднання. На рівні OS проблема вирішується використанням kqueue (FreeBSD) або epoll (Linux).
    1. Apache MPM event для apache 2.2 (експериментальний та обмежений MPM, спеціальний потік обробляє Listening та Keep-Alive сокети)
      не працює як слід з mod_perl/mod_php
    2. Jetty (Java) / Twisted (Python), nginx та інші спеціалізовані сервери з одним потоком/процесом на багато клієнтів.

    Чи потягне поточна серверна архітектура довгі з'єднання? Відповідь не є очевидною для сотень/тисяч одночасних з'єднань, але, скажімо, до 100 з'єднань у будь-якій архітектурі все добре.

  3. Наскільки довго користувачі знаходяться на одній сторінці? При переходах коннект, швидше за все, доведеться відкривати заново у будь-якому випадку.
  4. Якщо допустимі затримки доставки подій, то, можливо, вистачить частого опитування?

Класична(transport-independant) модель COMET

Подивимося взаємодія клієнт-сервер " з висоти пташиного польоту " , вище деталей передачі, транспортів тощо. Наприклад, так це зроблено в спеціалізованому server-push движку lightstreamer.

З'єднання з сервером поділяються на два типи

  1. Control connection - контрольні з'єднання, якими клієнт відправляє запити на сервер. Це – звичайні AJAX-запити через XMLHTTPRequest.
  2. Push connection(channel) - потік подій, з'єднання, якими клієнт отримує події з сервера

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

Наприклад, наступна діаграма описує типову послідовність дій:

  1. Клієнт відкриває потокове з'єднання з сервером
  2. Клієнт підписується на події типу Item1 у схемі Schema1
  3. Сервер шле події
  4. Клієнт відписується від подій через нове контрольне з'єднання
  5. Клієнт закриває з'єднання

Або - ось складніша діаграма, в якій клієнт підписується вже на різні типи подій:

В якості транспорту в lightstreamer використовується iframe. Іноді його потрібно закривати для очищення від прийнятих об'єктів. При закритті сесії (це відбувається при refresh сторінки в браузері) сервер буферизує нові події до деякого таймууту і віддає їх, щойно відкривається нова сесія Stream Connection 2 того ж користувача.

Взагалі, буферизація подій - загальний прийом, який дозволяє м'яко переживати закриття з'єднання, і необхідний будь-якому транспорті.

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

Ознаками цієї проблеми є:

    Неможливо зайти до інформаційної бази.

    Майже 100% активність диска, на якому розташований журнал реєстрації та активне читання файлу журналу реєстрації процесом rmngr.
    Цей пункт можна перевірити за допомогою монітора ресурсів (Диспетчер задач - Продуктивність - Відкрити монітор ресурсів) на вкладці "Диск".
    У групі “Запам'ятовуючі пристрої” слід звертати увагу на колонку “Активний час (%)”.
    У групі "Робота диска" потрібно звертати увагу на колонки "Читання" та "Файл". Можна відсортувати по колонці читання. Серед перших рядків із максимальною швидкістю читання буде процес rmngr. Далі потрібно дивитися ім'я файлу, що буде читати, воно буде відповідати журналу реєстрації певної інформаційної бази.

    У консолі адміністрування кластера серверів 1С:Підприємство у списку сеансів майже у всіх користувачів буде велике та приблизно однакове значення в колонці “Захоплено СУБД” або в колонці “Час дзвінка (поточний)”.

При виявленні проблеми потрібно:

    Запам'ятати УІД ІБ, до якої виконується читання процесом rmngr.

    Запустити збір технологічного журналу на події EXCP, якщо ще не запущено.

    Зробити експорт усіх сеансів на проблемному сервері АБО на проблемній ІБ за допомогою консолі адміністрування кластера серверів 1С:Підприємство на випадок, якщо знадобляться додаткові дані для аналізу.

    Перезапустити службу 1С: Підприємство.

    Зібрати технологічний журнал під час перезапуску сервера 1С:Підприємство.

    Проаналізувати технологічний журнал: виконати пошук слів “Вивантажити ЖурналРеєстрації” або “UnloadEventLog”.

Приклад:

29:40.069000-0,EXCP,4,process=rphost, p:processName=ib_accounting ,t:clientID=114396,t:applicationName=1CV8C, t:computerName=COMP ,t:connectID=109127,SessionID=1, Usr=ІвановІІ ,AppID=1CV8C,ClientID=114389,Exception=NetDataExchangeException,Descr=Передача даних перервана з ініціативи приймаючої сторони.

ЗагальнаФорма.ФормаЗвіту.Форма: 1242: ВаріантиЗвітів.СформуватиЗвітВФоні(ПараметриФормуванняЗвіту, РезультатФоновогоЗавдання.АдресРезультату);

Загальний Модуль. Варіанти Звітів. Модуль: 2544: Формування = Сформувати Звіт (Параметри, Брехня, Брехня);

ЗагальнийМодуль.ВаріантиЗвітів.Модуль: 2060: ЗвітОб'єкт.СкомпонуватиРезультат(Результат.ТабличнийДокумент, Результат.Розшифровка);

ЗовнішнійЗвіт.АналізЖурналуРеєстрації.МодульОб'єкта: 64:ВивантажитиЖурналРеєстрації(ТЗ, Відбір, Колонки);

Цим рядком можна сказати хто:ІвановІІ, де (на якому комп'ютері): COMP , в якій інформаційній базі: ib_accounting запустив аналіз журналу реєстрації

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

Наслідки можуть бути різні, а саме:

  • Не подана у строки заявка на участь у конкурсі
  • Програний електронний аукціон
  • Чи не підписаний у строк державний контракт

Три найбільш поширені проблеми в роботі з електронним підписом

  1. Сертифікат учасника закупівлі не відображається на електронному майданчику
  2. Електронний підпис не підписує документи

Насправді помилок може бути набагато більше, але ми розберемо основні та їх причини, а також позначимо можливі шляхи усунення проблем.

Найголовніше — запам'ятати, що для коректної роботи електронного підпису необхідно використовувати браузер Internet Explorer не нижче 8 версії та, бажано, не вище 11 (з 11 версією немає гарантій стабільної роботи підпису).

Сертифікат ключа підпису не видно на майданчику під час спроби входу в систему

В даному випадку помилка викликана відразу кількома причинами, а саме:

  • Некоректне налаштування сертифіката ключа підпису
  • Неправильно налаштований інтернет-браузер
  • Відсутній кореневий сертифікат.

Як вирішити проблему?

Насамперед необхідно переконатися в тому, що Ви коректно встановили відкриту частину сертифіката в особисті через СКЗІ (Кріпто Про). При цьому версія встановленої програми підходить для типу операційної системи.

Потім у налаштуваннях браузера Internet Explorer необхідно додати адреси майданчиків у надійні вузли та увімкнути всі елементи ActiveX.

Електронний підпис видає помилку під час підписання документів

Як правило, ця помилка виникає у ряді випадків:

  • Минув термін дії ліцензії програми КриптоПро
  • Вставлений носій з іншим сертифікатом

Як це виправити?

Для цього Вам необхідно отримати нову ліцензію, звернувшись до Центру, що засвідчує. Після того, як ліцензія успішно отримана, необхідно запустити КриптоПро та ввести серійний номер ліцензії.

У другому випадку Вам необхідно перевірити всі закриті контейнери (носія), вставлені в USB-роз'єм комп'ютера та перевірити правильність вибору потрібного сертифіката.

Система видає помилку під час входу на електронний майданчик

Ця помилка може бути викликана сукупністю причин, зазначених вище. Як показує практика, така помилка в першу чергу виникає через неправильно встановлену бібліотеку Capicom. Рекомендуємо перевірити наявність встановленої бібліотеки на Вашому комп'ютері та звернути увагу на необхідність копіювання 2 системних файлів з розширенням.dll в одну з папок Windows, використовуючи 64-розрядну систему.

Для того, щоб Ви могли уникнути подібних помилок, перед встановленням електронного підпису, прочитайте про встановлення та налаштування електронного підпису або замовити по випуску та налаштуванню електронного підпису в нашій компанії.