Відповівши послідовно на поставлені питання, буде складено протокол взаємодії між клієнтським і серверним компонентами.
Канал передачі запиту від клієнта серверу і результату у зворотному напрямку
Єдиний канал зв'язку, який можна використовувати між клієнтським і серверним компонентами - це з'єднання SSH, всередині якого вже можна передавати необхідну інформацію. Обмеження, яке накладає даний вид зв'язку - це неможливість встановити пряме з'єднання між клієнтським і серверним компонентами, тобто серверний компонент не може встановлюватися режим «прослуховування» на якому або порту вузла СГД Centera унаслідок закритості всіх невикористовуваних портів брандмауером. Відкрити порт для вхідних з'єднань можна тільки після аудиту захищеності СГД Centera з працюючим серверним компонентом.
Не можна розраховувати на те, що канал SSH буде існувати скільки-небудь довго, тому клієнтський компонент повинен обробляти раптовий обрив з'єднання з серверним компонентом.
У світлі наявних знань про специфіку каналу зв'язку можна запропонувати наступні рішення для організації каналу зв'язку між сервером і компонентом:
Обмін інформацією між клієнтським і серверним компонентами через консольний введення-виведення, що надається протоколом SSH. Тобто в контексті SSH-сесії запускається серверний компонент програмного комплексу, а потоки введення-виведення перенаправляються через SSH-з'єднання до клієнтського компоненту. Той аспект, що разом з обривом SSH-з'єднання буде знищена і процес серверного компонента, може бути усунутий за рахунок запуску серверного компонента в контексті додатки screen, яке дозволяє створити власну консольну сесію, до якої можна підключатися через нестабільне з'єднання. Мінусом цієї реалізації була б необхідність ускладнення протоколу взаємодії, який мав би враховувати особливості поведінки наданої screen консолі (при часткової передачі даних на сервер або клієнту, при відновленні стану взаємодії після розриву в середині передачі даних).
Реалізація серверного компонента двома модулями - один є виконуючим модулем, працюючим постійно на вузлі СГД та «слухати» або порт, відкритий на інтерфейсі «поворотна петля», або іменовану трубу; другий - проміжний модуль, що запускається кожного разу з сесії встановлюваного SSH-з'єднання (і знищуваний кожного разу після розриву з'єднання разом з SSH-сесією), що встановлює з'єднання з виконуючим модулем і забезпечує передачу даних з консолі SSH-з'єднання в встановлене з виконуючим модулем з'єднання і назад. У даній реалізації є наступний мінус - складність серверного компонента, состояжего з двох модулів і поява проміжного каналу зв'язку, який потрібно обслуговувати.
Реалізація взаємодії між компонентами через файлову систему вузла СГД Centera. При такій взаємодії запити зберігаються на ФС вузла СГД через SSH-сесію, серверний компонент виповнюється у вигляді самостійного процесу та відстежує зміни в діректіріі із запитами. При виявленні нового запиту серверний компонент обробляє його, а результати поміщає в директорію з результатами. Клієнтський компонент відстежує зміни в директорії з результатами і при виникненні ісеомих результатів отримує їх з вузла СГД використовуючи сесію SSH. При такій взаємодії цілісність переданої інформації підтримується каналом SSH, а збереженої на вузлі - додатковими заходами захисту. У даній реалізації є один мінус - додаткова затримка у виконанні запитів, пов'язана із збереженням запитів і результатів на ФС, а також із затримками при відстеженні змін на ФС.
Серед трьох запропонованих варіантів реалізації взаємодії між клієнтським і серверним компонентами оптимальним з погляду трудовитрат є третій варіант, оскільки вимагає більш просту структуру серверного компонента і більш просте тестування.
Доставка запиту
На ФС вузла СГД створюється директорія, в якій будуть розміщені запити від клієнтського компонента; в цю директорію клієнтський компонент копіює файл з вмістом запиту, використовуючи команду scp, що використовує протокол SSH для передачі даних, але ім'я файлу із запитом на момент запису встановлюється у форматі «незавершеного» запиту, щоб серверний компонент не намагався прочитати створений файл з не до кінця переданим запитом. Після запису файлу з запитом він перейменовується в формат «завершеного» файлу запиту, готового для обробки серверним компонентом.
Обробка запиту сервером
При виявленні серверним компонентом у відповідній директорії нового запиту, відбувається створення в директорії результатів файлу з попередніми результатами, що свідчать про початок обробки запиту сервером. Оригінальний файл запиту видаляється з директорії запитів. Створення та оновлення файлу результатів відбувається за такою ж схемою, за якою відбувається і створення файлу запиту - спочатку створюється «незавершений» файл результату з відповідним ім'ям, який після завершення формування перейменовується в «завершений» формат....
