Перейти до вмісту

Під’єднатися до віддаленого сервера

Кожен клієнт — це рендерер над cc_server, який володіє даними. Настільний застосунок може запустити сервер у собі; вебзастосунок на app.usectrl.dev не може, бо вкладка браузера не здатна розмістити сервер. Так чи інакше, цей посібник спрямовує клієнт на сервер, що працює деінде — невелика машинка, хмарна VM, збірковий сервер.

  • Працюючий cc_server. Якщо його немає, дивіться Запустити headless-сервер.
  • Або три значення спарювання, які видав сервер — URL сервера (ws://…/rpc або wss://…/rpc), ідентифікатор пристрою та ключ спарювання — або одноразовий код запрошення від адміністратора робочого простору. Активація запрошення створює вашого користувача, фіксує ваше членство й видає облікові дані цього клієнта, тож вам ніколи не доведеться мати справу з ідентифікатором пристрою чи ключем.

Локальному серверу нічого не потрібно: ws://localhost:9030/rpc працює і з настільного застосунку, і з браузера, бо браузери вважають loopback довіреним джерелом.

Сервер на іншій машині — інша річ. app.usectrl.dev обслуговується через HTTPS, тож браузер відкриє сокет wss:// лише із сертифікатом, якому вже довіряє, — а cc_server узагалі відмовляється прив’язуватися до не-loopback адреси без TLS. Дайте йому щось одне з цього:

  • сертифікат напряму, за допомогою --tls-cert і --tls-key
  • зворотний проксі, що завершує TLS, попереду, а сервер запущено з --insecure (відкритий текст за проксі, лише в довіреній мережі)
  • тунель або VPN, який надає сертифікат — Tailscale, cloudflared чи подібний. У Налаштування → Сервер → Підключення та стан є вбудована опція тунелю в розділі Надати доступ до цього сервера.

Два параметри на боці сервера легко пропустити. За проксі, NAT або тунелем задайте --public-url як адресу, до якої клієнти насправді мають підключатися — він типово дорівнює локальній прив’язці, тож без нього клієнти звертаються не до того хоста. А якщо ви розміщуєте власну копію вебзбірки, додайте її origin до --allowed-origins, який типово дозволяє лише https://app.usectrl.dev; loopback і нативні клієнти дозволені завжди.

У разі свіжого встановлення:

  1. Запустіть Control Center. Екран першого запуску запитує Як має працювати Control Center?
  2. Замість Запустити в цій програмі заповніть поля підключення: URL сервера та або код запрошення, або ідентифікатор пристрою з ключем спарювання.
  3. Натисніть Підключитись. Control Center звертається до сервера й відкриває вхідні робочого простору.

На настільному застосунку, який уже запускає власний сервер:

  1. Відкрийте Налаштування → Сервер → Підключення та стан.
  2. Натисніть Додати сервер. Введіть URL сервера (wss://host:9030/rpc) та або код запрошення, або ідентифікатор пристрою з ключем спарювання. Кнопка-суфікс у полі URL знаходить екземпляри cc_server у вашій локальній мережі чи tailnet.
  3. Натисніть Підключитись, а потім Перемкнути у рядку нового сервера.

Перемикання відбувається наживо: застосунок на місці перебудовується навколо нової сесії, без перезапуску. Якщо підключення не вдалося, ви залишаєтеся на поточному сервері й бачите помилку. У рядку сервера, на якому ви перебуваєте, немає дії Перемкнути; локальний сервер — перший рядок, позначений Запускати в цьому застосунку.

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

Вебзбірка завжди віддалена.

  1. Відкрийте app.usectrl.dev або власну копію вебзбірки.
  2. Введіть URL сервера та або код запрошення, або ідентифікатор пристрою з ключем спарювання.
  3. Клієнт звертається до сервера й відтворює той самий інтерфейс, що й настільний застосунок.

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

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

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

Дві речі поводяться інакше, а не бувають відсутні. Запис зустрічі працює в браузері, захоплюючи ваш мікрофон і демонстрацію екрана зі звуковою доріжкою. Відкрити в IDE теж працює, але просить сервер запустити редактор на дисплеї сервера, тож проти headless-хоста без редакторів ця кнопка ховається.

  • Час очікування з’єднання вичерпано: сервер має бути доступним із клієнта. Перевірте прив’язку (--bind any), що порт відкритий і що --public-url указує на адресу, до якої клієнт справді може підключитися. У відкритому інтернеті TLS обов’язковий — прив’язка до не-loopback адреси у відкритому тексті відхиляється під час запуску, якщо сервер не запущено з --insecure за проксі.
  • Браузер відмовляється підключатися, але нативний клієнт працює: origin браузера відсутній у списку --allowed-origins сервера. Типово дозволено лише https://app.usectrl.dev (плюс loopback).
  • Ключ спарювання відхилено: повторно виконайте cc_server pair на сервері, щоб змінити ключ того пристрою, а потім введіть новий. Відкликаний пристрій виявляє, що його облікові дані зникли, і закривається безпечно; відкликання розриває активну сесію за лічені секунди.
  • Неправильний робочий простір: робочий простір є частиною URL (/workspaces/:workspaceId/…) і передається з кожним викликом, тож перемикання робочих просторів в одному клієнті змінює лише ваш власний вигляд. Ви можете дістатися лише тих робочих просторів, членом яких є — усе інше відхиляється з повідомленням «Not a member of this workspace». Дивіться Робочі простори та ізоляція.