رفتن به محتوا

اتصال به سرور راه دور

هر کلاینت یک رندرکننده روی یک cc_server است که مالک داده است. رومیزی می‌تواند یکی را درون خودش اجرا کند؛ اما اپ وب در app.usectrl.dev نمی‌تواند، چون یک تب مرورگر نمی‌تواند میزبان سرور باشد. در هر حالت، این راهنما یک کلاینت را به سروری اشاره می‌دهد که جای دیگری اجرا می‌شود — یک جعبهٔ کوچک، یک VM ابری، یک سرور ساخت.

  • یک cc_server در حال اجرا. اگر یکی ندارید، اجرای سرور بدون رابط را ببینید.
  • یا آن سه مقدار جفت‌سازی که سرور ساخته — URL سرور (ws://…/rpc یا wss://…/rpc)، یک شناسهٔ دستگاه و یک کلید جفت‌سازی — یا یک کد دعوت یک‌بارمصرف از یک مدیر فضای کاری. بازخرید یک دعوت، کاربر شما را تأمین می‌کند، عضویتتان را ثبت می‌کند و اعتبارنامهٔ این کلاینت را برایتان صادر می‌کند، پس هرگز با شناسهٔ دستگاه یا کلید سروکار پیدا نمی‌کنید.

مطمئن شوید سرور قابل‌دسترسی است

بخش با عنوان “مطمئن شوید سرور قابل‌دسترسی است”

یک سرور محلی چیزی لازم ندارد: ws://localhost:9030/rpc هم از رومیزی و هم از مرورگر کار می‌کند، چون مرورگرها لوپ‌بک را مبدأی قابل‌اعتماد می‌دانند.

سروری روی ماشینی دیگر فرق دارد. app.usectrl.dev روی HTTPS ارائه می‌شود، پس مرورگر فقط سوکت wss:// را با گواهی‌ای باز می‌کند که از قبل به آن اعتماد دارد — و خودِ cc_server هم از همان ابتدا از بایند کردن یک نشانی غیرلوپ‌بک بدون TLS سر باز می‌زند. یکی از این‌ها را به آن بدهید:

  • گواهی مستقیماً، با --tls-cert و --tls-key
  • یک پروکسی معکوس پایان‌دهندهٔ TLS در جلو، با سرور اجراشده با --insecure (متن ساده پشت پروکسی، فقط روی یک شبکهٔ قابل‌اعتماد)
  • یک تونل یا VPN که گواهی را تأمین می‌کند — Tailscale، cloudflared یا مشابه. تنظیمات ← سرور ← اتصال و وضعیت گزینهٔ اشتراک تونل توکار را زیر اشتراک این سرور دارد.

دو تنظیم در سمت سرور آسان از چشم می‌افتند. پشت یک پروکسی، NAT یا تونل، --public-url را روی نشانی‌ای بگذارید که کلاینت‌ها باید واقعاً شماره‌گیری کنند — پیش‌فرضش بایند محلی است، پس بدون آن کلاینت‌ها میزبان اشتباه را امتحان می‌کنند. و اگر نسخهٔ خودتان از ساخت وب را میزبانی می‌کنید، مبدأ آن را به --allowed-origins اضافه کنید، که پیش‌فرضش تنها https://app.usectrl.dev است؛ لوپ‌بک و کلاینت‌های بومی همیشه مجازند.

روی یک نصب تازه:

  1. Control Center را اجرا کنید. صفحهٔ نخستین اجرا می‌پرسد Control Center چطور اجرا شود؟
  2. به‌جای اجرا در این برنامه، فیلدهای اتصال را پر کنید: URL سرور، به‌همراه یا یک کد دعوت یا یک شناسهٔ دستگاه و کلید جفت‌سازی.
  3. روی اتصال کلیک کنید. Control Center سرور را شماره‌گیری می‌کند و روی صندوق ورودی فضای کاری فرود می‌آید.

روی رومیزی‌ای که خودش از قبل سرور خودش را اجرا می‌کند:

  1. تنظیمات ← سرور ← اتصال و وضعیت را باز کنید.
  2. روی افزودن سرور کلیک کنید. URL سرور (wss://host:9030/rpc) و یا یک کد دعوت یا یک شناسهٔ دستگاه و کلید جفت‌سازی را وارد کنید. دکمهٔ پسوند فیلد URL نمونه‌های cc_server را روی LAN یا تیل‌نت شما کشف می‌کند.
  3. روی اتصال و سپس روی تعویض در ردیف سرور جدید کلیک کنید.

تعویض زنده است: اپ در جای خودش پیرامون نشست جدید بازساخته می‌شود، بدون راه‌اندازی مجدد. اگر اتصال شکست بخورد روی سرور کنونی می‌مانید و خطا را می‌بینید. ردیف سروری که روی آن هستید کنش تعویض ندارد؛ سرور محلی ردیف اول است، با برچسب اجرا در این برنامه.

پس از تعویض، رومیزی هیچ پایگاه‌داده‌ای را مالک نیست. هر صفحه از طریق سرور راه دور روی یک WebSocket می‌خواند و می‌نویسد.

ساخت وب همیشه راه دور است.

  1. app.usectrl.dev یا نسخهٔ خودتان از ساخت وب را باز کنید.
  2. URL سرور به‌همراه یا یک کد دعوت یا یک شناسهٔ دستگاه و کلید جفت‌سازی را وارد کنید.
  3. کلاینت سرور را شماره‌گیری می‌کند و همان رابطی را رندر می‌کند که رومیزی.

اگر پیوند عمیق جفت‌سازی در URL باشد، فیلدها پیش‌پر شده‌اند. کلید جفت‌سازی در قطعهٔ URL سوار می‌شود، که مرورگرها هرگز آن را به سرور میزبان صفحه نمی‌فرستند، پس میزبان ایستا هرگز آن را نمی‌بیند.

کارهایی که مرورگر انجام نمی‌دهد

بخش با عنوان “کارهایی که مرورگر انجام نمی‌دهد”

کلاینت وب همان سروری را می‌خواند و می‌نویسد که رومیزی، اما چند سطح به یک پنجرهٔ بومی یا دستگاه‌های خود ماشین نیاز دارند:

  • بدون توست اعلان سیستم‌عامل، بدون صداهای اعلان، بدون ریل بنر محیطی (مرکز اعلان درون‌برنامه‌ای همچنان کار می‌کند)
  • بدون کشف سرور روی LAN یا تیل‌نت در پنجرهٔ افزودن سرور
  • بدون مقاله‌خوان درون‌برنامه‌ای — مقاله‌های خوراک خبری در یک تب جدید باز می‌شوند
  • بدون اجرای دوبارهٔ خلاصهٔ جلسه و بدون لغو خلاصه‌ای که در حال پردازش است

دو مورد به‌جای آنکه نبود داشته باشند، متفاوت رفتار می‌کنند. ضبط جلسه در مرورگر کار می‌کند: میکروفون شما به‌علاوهٔ یک اشتراک صفحه که آهنگ صوتی دارد را می‌گیرد. باز کردن در IDE هم کار می‌کند، اما از سرور می‌خواهد که ویرایشگر را روی نمایشگر سرور اجرا کند، پس دکمه در برابر یک میزبان بدون رابط که هیچ ویرایشگری نصب ندارد خودش را پنهان می‌کند.

  • مهلت اتصال تمام می‌شود: سرور باید از سمت کلاینت قابل‌دسترسی باشد. بایند (--bind any) را بررسی کنید، اینکه پورت باز است و اینکه --public-url نشانی‌ای را نام می‌برد که کلاینت واقعاً می‌تواند شماره‌گیری کند. روی اینترنت باز، TLS اجباری است — یک بایند غیرلوپ‌بک با متن ساده در زمان راه‌اندازی رد می‌شود مگر اینکه سرور پشت یک پروکسی با --insecure اجرا شده باشد.
  • مرورگر از اتصال سر باز می‌زند اما یک کلاینت بومی کار می‌کند: مبدأ مرورگر در فهرست --allowed-origins سرور نیست. پیش‌فرض تنها https://app.usectrl.dev را مجاز می‌کند (به‌علاوهٔ لوپ‌بک).
  • کلید جفت‌سازی رد می‌شود: cc_server pair را روی سرور دوباره اجرا کنید تا کلید آن دستگاه بچرخد، سپس کلید جدید را وارد کنید. یک دستگاه ابطال‌شده اعتبارنامه‌اش را ازدست‌رفته می‌یابد و بسته شکست می‌خورد؛ ابطال یک نشست زنده را در عرض چند ثانیه می‌اندازد.
  • فضای کاری اشتباه: فضای کاری بخشی از URL است (/workspaces/:workspaceId/…) و با هر فراخوانی سفر می‌کند، پس عوض‌کردن فضای کاری در یک کلاینت فقط نمای خودتان را تغییر می‌دهد. تنها به فضاهای کاری‌ای می‌رسید که عضو آن هستید — هر چیز دیگری با «Not a member of this workspace» رد می‌شود. فضاهای کاری و ایزوله‌سازی را ببینید.