Забезпечення надійності проходження інформації у системі телемедичних консультацій

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Забезпечення надійності проходження інформації у системі телемедичних консультацій

М.В. Кононов, O.В. Кононов, М.К. Новоселець,

Л.О. Ахременко, О.О. Судаков

Київський університет імені Тараса Шевченка

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

Ключові слова: телемедицина, Інтернет, телеконференція, клієнт-сервер, протокол.

Вступ

Проведення телемедичних консультацій [1] з використанням Інтернету, особливо в інтерактивному режимі, вимагає забезпечення надійності передачі інформації та якісної синхронізації роботи клієнтських процесів. Особливо, якщо взяти до уваги, що таких консультацій потребують клінічні заклади, які не мають умов достатньо якісного приєднання до мережі. Звичайно, використання для реалізації комунікаційної підсистеми потокового режиму роботи, тобто протоколу TCP, дозволяє гарантувати достатньо надійну доставку файлів при їх проходженні мережею і значно спрощує проблему. Однак складність структури даних і необхідність багатопотоковості, вимагають застосування додаткових мір на прикладному рівні.

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

Протокол передачі файлів запитів для відкладених та інтерактивних консультацій

В основу проекту було покладено вимогу забезпечення надійного проходження консультацій за умов, коли користувачі телемедичної системи мають доступ до Інтернету лише на протязі короткого проміжку часу. Це відповідає, наприклад, випадку dial-up з'єднання або випадку, коли користувач не має постійного доступу до свого робочого місця. Ставилась також вимога надійної роботи на каналах малої пропускної спроможності (2,4-9,6 кб/с), з високим рівнем шуму, або низької надійності. Це веде до значної імовірності обривів зв'язку, тривалого часу передачі даних обстеження, виходів системи з ладу. Виходячи з цих причин, було запропоновано засоби відновлення з'єднання і протокол передачі, що вирішують наступні задачі.

1. Виявлення і корекція помилок при передачі даних та забезпечення надійності.

2. Робота клієнтів за брандмауером.

3. Максимальне використання пропускної спроможності каналу для достатньої швидкої передачі.

4. Забезпечення стійкості системи щодо наявності невиправних помилок передачі даних.

5. Відновлення в результаті апаратних та програмних помилок комп'ютерного обладнання користувачів.

Перша задача вирішується нижче прикладного рівня використанням добре розробленими на сьогодні апаратними протоколами передачі даних та транспортними протоколами. Зазначимо, що в даному випадку оптимальнішим є використання TCP, ніж UDP з контролем якості передачі на прикладному рівні, оскільки в останньому випадку вимагається ретрансляція хибних повідомлень за повним маршрутом замість ланки, а в умовах «поганих» каналів така ймовірність може бути досить високою. Оскільки підтримка протоколу TCP інтегрована в сучасні мережеві операційні системи, тому при розробці телемедичних систем для цього доцільно використовувати стандартний АРІ. У запропонованій системі використано інтерфейс BSD socket, орієнтований на з'єднання.

Для забезпечення роботи за брандмауером (наприклад, в режимі трансляції адрес) взаємодія клієнтів між собою завжди виконується через сервер. На початку сеансу клієнт посилає запит на з'єднання (connect) на сервер, який працює в пасивному режимі (listen), тобто чекає з'єднання на певному порту.

Запит на консультацію як відкладеного, так і інтерактивного типу в запропонованій телемедичній системі представлено у вигляді файлу. Підготовка запиту (або відповіді) не вимагає наявності мереженого каналу і може проводитись в режимі offline. Для спрощення роботи системи уся адресна інформація у вигляді унікального номера та ідентифікаторів (UID) відправника і адресата міститься в імені файлу запиту.

Таким чином, передача запитів та відповідей зводиться до передачі файлів, що дозволяє використовувати протокол FTP або деякий аналог. Для збільшення безпечності та ефективності використання мережі замість використання FTP було розроблено спеціалізований протокол. Відповідно до цього протоколу користувачі системи взаємодіють з сервером за допомогою віртуальних каналів -- одного для керуючих повідомлень та декількох для передачі файлів. Керуючий канал встановлюється при приєднанні користувача до системи (сервера) після автентифікації, яка виконується без втручання користувача на основі даних про нього, що розміщені на сервері, та шифрованої інформації, яка зберігається на боці клієнта.

За успішного приєднання активується алгоритм відправки файлів-запитів на консультацію та відповідей (у випадку відкладеної консультації) як з клієнта на сервер, так і з сервера на клієнт. При цьому для забезпечення максимального завантаження фізичного каналу паралельно відкриваються декілька каналів (вимога пункту 3). Оптимальна кількість каналів передачі залежить від пропускної спроможності лінії. Як показали результати випробування системи, оптимальне значення -- 4 в обох напрямках.

Всі операції керування та діагностики між сервером та клієнтом відбуваються за допомогою керуючого каналу. Протокол останнього оперує повідомленнями (командами) фіксованої структури (див. табл. 1).

Заголовок повідомлення містить дані, необхідні для адресації повідомлення (поля 2, 3), код команди (поле 2), що задає інтерпретацію поля 5 та розмір всього повідомлення, який необхідний для коректного читання даних. Поле 4 є надлишковим, проте воно може бути використано при відновлені в результаті збою. Зауважимо, що для відкладеної консультації поле 3 також надлишкове, оскільки адресна інформація міститься в імені файлу, але така структура керуючого повідомлення збережена для спрощення сумісності з командами інтерактивної консультації.

Таблиця 1. Структура повідомлення керуючого каналу.

Для відкриття каналу передачі файлів використовується протокол сесійного рівня, що складається з декількох фаз. Кожна фаза починається з відправки повідомлення до керуючого каналу з вимогою прийняти файл з даним іменем. При цьому сторона, яка приймає файл, посилає відповідь, що містить інформацію про можливість виконання даної операції (статус) та позицію в даному файлі (на випадок досилання після поновлення втраченого зв'язку), з якої необхідно починати передачу. Схеми встановлення каналів передачі показані на рис. 1, 2. Оскільки сервер завжди працює в пасивному режимі, до повідомлення вводяться додаткові поля. Зокрема, сервер генерує cookie, а також вказує IP-адресу та порт, до якого повинен приєднатись клієнт, що дає можливість використовувати розподілену систему серверів.

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

інформація телемедичний клієнтський надійність

Рис. 1. Процес встановлення каналу передачі файлу клієнтом.

Рис. 2. Процес встановлення каналу передачі файлу сервером.

Протокол підтримки консультацій реального часу

Вимоги до системи реального часу аналогічні до системи відкладених консультацій, проте складність задачі значно вища. Це пов'язано з необхідністю високоякісної синхронізації клієнтських процесів і мінімізації затримок при передачі (при великих затримках втрачається зручність та «інтерактивність»).

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

Додатковою проблемою є синхронізований запуск інтерактивної консультації (конференції). Оскільки передбачається робота за брандмауером, сервер не має права звертатись до клієнта для запуску конференції, навіть коли клієнт має постійне підключення. Таким чином, встановлення зв'язку між учасниками конференції має ініціюватись з боку клієнтів, тобто з усіх клієнтських станцій повинно виконуватись звертання до сервера. Для цього на клієнтські робочі станції встановлюється і запускається через автозавантаження спеціальний компактний процес-супервізор. Основне призначення супервізора -- слідкувати за часом початку наперед запланованої консультації (існує зручний інтерфейс планування) і виконувати запуск основної клієнтської програми з налаштуванням на інтерактивний режим. Зазначимо, що для вчасного запуску конференції годинники клієнтських робочих станцій обов'язково повинні бути синхронізовані. Синхронізація виконується по годиннику сервера на початку кожного з'єднання з ним. Годинник комп'ютера при цьому не переводиться (це виключне право самого користувача), замість цього записується поправка до «клієнтського» часу, яка і враховується в роботі супервізора весь час до нового приєднання.

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

Фази встановлення каналу конференції наведено на рис. 3. Приєднання до консультації реального часу (конференції) відбувається у випадку передачі клієнтською стороною першого повідомлення у нову конференцію, або у випадку термінових консультацій при прийомі сервером запитів на таку консультацію. При цьому у випадку нової конференції сервер запускає задачу, що керує конференцією, та передає клієнту IP адресу та порт для приєднання. Якщо консультація з даним номером вже проводиться, то повертаються параметри для приєднання до неї. Всі повідомлення консультацій зберігаються у вигляді черги, що записуються в файл. Це дозволяє ефективно відновлювати контекст консультації у випадку виходів серверу з ладу, або при необхідності повторної консультації.

Рис. 3. Протокол приєднання клієнта до консультації реального часу.

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

Таблиця 2. Структура повідомлення каналу конференції.

Телеконсультативна система на основі запропонованої архітектури проходить випробування в клінічних умовах в Інформаційному центрі телемедицини АМН України.

Висновки

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

Попередня передача ресурсоємної інформації, необхідної для проведення інтерактивної консультації, зазначені методи синхронізації початку телеконференції і проходження її команд та подвійна буферизація команд (на сервері та клієнті) забезпечують, на відміну від аналогічних систем, ефективну роботу інтерактивної консультації навіть в умовах повільних каналів і розривів зв'язку.

Література

1. Mun S.K., Elsayed A.M., Tohme W.G., Wu Y.Ch. Teleradiology /Telepathology Requirements and Implementation // J. of Medical Systems. -- 1995. -- Vol. 19. -- № 2. -- P. 153-164.

2. Кононов М.В., Кононов О.В., Новоселець М.К., Ахременко Л.О., Судаков О.О. Система телемедичних консультацій, орієнтована на активне використання діагностичних зображень // Реєстрація, зберігання і оброб. даних. -- 2000. -- Т. 2. -- № 4. -- С. 48-58.

Размещено на Allbest.ru