Як Україна «відкрила» російське метеорологічне сховище, не заплативши за ключ

Коли російські чиновники щось продають, це завжди супроводжується трьома аргументами:

• «Це секретно!» — вам ще пощастило, що ми взагалі це показуємо.
• «Це надзвичайно складна технологія!» — без нас ви не зрозумієте.
• «Це дуже дорого!» — просто тому що… ну, тому що.

Саме так сталося з російськими метеорологічними центрами. Їх пропонували Україні по 40 000 доларів за одиницю, стверджуючи, що без них доступ до міжнародної метеорологічної мережі неможливий.

Але в нас були інші плани.

«Бриз» проти «золотого метеорологічного центру»

Українські інженери розробили власний метеорологічний інформаційний концентратор «Бриз». Він був у десять разів дешевший, працював не гірше, але залишалася проблема:

росія контролювала вузли доступу до міжнародної мережі й блокувала підключення України.

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

Ми не сперечалися. Ми просто знайшли обхідний шлях.

Мінськ: гра на обидва боки

Російські метеорологічні центри також були розташовані в Білорусі, яка була важливою ланкою мережі.

Мінськ традиційно намагався балансувати між обома сторонами. Білоруси не знали внутрішньої роботи російських центрів, але могли відкрити канал зв’язку до Києва. І вони це зробили.

«Секретний протокол»? Тільки для тих, хто з ним не знайомий

Проєкт «Бриз» очолював Андрій Ніколаєв, головний розробник і технічний керівник проєкту.

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

Сканере портів, привіт!

Коли наша система вже повністю працювала, бракувало лише одного — підключення до мережі.

Ми запустили сканер портів — методично перевіряючи можливі точки доступу, доки не знайшли потрібний порт.

З’єднання встановлено!
Україна отримала повний доступ до міжнародної метеорологічної мережі!

Економічний ефект: заощадження, немислимі у 2000 році

Концентратори «Бриз» були розгорнуті в усіх регіонах України, а також в аеропортах і залізничних мережах.

Їх було щонайменше сто, тобто заощадження обчислювалися мільйонами доларів.

На межі 2000 року такі фінансові заощадження були для країни немислимою сумою.

Шок і реакція

росіяни були приголомшені:

«Але… але це ж наш закритий протокол!»

А ми відповіли:

«Хлопці, ми проєктуємо такі системи з 1991 року».

А Мінськ? Як завжди:

«Я нічого не знаю, я тут ні до чого…» 😆

Від метеорологічних центрів до розроблення програмного забезпечення

Коли ти справді розумієш технологію, ти не переплачуєш за маркетингові «замки».

Це стосується не лише метеорологічних центрів, а й розроблення програмного забезпечення.

Як точно оцінити трудомісткість проєкту?

Як уникнути зайвих витрат?

Як визначити потрібну кількість розробників?

💡 «Калькулятор трудомісткості розроблення програмного забезпечення», створений Андрієм Ніколаєвим, відповідає на ці питання.

Спочатку «Бриз», тепер — автоматизована оцінка складних проєктів.

Висновок

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

У росії кажуть, що їхні проблеми — дурні та погані дороги

З цим важко сперечатися, але до списку варто додати ще й погані лінії зв’язку.

Саме тому цей протокол був розроблений у Москві — щоб компенсувати низьку якість каналів зв’язку, характерну для величезних територій росії. Однак сам протокол насправді не розв’язував проблему. Натомість він став частиною схеми «золотих метеорологічних центрів», призначеної для прив’язування колишніх радянських республік до купівлі дорогого російського обладнання.

Як росія намагалася перетворити протокол на «золоті кайдани»

Цей протокол був придуманий і впроваджений у Москві для Росгідромету. Згідно з усіма офіційними регламентами, будь-які метеорологічні центри в колишніх радянських республіках мали йому відповідати. Це дало російській владі підставу вважати, що всіх буде змушено купувати їхні «золоті» російські метеорологічні центри.

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

Але не для України.

Протокол за замком

Нижче описано протокол TCP/IP для ліній зв’язку низької якості, рекомендований для використання в СНД (Рекомендація RG/GST-14). Цей протокол був основою закритої російської системи, яку нам вдалося обійти без купівлі дорогого обладнання.

Вступ

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

Метеорологічний протокол сеансового рівня для ліній зв’язку низької якості

Опис: опис протоколу TCP/IP для каналів низької якості, рекомендованого для використання в СНД (Рекомендація RG/GST-14).

Вступ

Описаний нижче протокол призначений для обміну метеорологічними повідомленнями через мережу TCP/IP між системами комутації повідомлень (MSS) на базі UNIX-машин, переважно з використанням аналогових ліній телефонного типу.

Алгоритм взаємодії процесів

Обмін даними між двома MSS здійснюється пакетами, які можна класифікувати як службові пакети та інформаційні пакети. Службові пакети використовуються для керування прийманням і передаванням інформаційних пакетів, що містять метеорологічні повідомлення, а також для контролю стану з’єднання.

На програмному рівні як алгоритм взаємодії прийнято схему «клієнт-сервер», а механізм взаємодії базується на мережевому стандарті «socket». Програми, яким потрібно обмінюватися даними, мають працювати в різних режимах, тобто одна програма — у режимі «сервер», а інша — у режимі «клієнт».

Після запуску програма «сервер» відкриває сокет, присвоює йому номер порту (Bind), що залежить від номера логічного каналу (LCN), під яким налаштовано MSS, і очікує з’єднання (accept) від віддаленої програми «клієнт».

Після запуску програма «клієнт» також відкриває сокет і намагається знайти «сервер» у мережі та встановити з’єднання (connect), указуючи ім’я машини сервера та номер порту.

Алгоритм взаємодії програм

Якщо «сервер» не вдається знайти на зазначеній машині, «клієнт» може спробувати знайти «сервер» на альтернативній машині або повторити спробу з’єднання пізніше.

Існує кілька причин невдалого з’єднання, основні з них:

• машину «сервера» вимкнено;
• програма «сервер» неактивна;
• мережевий порт на машині «сервера» зайнятий;
• між віддаленими машинами немає зв’язку;
• тайм-аут з’єднання.

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

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

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

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

Після надсилання пакета завершення повідомлення (END) програма-передавач запускає таймер очікування підтвердження (ACK WAITING), і якщо час спливає без отримання пакета ACK, повідомлення передається повторно. Програма-передавач вважає передавання повідомлення успішним після отримання пакета підтвердження (ACK).

Якщо під час роботи виявлено розрив мережевого з’єднання або будь-яку помилку читання під час приймання/передавання, програми закривають «сервер» і намагаються встановити нове з’єднання.

Щоб запобігти перевантаженню мережевого каналу, що особливо важливо під час роботи на поганих і повільних каналах передавання даних, у програмах має бути реалізовано «WINDOW» для передавання, розмір якого залежить від швидкості каналу та потрібної пропускної здатності.

За замовчуванням розмір вікна передавання для MSS встановлюється рівним 5, тобто програма-передавач може надіслати мережею 5 повідомлень, не очікуючи пакетів підтвердження (ACK).

Час ACK WAITING є параметром програми, який визначається під час встановлення системи; на практиці його зазвичай задають у межах 120–300 секунд. Цей параметр має бути однаковим для «сервера» і «клієнта».

Значення параметрів:

• «Вікно передавання» — 1, 3, 5, 10, 15
• Час «ACK WAITING» — 60, 120, 180, 240, 300 секунд

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

Для контролю стану з’єднання під час пауз між передаванням повідомлень програми обмінюються службовими пакетами готовності до приймання (RR).

Програма має контролювати тайм-аути приймання та передавання пакетів.

Під час передавання програма має забезпечувати регулярне надсилання певного пакета до мережі; якщо метеорологічних повідомлень немає, програма надсилає пакети готовності до приймання (RR).

Цей інтервал визначається як час ACK WAITING, поділений на 4.

Під час приймання програма має контролювати отримання будь-якого пакета протягом певного періоду. Якщо жодного пакета не отримано, програма має закрити сокетне з’єднання і розпочати встановлення нового з’єднання.

Цей інтервал визначається як час ACK WAITING, поділений на 2.

2. Структура повідомлення при використанні «socket»

• Інформаційні пакети (INFO) мають вільну структуру і містять лише текст метеорологічного повідомлення у двійковому форматі або сегменти факсимільного повідомлення у формі стандартних метеорологічних повідомлень.
• Метеорологічні повідомлення можуть передаватися у звичайному або запакованому (стисненому) вигляді. Для стиснення використовується біт “COMPRESS” у полі типу службового пакета.

3. Службові пакети

Структура службових пакетів DATA, END, ACK

a) Тип пакета — визначає призначення пакета і може бути таким:

• DATA — пакет опису повідомлення (початок передавання повідомлення);
• DATA Z — пакет опису повідомлення (початок передавання повідомлення) при використанні режиму стиснення;
• END — пакет завершення передавання повідомлення;
• ACK — пакет підтвердження приймання повідомлення;
• RR — пакет готовності до приймання.

b) Ідентифікатор повідомлення — параметр MSS, спеціальна адреса для швидкого пошуку повідомлення в черзі;

c) Довжина повідомлення — усі символи повідомлення від SOH до ETX;

d) Порядковий номер повідомлення — група “nnn”;

e) AHD — скорочений заголовок повідомлення (10 символів у коді ITA-5, 2 зарезервовані октети);

f) Пріоритет повідомлення — визначається для конкретного типу даних, для швидкого пошуку повідомлення в черзі.

Структура службового пакета RR

Цей пакет використовується «приймачем» для контролю стану з’єднання за відсутності трафіку даних.

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

Символьні параметри службових пакетів ідентифікуються десятковими цифрами і мають такі значення:

• DATA — 1
• DATA.Z — 5 (використовує біт COMPRESS з бітовою маскою 0x80);
• ACK — 2
• END — 4
• RR — 6

Правила використання TCP/IP для зв’язку через «socket»

1. Усі нові з’єднання мають починатися з останнього підтвердження.
2. Встановлене з’єднання може існувати необмежено довго.
3. Перед передаванням кожного повідомлення має передувати пакет опису повідомлення (DATA).
4. Після передавання всіх символів повідомлення (пакет INFO) має бути надісланий пакет завершення повідомлення (END).
5. «Приймач» має порівняти параметри з пакета завершення повідомлення (END) з параметрами з пакета опису повідомлення (DATA).
   • Якщо параметри повністю збігаються, повідомлення вважається успішно прийнятим, і «передавачу» надсилається пакет підтвердження (ACK).
   • Якщо параметри не збігаються, повідомлення вважається неприйнятим, і «приймач» завершує з’єднання.
6. Якщо трафіку немає, «передавач» і «приймач» мають обмінюватися службовими пакетами готовності до приймання (RR), щоб підтримувати синхронізацію з частотою:

   T_rx-rr = 2T_tx-rr

Протокол реалізовано в програмному забезпеченні метеорологічних концентраторів і факсимільних серверів «Бриз» у регіональних гідрометеорологічних центрах України та в Головному центрі даних Державної гідрометеорологічної служби України.

Ми хотіли незалежності України не лише на словах, а й у дії — там, де могли зробити реальний внесок. Ми досягали цього, застосовуючи свої найкращі технічні навички та відданість своїй країні.

Метеорологічна мережа була побудована на розроблених в Україні концентраторах «Бриз» — універсальній і незалежній від протоколів системі, здатній працювати з будь-яким форматом даних, кодуванням або лінією зв’язку. Цю технічну основу було використано в метеорологічній телекомунікаційній мережі України із залученням перевірених рішень із систем «Сбор» та «Єдиний центр управління». Саме ця основа згодом дала змогу створити національні системи реального часу: «Навігація» (система управління навігаційно-часовим забезпеченням України) та «Система обліку пасажиропотоків метрополітену».

Висновок

Ми створили систему, яка працювала і приносила користь, а не обіцянки.

Філософія вибору OSI: чому стандартна модель взаємодії відкритих систем?

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

📌 Перший принцип: відкриті системи

• Якщо мережа має інтегруватися з іншими, її не можна робити закритою й обмеженою одним протоколом або однією технологією.
• Лише один стандарт універсально розв’язує цю проблему — модель взаємодії відкритих систем (OSI).
• Це було не просто технічне рішення, а ідеологічний вибір — будувати систему, не обмежену технологіями, виробниками або типами даних.

Що було б, якби OSI не використовували?

• Кожен розробник створював би власну мережу, несумісну з іншими.
• Не було б єдиного підходу, що призвело б до хаосу в інтеграції.
• Будь-яка зміна протоколу або обладнання вимагала б переписування всієї системи.

📌 Другий принцип: сім рівнів — не просто структура, а інструмент

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

📌 Гармонія семи рівнів OSI

Вибір семи рівнів в OSI не був випадковим — він спирається на фундаментальні принципи структури інформації та природної взаємодії.

• Музика — сім нот, кожна з яких відіграє свою роль у гармонії.
• Світло — сім кольорів веселки; в Україні їх саме сім, на відміну від англомовної традиції.
• OSI — сім рівнів, і кожен виконує власну функцію, не заважаючи іншим і створюючи єдину систему.

📌 Важлива паралель

Якщо прибрати один із рівнів OSI, уся система руйнується, так само як якщо прибрати одну ноту з октави або один колір із веселки.

📌 Головний висновок

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