موضوع مقاله: پروتکل اصلی سیستم پنجره اکس | مخاطب: عمومی | لحن: دانشنامه‌ای | ساختار: عنوان، مقدمه، 3 بخش، جمع‌بندی | مقاله: | # پروتکل اصلی سیستم پنجره اکس | مقدمه: انگشتی|چپ|لوگوی سامانه پنجره‌ای اکس|150px پروتکل اصلی سامانه پنجره‌ای اکسRFC 1013 پایه‌ای‌ترین پروتکل در ساختار سامانه پنجره‌ای اکس است. | ## بخش 1: پروتکل اصلی سیستم پنجره اکس | سامانهٔ پنجره‌ای اکس، یک سامانه پنجره‌ای تحت شبکه برای نمایشگرهای بیت‌مپی است که برای ساختن واسط‌های گرافیکی کاربر در سیستم‌عامل‌های یونیکس، شبه یونیکس یا دیگر سیستم‌ها بکار برده می‌شود. اکس بستری را فراهم می‌کند که به‌کمک آن می‌توان نرم‌افزارهایی به همراه واسط گرافیکی (همچون میزکارهای گنوم و کی‌دی‌ئی) را بر روی این سیستم‌عامل‌ها اجرا کرده و توسعه داد. در این مدل، یک سرویس‌دهندهٔ یگانه که سرور اکس نامیده می‌شود، همهٔ سخت‌افزارهای ورودی/خروجی همانند صفحه نمایش، صفحه کلید، ماوس و ... همهٔ برنامه‌های کاربردی هم به گونهٔ سرویس‌گیرنده کار می‌کنند و با کمک سرور اکس، با کاربر یا دیگر کلاینت‌ها تعامل برقرار می‌کنند. پروتکل‌های دیگری هم در رابطه با سامانه پنجره‌ای اکس وجود دارد که این پروتکل‌ها، هم به گونهٔ یک پروتکل جدا و خودسر هستند و هم اینکه بر روی بستر پروتکل اصلی اکس ایجاد شده‌اند. درخواست‌ها یا به سرور می‌گویند که کار خاصی را انجام دهد (همچون ایجاد کردن یک پنجره تازه) یا از سرور می‌خواهند که داده‌های دلخواهی را برای کلاینت‌ها بفرستد. پاسخ‌ها از سوی سرور برای کلاینت‌ها فرستاده می‌شوند و داده‌های درخواستی کلاینت را در خود دارند که در پاسخ به درخواست کلاینت‌ها برای آن‌ها فرستاده می‌شود. رویدادها از سوی سرور برای کلاینت فرستاده می‌شوند و کلاینت را از کارهایی که کاربر سرگرم انجام‌دادن آنهاست یا رخدادهای دیگری که ممکن است کلاینت علاقه‌مند به دانستن آن‌ها باشد، باخبر می‌کنند و کلاینت می‌تواند واکنش درخور به آن رویدادها را نشان دهد. هنگامی که رویداد غیرمنتظره‌ای در هنگام پردازش کردن درخواست‌های کلاینت رخ می‌دهد و خطایی روی می‌دهد، سرور این خطاها را به کمک بسته‌هایی از نوع خطا به آگاهی کلاینت می‌رساند. درخواست‌ها ممکن است باعث تولید کردن پاسخ‌ها، رویدادها یا خطاها شوند؛ افزون بر آن، سرور اجبار نمی‌کند که بسته‌ها حتماً باید به ترتیب خاصی بر روی شبکه ارسال شوند. چندین افزونه برای پروتکل اصلی هست که هر کدام درخواست‌ها، پاسخ‌ها، رویدادها و خطاهای ویژهٔ خودشان را دارند. اینکه سامانه پنجره‌ای اکس «مکانیسم و سازوکار را مشخص می‌کند، نه خط مشی را»، اصل اولیه‌ای بود که طراحان سیستم، باب شیفلر و جیم گتیز، آن را گزیدند. در نتیجه، پروتکل اصلی، چگونگی تعامل بین کلاینت‌ها یا تعامل بین یک کلاینت با یک کاربر را تعیین نمی‌کند. کلیات انگشتی|چپ|مثالی از تعامل بین کلاینت و سرور انگشتی|راست|در این مثال، سرور اکس از یک سو با دستگاه‌های ورودی همچون ماوس و کیبورد در ارتباط است و اطلاعات ورودی را از این دستگاه‌ها دریافت می‌کند؛ و از سوی دیگر با دستگاه‌های خروجی همچون صفحه‌نمایش در ارتباط است و تصاویر خروجی را بر روی آن نمایش می‌دهد. یک مرورگر وب و یک شبیه‌ساز ترمینال هم در حال اجرا شدن بر روی رایانه کاربر هستند. در سوی دیگر و در یک رایانه که در راه دور قرار دارد، یک شبیه‌ساز ترمینال در حال اجرا شدن است. اما کنترل آن از روی رایانه کاربر انجام می‌شود، انگار که در حال اجرا شدن در همان ماشین محلی است. سرور اکس برنامه‌ایست که بر روی رایانه‌ای که دارای نمایشگر و کیبورد است، نصب می‌شود. سرور اکس درخواست‌ها را از کلاینت‌ها دریافت کرده، پس از پردازش، آن‌ها را بر روی صفحه‌نمایش (یا دیگر دستگاه‌های خروجی) نمایش می‌دهد. همچنین سرور اکس اطلاعات را از ماوس و کیبورد و دیگر دستگاه‌های ورودی دریافت کرده، آن‌ها را برای کلاینت‌ها می‌فرستد. ارتباط بین کلاینت‌ها و سرور به کمک پروتکل‌های شبکه انجام می‌شود؛ بنابراین این دو برنامه می‌توانند بر روی کامپیوترهای گوناگون که حتی سیستم‌عامل‌های ناهمسانی هم دارند، نصب شده و سپس با هم تعامل داشته باشند. ارتباط بین سرور و کلاینت‌ها با مبادله کردن بسته‌هایی بر روی یک کانال مخابراتی انجام می‌شود. اتصال از سوی کلاینت برقرار می‌شود (چگونگی آغاز به کار کلاینت در پروتکل مشخص نشده‌است). همچنین کلاینت نخستین بسته را هم می‌فرستد که این بسته، افزون بر اینکه ترتیب بایت بکاررفته را در خود دارد، اطلاعاتی دربارهٔ نسخهٔ پروتکل و چگونگی اعتبارسنجی که کلاینت دوست دارد سرور از آن استفاده کند را هم در بر می‌گیرد. سرور در پاسخ بسته‌ای را برای کلاینت می‌فرستد که این بسته مشخص می‌کند آیا سرور اتصال کلاینت را پذیرفته‌است یا اینکه آن را رد کرده‌است یا اینکه درخواستی برای اعتبارسنجی کلاینت را به همراه دارد. اگر سرور اتصال را پذیرفته باشد، بسته، داده‌هایی در خود دارد که کلاینت باید در کنش‌های آینده با سرور، آن‌ها را بکار برد. پس از اینکه اتصال برپا شد، چهار گونه بسته در کانال ارتباطی بین سرور و کلاینت جابجا می‌شود: درخواست: کلاینت اطلاعاتی را از سرور درخواست می‌کند یا اینکه از سرور می‌خواهد تا کاری را انجام دهد. رویداد: سرور کلاینت را از رخ دادن رویدادی آگاه می‌کند، همچون ورودی ماوس یا صفحه کلید، جابجا شدن یک پنجره، تغییر اندازه آن و دیگر چیزها. از آنجایی که درخواست‌ها در یک صف جاداده می‌شوند، خطایی که برای یک درخواست فرستاده می‌شود ممکن است بی‌درنگ فرستاده نشوند و دیرکردی در کار باشد. همینکه سرور بسته‌های «درخواست» را دریافت کرد، آن‌ها را به ترتیب شماره‌گذاری می‌کند. به نخستین درخواستی که از سوی کلاینت فرستاده می‌شود، شماره ۱ واگذار می‌شود، دومین درخواست شماره ۲ و همینگونه تا به پایان. اگر درخواستی، یک پاسخ یا یک خطا را به بار آورد، ۱۶ بیت کم‌ارزش از شماره‌ای که به آن درخواست داده شده، در آن بستهٔ «پاسخ» یا «خطا» گنجانده می‌شود تا مشخص باشد که این «پاسخ» یا «خطا» برای کدام درخواست است. این بیت‌ها همچنین در بسته‌های «رویداد» هم برای نشان دادن شمارهٔ درخواستی که سرور سرگرم پردازش آن است یا پردازش آن را به پایان رسانده، گنجانده می‌شوند. شماره یک پنجره ریشه را نشان می‌دهد که سرتاسر صفحه را در بر گرفته است، ۲ و ۳ پنجره‌های سطح بالا هستند، ۴ و ۵ زیرپنجره‌های پنجره شماره ۲ هستند. همچنین اصطلاح پنجره برای نامیدن پنجره‌هایی که در درون یک پنجره دیگر جای دارند هم بکار می‌رود. عناصر گرافیکی همچون دکمه‌ها، منوها، آیکون‌ها و دیگر چیزها، می‌توانند به‌دست زیرپنجره‌ها محقق شوند. همچنین کلاینت می‌تواند درخواست کند که یک زیرپنجره در درون پنجره‌ای که از پیش وجود دارد، ساخته شود. در نتیجه، پنجره‌هایی که به‌دست کلاینت‌ها ساخته می‌شوند، در یک ساختار درختی و به گونهٔ سلسله‌مراتبی، چیده می‌شوند. پنجره ریشه یک پنجرهٔ ویژه است و در هنگام آغاز به کار سیستم به گونه خودکار به‌دست سرور ساخته می‌شود. از دید ظاهری، پنجره ریشه به بزرگی یک دسکتاپ مجازی است و در پشت همه پنجره‌های دیگر نهفته می‌شود. درون‌مایهٔ یک پنجره می‌تواند با جابجا شدن پنجره، تغییر اندازه دادن پنجره، گذاشتن پنجره‌های دیگر بر روی آن پنجره، یا ... کلاینت می‌تواند از سرور بخواهد که چنین انباره‌ای را از درون‌مایهٔ یک پنجره نگه‌داری کند، اما سرور تعهد و ضمانتی برای انجام این کار ندارد. در نتیجه، کلاینت‌ها نمی‌توانند چنین بپندارند که سرور یک انباره پشتیبان برای یک پنجره را نگه‌داری می‌کند. اگر بخش نمایان یک پنجره، درون‌مایهٔ نامشخصی داشته باشد، رویدادی برای کلاینت فرستاده می‌شود و او را آگاه می‌کند که درون‌مایهٔ پنجره باید دوباره ترسیم شوند. همانند ژئومتری (اندازه پنجره و جای آن بر روی صفحه)، تصویر پس‌زمینه آن، اینکه آیا انباره پشتیبان برای آن نگهداری می‌شود یا نه و صفت‌های دیگر. تعدادی درخواست برای بررسی کردن این صفت‌ها و تغییر دادن آن‌ها در پروتکل تعبیه شده‌است. قاب زینتی و نوار عنوان پنجره‌ها (که می‌تواند شامل شماری دکمه هم باشد) که گرداگرد پنجره‌ها دیده می‌شود، به‌دست برنامه‌ای ویژه به نام مدیر پنجره رسم می‌شود، نه به‌دست کلاینتی که پنجره را ساخته و صاحب آن است. برای نمونه، هنگامی که کاربر با نشانگر ماوس بر روی قاب پنجره کلیک می‌کند و آن را تغییر اندازه می‌دهد، در واقع این مدیر پنجره است که پنجره را کوچک و بزرگ می‌کند و آن را تغییر اندازه می‌دهد. کلاینت‌ها معمولاً بدون توجه و در نظر گرفتن تغییرات انجام شده به‌دست مدیر پنجره، بر روی پنجره‌هایی که ساخته‌اند به فعالیت می‌پردازند. مدیر پنجره‌های ری-پرنتینگRe-parenting پس از ساختن یک پنجره سطح بالا، پدر این پنجره تازه‌ایجادشده را به پنجره‌ای جز پنجرهٔ ریشه، که برای همین منظور در نظر گرفته شده، تغییر می‌دهند. از دید پروتکل، مدیر پنجره هم تنها یک کلاینت است و با کلاینت‌های دیگر فرقی ندارد. با فرستادن آرگومان خط فرمانی -tree به این برنامه، می‌توان درخت زیرپنجره‌های یک پنجره را به همراه شناسه‌ها و داده‌های ژئومتری آن پنجره‌ها دید. پیکس‌مپ و ترسیم‌پذیرها یک پیکس‌مپpixmap بخشی از حافظه است که می‌توان آن را برای ترسیم کردن بکار برد. با این حال، محتوای یک پیکس‌مپ (یا بخشی از آن) می‌تواند به یک پنجره منتقل شود (یا برعکس، محتوای یک پنجره به یک پیکس‌مپ برده شود). بسیاری از عملیات‌های گرافیکی که بر روی پنجره‌ها می‌توان انجام داد، بر روی پیکس‌مپ‌ها هم انجام‌پذیر است. پنجره‌ها و پیکس‌مپ‌ها روی هم ترسیم‌پذیرdrawable نامیده می‌شوند و محتوای آن‌ها در سرور جای داده می‌شود. با این حال، یک کلاینت می‌تواند درخواست کند که محتوای یک ترسیم‌پذیر از سرور به کلاینت یا از کلاینت به سرور جابجا شود. بافت‌های گرافیکی و فونت‌ها کلاینت می‌تواند شماری عملیات گرافیکی همچون پاک‌سازی یک بخش، کپی کردن درون‌مایهٔ یک بخش به بخشی دیگر، رسم کردن نقطه، خط، مستطیل، متن و... افزون بر پاک کردن، همه این عملیات‌ها بر روی همه ترسیم‌پذیرها (پنجره و پیکس‌مپ) هم انجام‌پذیر است. یک بافت گرافیکی رنگ پیش‌زمینه، رنگ پس‌زمینه، فونت متن و دیگر پارامترهای گرافیکی را در خود دارد. در هنگام درخواست دادن یک عملیات گرافیکی، کلاینت یک بافت گرافیکی را هم به همراه درخواست خود برای سرور می‌فرستد. چنین فونت‌هایی به گونه فایل ذخیره می‌شوند و سرور به آن‌ها یا به صورت مستقیم و با سیستم فایل دسترسی دارد یا به آن‌ها به گونه غیرمستقیم و با شبکه و برنامه‌ای که سرویس‌دهنده فونتfont server نامیده می‌شود، دسترسی دارد. کلاینت‌ها می‌توانند فهرست همه فونت‌های موجود را از سرور درخواست کنند و پس از اینکه فونتی را از فهرست برگزیدند، می‌توانند از سرور بخواهند که آن فونت را بارگذاری کند (اگر هنوز بارگذاری نشده باشد) یا آن فونت را باراندازیunload کند (اگر کلاینت‌های دیگر سرگرم استفاده از آن نباشند). یک کلاینت می‌تواند اطلاعات کلی دربارهٔ یک فونت و همچنین مقدار فضایی که یک رشته متنی خاص در هنگام رسم شدن با آن فونت نیاز دارد را از سرور درخواست کند. در قرارداد توصیف منطقی فونت‌های اکس چگونگی نام‌گذاری فونت‌ها بر اساس خصوتیاتشان مشخص شده‌است. این قرارداد همچنین مقادیر دلخواهی که می‌توانند به فونت‌ها چسبیده شوند را هم مشخص می‌کنند. فونت‌های سمت کلاینت به‌دست خود کلاینت رندر می‌شوند و سرور آن‌ها را رندر نمی‌کند. شناسه‌ها، اعداد صحیحی هستند که به یک شی داده می‌شوند و به عنوان نام آن شی بکار برده می‌شوند. برای نمونه، اگر یک کلاینت بخواهد که پنجره تازه رسم شود، شناسه آن پنجره را، به همراه درخواستی برای ساختن یک پنجره نو، برای سرور می‌فرستد. کلاینت پس از آن می‌تواند این شناسه را بکار برده و برای نمونه، از سرور بخواهد که رشته‌ای متنی را در آن پنجره چاپ کند. اشیاء زیر در سرور قرار دارند و کلاینت آن‌ها را با یک شناسه عددی می‌شناسد: پنجره پیکس‌مپ فونت رنگ‌نگاشت (جدولی از رنگ‌ها، بعداً تشریح می‌شود) بافت گرافیکی این اشیاء، منبعresource نامیده می‌شوند. هنگامی که کلاینت درخواست ساختن یک چنین منبعی را می‌دهد، شناسه آن را هم مشخص می‌کند. برای نمونه، برای ساختن یک پنجره تازه، کلاینت هم صفات پنجره، همچون پنجره ودر، درازا، پهنا و... هر کلاینت، مجموعه شناسه‌های ویژه خود را دارد که می‌تواند برای ساختن اشیاء آن‌ها را بکار برد. سرور این مجموعه شناسه را با جای دادن دو عدد صحیح در بسته پذیرش (همان بسته‌ای که سرور در آغاز کار در پاسخ به کلاینت برای ایجاد اتصال جدید، برای او می‌فرستد) مشخص می‌کند. | ## بخش 2: پروتکل اصلی سیستم پنجره اکس | کلاینت شناسه‌های خود را به گونه‌ای از این مجموعه گزینش می‌کند که برخوردی پیش نیاید: در بین پنجره‌ها، پیکس‌مپ‌ها، فونت‌ها، رنگ‌نگاشت‌ها و بافت‌های گرافیکی، دو شی دارای شناسه یکسانی نباشند. پس از اینکه یک منبع ساخته شد، کلاینت می‌تواند با شناسه آن منبع، از سرور درخواست کند که کاری را بر روی آن منبع انجام دهد. برخی از درخواست‌ها، بر روی منبع تأثیرگذار هستند و ممکن است آن منبع را دگرگون کنند (برای نمونه، درخواست جابجا کردن یک پنجره)؛ برخی دیگر، اطلاعاتی که دربارهٔ یک منبع در سرور ذخیره شده را درخواست می‌دهند (همچون درخواست برای خصوصیات یک پنجره). برای نمونه، دو پنجره گوناگون هیچگاه شناسه یکسانی ندارند، حتی اگر دو کلاینت گوناگون آن‌ها را ساخته باشند. یک کلاینت می‌تواند به اشیائی که دیگر کلاینت‌ها ساخته‌اند هم دسترسی داشته باشد، حتی اگر شناسه آن شی، بیرون از بازهٔ شناسه‌های آن کلاینت باشد. در نتیجه، دو کلاینت گوناگون که هر دو به یک سرور متصل هستند، می‌توانند از یک شناسه مشترک برای دسترسی داشتن به یک شی یکسان استفاده کنند. برای نمونه اگر کلاینتی یک شی با شناسه 0x1e00021 ساخته باشد و این عدد 0x1e00021 را به یک برنامه دیگر هم بدهد (این کار می‌تواند به هر شکل دلخواهی انجام شود، همانند ذخیره کردن این عدد در یک فایل به گونه‌ای که برنامه دیگر بتواند آن را از آن فایل بخواند)، برنامه دیگر هم می‌تواند تا بر روی همان پنجره کاری را انجام دهد. برای نمونه، برنامه گوست‌ویو در سامانه پنجره‌ای اکس از این ویژگی اینگونه بهره می‌برد: این برنامه یک زیرپنجره ساخته، سپس شناسه آن را در یک متغیر محیطی می‌گذارد، سپس برنامه گوست‌اسکریپت را فراخوانی می‌کند، سپس برنامه گوست‌اسکریپت، محتوای یک فایل پست‌اسکریپت را در این پنجره نمایش می‌دهد. رویدادها انگشتی|چپ|نمونه‌ای از یک رویداد: هنگامی که کلیدی در یک پنجره فشرده می‌شود، بسته به ماسک رویداد آن پنجره، رویدادی تولید شده و برای کلاینت فرستاده می‌شود. این ماسک رویداد را کلاینت می‌تواند تغییر داده و انتخاب کند که آیا مایل به دریافت آن رویداد است یا نه رویدادها، بسته‌هایی هستند که از سوی سرور برای کلاینت فرستاده می‌شوند، این بسته‌ها کلاینت را از رخ دادن رویدادی که ممکن است برای کلاینت جالب توجه باشد، آگاه می‌کنند. برای نمونه، هنگامی که کاربر کلیدی را فشار می‌دهد یا بر روی دکمه‌ای کلیک می‌کند، رویدادی برای کلاینت فرستاده می‌شود. برای نمونه، هنگامی که زیرپنجره‌ای در یک پنجره ساخته می‌شود، رویدادی برای آگاه کردن کلاینت از این رخداد، برای آن فرستاده می‌شود. برای نمونه، اگر کاربر هنگامی که نشانگر ماوس بر روی یک پنجره قرار دارد، روی آن پنجره کلیک کند، رویداد با آن پنجره در ارتباط خواهد بود. یک کلاینت می‌تواند از سرور بخواهد که رویدادی را برای یک کلاینت دیگر بفرستد؛ کلاینت‌ها از این ویژگی برای برقراری ارتباط با یکدیگر استفاده می‌کنند. برای نمونه، هنگامی که کلاینتی از سرور درخواست می‌کند که متن انتخاب‌شده به‌دست کاربر برایش فرستاده شود، یک چنین رویدادی ساخته می‌شود (ممکن است کاربر متن موجود در پنجره‌ای که متعلق به یک کلاینت دیگر است را انتخاب کرده باشد)؛ این رویداد، برای کلاینتی فرستاده می‌شود که پنجره حاوی متن انتخاب‌شده را اداره می‌کند. هنگامی که محتویات بخشی از یک پنجره، نابود شده و سپس دوباره نمایان می‌شود، رویدادی به نام Expose برای کلاینت فرستاده می‌شود. برای نمونه اگر یک پنجره، بر روی پنجره دیگری جای بگیرد و همه یا بخشی از آن را بپوشاند، محتوای پنجره پوشیده شده نابود خواهد شد. البته این هنگامی است که سرور انباره پشتیبان برای آن پنجره را نگه‌داری نکرده باشد. سرور تضمین نمی‌کند که حتماً یک انباره پشتیبان نگه‌داری می‌کند، اما تضمین می‌کند که هر گاه نیاز به ترسیم دوباره محتوای یک پنجره بود، رویدادی را برای کلاینت بفرستد. بسیاری از رویدادها تنها هنگامی برای کلاینت فرستاده می‌شوند که کلاینت از پیش آمادگی خود را برای دریافت آن‌ها اعلام کرده باشد و مایل به دریافت آن رویدادها بوده باشد. دلیل این کار این است که شاید تنها چند گونه رویداد خاص برای برخی از کلاینت‌ها جالب توجه باشد و کلاینت‌ها نخواهند به همه آن‌ها پاسخ دهند. برای نمونه، یک کلاینت ممکن است تنها بخواهد از رویدادهای صفحه‌کلید آگاه شود و علاقه‌ای به رویدادهای ماوس نداشته باشد. با این حال، رویدادهایی هستند که حتی اگر کلاینت از پیش آمادگی خود را برای دریافت آن‌ها نشان نداده باشد، باز هم برای کلاینت فرستاده می‌شوند. کلاینت‌ها با تنظیم کردن یکی از خصوصیات پنجره، مشخص می‌کنند که علاقه‌مند به دریافت کردن چه رویدادهایی هستند. برای نمونه، برای ترسیم دوباره پنجره‌ای که محتوای آن نابود شده، کلاینت باید رویداد Expose را دریافت و پذیرش کند (این رویداد برای همین کار در نظر گرفته شده و کلاینت را آگاه می‌کند که محتوای پنجره نیازمند ترسیم دوباره است). با این حال، این رویداد تنها هنگامی برای کلاینت فرستاده می‌شود که کلاینت از پیش اعلام کرده باشد که می‌خواهد آن را دریافت کند. آن‌ها حتی می‌توانند ماسک رویداد آن پنجره را به گونهٔ متفاوتی مقداردهی کنند و بدین گونه، هر کدام رویدادهای گوناگونی را دریافت کنند. برای نمونه، یک کلاینت شاید بخواهد تنها رویدادهای مرتبط با صفحه‌کلیدی که برای یک پنجره رخ می‌دهد را دریافت کند، در حالی که کلاینت دیگر دوست دارد تنها رویدادهای مرتبط با ماوس برای همان پنجره را دریافت کند. این کار برای این شدنی است که سرور برای هر پنجره، ماسک رویداد جداگانه‌ای را به ازای هر کلاینت نگه‌داری می‌کند. با این حال، برخی از رویدادها تنها می‌توانند در هر زمان به‌دست یک کلاینت دریافت شوند و کلاینت‌های دیگر نمی‌توانند همزمان همان رویداد را دریافت کنند. این رویدادها، گزارش‌هایی را دربارهٔ کلیک کردن دکمه‌های ماوس و همچنین تغییرات مرتبط با مدیریت پنجره را می‌فرستند. نمونه در ادامه نمونه‌ای از چگونگی تعامل و برپایی ارتباط بین یک کلاینت و سرور را مرور می‌کنیم. در این نمونه، کلاینت یک پنجره می‌سازد که جعبه‌ای سیاه‌رنگ در آن جای دارد، برنامه همین که یک کلید فشرده شد، خارج می‌شود. در این مثال، سرور هیچ پاسخی به سوی کلاینت نمی‌فرستد، چرا که درخواست‌های کلاینت پاسخی را در پی ندارند. اما این درخواست‌ها می‌توانند باعث رخ دادن یک خطا شوند: کلاینت اتصال تازه‌ای را با سرور ایجاد کرده و بسته آغازین را برای سرور می‌فرستد. سرور با فرستادن یک بسته مناسب برای کلاینت، اتصال را می‌پذیرد (در این مثال نیازی به اعتبارسنجی و احراز هویت نیست). (در این مثال، کلاینت شناسه پنجره ریشه که 0x0000002b بود را به عنوان پنجره پدر مشخص می‌کند، شناسه خود پنجره سطح بالا را 0x00200001 در نظر می‌گیرد، اندازه پنجره را ۲۰۰ در ۲۰۰ پیکسل مشخص می‌کند و از سرور می‌خواهد تا این پنجره را در مختصات (۱۰٫۱۰) رسم کند). اگر این رویدادها رخ دادند، سرور با فرستادن یک بسته مناسب، کلاینت را آگاه می‌کند. کلاینت از سرور می‌خواهد تا پنجره‌ای که شناسه آن 0x00200001 است بر روی صفحه نقش شود (بر روی صفحه نشان داده شود). وقتی که پنجره بر روی صفحه نمایان شد و نیاز به ترسیم محتوای آن بود، سرور رویداد Expose را برای کلاینت می‌فرستد. اگر پنجره دیگری بر روی پنجره جای گیرد و دوباره از روی آن برداشته شود، با فرض اینکه انباره پشتیبان نگه‌داری نشده باشد: سرور یک رویداد Expose دیگر ارسال می‌کند تا به کلاینت بگوید که محتوای پنجره باید دوباره رسم شوند. اگر کلیدی فشرده شود: سرور یک رویداد KeyPress برای کلاینت می‌فرستد تا او را از فشرده‌شدن کلیدی آگاه کند. (در این مثال، به اجرای خودش خاتمه خواهد داد) رنگ‌ها در سطح پروتکل، رنگ‌ها به شکل اعداد صحیح ۳۲ بیتی بدون علامت نمایش می‌یابند که pixelvalue نامیده می‌شوند. عناصر زیر بر روی نمایش رنگ‌ها تأثیر دارند: عمق رنگ رنگ‌نگاشتcolormap که جدولی است که شدت رنگ‌های آبی، قرمز، سبز در آن مشخص می‌شود. در ساده‌ترین حالت، رنگ‌نگاشت جدولی است که هر سطر آن حاوی یک سه‌تایی آرجی‌بی است. دو کلاس بصری باقی‌مانده با کلاس‌هایی که در بالا معرفی شدند متفاوت هستند، چرا که آن‌ها pixelvalueها را به سه قسمت تقسیم می‌کنند و برای تعیین کردن شدت رنگ‌های آبی، قرمز و سبز، از سه جدول مجزا برای هر کدام استفاده می‌کنند. هر کدام از این سه دسته بیت، به صورت یک عدد صحیح درمی‌آید و سپس از این عدد صحیح به عنوان یک اندیس، برای پیدا کردن یک مقدار در یکی از آن سه جدول مجزا، مورد استفاده قرار می‌گیرد. این سازوکار نیازمند آن است که رنگ‌نگاشت از سه جدول مجزا تشکیل شده باشد و به ازای هر رنگ اولیه، یک جدول مجزا وجود داشته باشد. نتیجه این تبدیل، همچنان یک سه‌تایی از مقادیری است که مشخص‌کننده شدت رنگ‌ها هستند. یک گونه بصری، حاوی یک کلاس بصری و دیگر پارامترهای مورد نیاز برای نمایش رنگ‌هاست. هر سرور یک دسته ثابت از گونه‌های بصری دارد که هر کدام شناسه عددی مخصوص به خود را دارند. وقتی که اتصال یک کلاینت توسط سرور پذیرفته می‌شود، بسته پذیرشی که از طرف سرور برای کلاینت ارسال می‌شود حاوی دنباله‌ای از بلاک‌هاست که هر کدام از این بلاک‌ها، حاوی اطلاعاتی دربارهٔ یک صفحه‌نمایش هستند. بلاک متناظر با هر صفحه‌نمایش، حاوی فهرستی از بلاک‌های دیگر است که هر کدام از این بلاک‌ها، مربوط به عمق رنگ خاصی است که توسط آن صفحه‌نمایش پشتیبانی می‌شود. این فهرست، به ازای هر یک از عمق رنگ‌های مورد پشتیبانی، حاوی فهرستی از گونه‌های بصری است. در نتیجه، هر صفحه نمایش تعدادی عمق رنگ دارد که هر کدام از این عمق رنگ‌ها، دارای چند گونه بصری هستند. هر گونه بصری را می‌توان برای چندین صفحه‌نمایش با عمق‌های مختلف مورد استفاده قرار داد. بسته پذیرش به ازای هر گونه بصری، هم حاوی شناسه آن گونه بصری هست و هم حاوی پارامترهای واقعی که در آن گونه بصری وجود دارد (کلاس بصری و موارد دیگر). کلاینت‌ها این اطلاعات را در خود ذخیره می‌کنند، چرا که بعداً نمی‌توانند آن‌ها را درخواست دهد. علاوه بر آن، کلاینت‌ها نمی‌توانند گونه‌های بصری را تغییر داده یا گونه‌های بصری جدید ایجاد کنند. درخواستی که برای ایجاد کردن یک پنجره جدید برای سرور ارسال می‌شود، حاوی عمق و شناسه گونه بصری‌ای است که باید برای نمایش دادن رنگ‌ها در آن پنجره، مورد استفاده قرار گیرد. رنگ‌نگاشت‌ها بدون توجه به اینکه سخت‌افزاری که صفحه نمایش را کنترل می‌کند (همانند کارت گرافیک) از یک پالت استفاده می‌کند یا نه، بکار برده می‌شوند. حتی اگر سخت‌افزار از یک پالت استفاده نکند، سرورهاباز هم از رنگ‌نگاشت‌ها استفاده می‌کنند. هنگامی که سخت‌افزار از پالت بهره می‌برد، می‌توان تنها شمار محدودی از رنگ‌نگاشت‌ها را بکار گرفت. یک رنگ‌نگاشت هنگامی به کار گرفته می‌شود که سخت‌افزار بر طبق آن رنگ‌ها را نشان می‌دهد. به لطف این خصیصه رنگ‌نگاشت‌های استاندارد، برنامه‌های مختلف می‌توانند آن‌ها را بکار گیرند. سازندگان پروتکل، اتم‌ها را به این دلیل معرفی کردند، که اتم‌ها رشته‌ها را به شکلی کوتاه و با اندازه‌ای ثابت نمایش می‌دهند. در حالی که یک رشته می‌تواند طول دلخواهی داشته باشد، یک اتم همیشه اندازه ثابت ۳۲ بیتی دارد. در مواردی که بسته‌هایی با یک رشته یکسان باید به صورت چند باره فرستاده شود، می‌توان با اتم‌ها، از شبکه به گونه بهینه‌تر سود جست. بسته‌های نوع رویداد که اندازه ثابت ۳۲ بایتی دارند، می‌توانند اتم‌ها را در خود جای دهند، اما ممکن است یک رشته متنی به اندازه‌ای بزرگ باشد که نتوان آن را در بسته‌های رویداد گنجاند. به گونه دقیقتر می‌توان گفت که اتم‌ها، شناسه‌هایی برای رشته‌هایی که در سرور ذخیره شده‌اند، هستند. یکی اینکه شناسه اتم‌ها به‌دست سرور گزیده می‌شود و کلاینت در گزینش آن‌ها نقشی ندارد. به عبارتی دیگر، هنگامی که کلاینت درخواست ساختن یک اتم تازه را می‌دهد، تنها رشته‌ای که قرار است ذخیره شود را برای سرور می‌فرستد، نه شناسه آن اتم را. پس از اینکه یک اتم ساخته شد، نام آن را نمی‌توان تغییر داد و دو اتم هم نمی‌توانند نام یکسانی داشته باشند. یک کلاینت، هم می‌تواند از سرور درخواست کند که یک اتم تازه بسازد و هم می‌تواند با دادن یک رشته به سرور، شناسه اتم آن را دریافت کند. یکی از رایج‌ترین استفاده از اتم‌ها، برقرار کردن ارتباط بین دو یا چند کلاینت است که همگی به یک سرور یکسان متصل شده‌اند. | ## بخش 3: پروتکل اصلی سیستم پنجره اکس | این برنامه برای هر اتم، شناسه آن (که یک عدد است) و نام آن (که یک رشته است) را چاپ می‌کند. ویژگی‌ها، اطلاعاتی دربارهٔ یک پنجره هستند، مانند اندازه، مکان، رنگ پس‌زمینه و دیگر جیزها. خصیصه‌ها همانند متغیرها در زبان‌های برنامه‌نویسی دستوری هستند، که یک کلاینت می‌تواند خصیصه تازه‌ای را با نام و نوع دلخواه ساخته و مقداری را در آن بگذارد. خصیصه‌ها مخصوص همان پنجره هستند: دو خصیصه همنام می‌تواند در دو پنجره گوناگون وجود داشته باشد، در حالی که مقدار و نوع آن‌ها با یکدیگر ناهمسان است. رشته‌ها در سرور ذخیره شده و کلاینت می‌تواند با شناسه‌ها به آن‌ها دسترسی داشته باشد. یک کلاینت می‌تواند با شناسهٔ اتمی که دربرگیرنده نام یک خصیصه است، به آن خصیصه دسترسی داشته باشد. برای نمونه، یک خصیصه به نام WM_NAME (این خصیصه توسط اتمی که رشته اختصاص یافته به آن "WM_NAME" است نامگذاری شده‌است) هست که برای ذخیره کردن نام پنجره‌ها بکار برده می‌شود. مدیر پنجره‌ها معمولاً این خصیصه را می‌خوانند و سپس آن را در نوار عنوان پنجره نمایش می‌دهند. برای نمونه، بر پایه مشخصاتی که فری‌دسکتاپ برای مدیر پنجره‌ها تعریف کرده، مدیر پنجره‌ها باید شناسه پنجره‌ای که هم‌اکنون فعال است و فوکوس را در اختیار دارد را در یکی از خصیصه‌های پنجره ریشه به نام _NET_ACTIVE_WINDOW ذخیره کنند. به این گونه، همه کلاینت‌ها می‌توانند به این خصیصه‌ها دسترسی داشته باشند، حتی اگر این کلاینت‌ها بر روی رایانه‌های گوناگون اجرا شوند. در سامانه پنجره‌ای اکس، هر کلیدی که بر روی دستگاه‌های ورودی از جمله ماوس و کیبورد وجود دارد، یک عدد منحصربفرد مابین ۸ تا ۲۵۵ دارد که به آن keycode می‌گویند. وضعیت کنونی اصلاح‌گرها (شیفت، کنترل و ...) و دکمه‌های ماوس راست|انگشتی|400px|چگونگی ترجمه شدن یک keycode به یک keysym بنابراین سرور keycode و وضعیت اصلاح‌گرها را بدون اینکه تلاش کند خود آن‌ها را به یک کاراکتر ویژه ترجمه کند، برای کلاینت می‌فرستد و وظیفه ترجمه و تفسیر آن‌ها را بر دوش کلاینت واگذار می‌کند. برای نمونه، یک کلاینت ممکن است رویدادی مبنی بر اینکه یک کلید ویژه در حالی فشرده شده‌است که دکمه شیفت هم پایین نگه داشته شده، دریافت کند. اگر در حالت معمول این کلید خاص، کاراکتر 'a' را تولید می‌کرده، کلاینت (و نه سرور) این رویداد را به منزله وارد شدن کاراکتر 'A' تلقی می‌کند. ذخیره کردن این جدول در سرور که یک جای عمومی و مرکزی است، این امکان را فراهم می‌کند تا همه کلاینت‌ها بتوانند به آن دسترسی داشته باشند. یک اصلاح‌گر کلیدی است که هنگامی فشرده می‌شود، چگونگی تفسیر شدن کلیدها را تغییر می‌دهد. وقتی کلیدی که در حالت معمول کاراکتر 'a' را تولید می‌کند، به همراه کلید شیفت فشرده می‌شود، باعث تولید شدن یک کاراکتر بزرگ 'A' می‌شود. این کار بایسته است، چرا که بیشتر کیبوردها دو کلید برای برخی از اصلاح‌گرها دارند. برای نمونه، بیشتر کیبوردها دو کلید شیفت دارند (یکی در سمت چپ و دیگری در سمت راست). این دو کلید، در هنگام فشرده‌شدن هر کدام keycode ویژه و متفاوت از یکدیگری را تولید می‌کنند، اما سرور اکس هر دو آن‌ها را به عنوان اصلاح‌گر شیفت می‌شناسد. سرور اکس برای هر کدام از این هشت اصلاح‌گر، فهرستی از keycodeها را نگه می‌دارد که آن‌ها را به عنوان آن اصلاح‌گر تفسیر می‌کند. برای نمونه، اگر در فهرست اولین اصلاح‌گر (اصلاح‌گر شیفت)، یک kecode با مقدار 0x37 وجود داشته باشد، آنگاه سرور کلیدی که باعث تولید شدن keycodeای با مقدار 0x37 می‌شود را به عنوان یک کلید شیفت در نظر می‌گیرد. هرچند که فهرست‌های مربوط به نگاشت کردن اصلاح‌گرها در سرور نگهداری می‌شود، اما هر کلاینتی می‌تواند آن‌ها را به خواست خود تغییر دهد. برای نمونه، یک کلاینت می‌تواند درخواست دهد که کلید F1 به فهرست اصلاح‌گر شیفت افزوده شود. در نتیجه، F1 همانگونه کار می‌کند که پیش از آن کار می‌کرده (برای نمونه ممکن است یک پنجره Help در هنگام فشرده شدن F1 باز شود)، اما همچنین به عنوان یک کلید شیفت هم کار می‌کند (برای نمونه فشردن کلید 'a' به همراه F1 می‌تواند باعث تولید شدن یک کاراکتر 'A' در یک ویرایشگر متن شود). این کار به ویژه برای تعویض کردن دکمه‌های چپ و راست برای استفاده آسان‌تر توسط افراد راست‌دست و چپ‌دست سودمند است. قاپیدن رویدادها انگشتی|چپ|450px|اگر مکان‌نما یا کیبورد فریز شده باشد، رویدادها همچنان تولید می‌شود، اما در یک صف ذخیره می‌شوند تا وقتی که از حالت فریز خارج شوند و آنگاه برای کلاینت مورد نظر ارسال می‌شوند. اگر آنها گرب شده باشند، رویدادهای مرتبط با آنها به جای اینکه برای پنجره‌ای که در حالت عادی آنها را دریافت می‌کند، ارسال شود، برای کلاینتی که گرب را در اختیار دارد ارسال می‌شود. قاپیدن رویدادهاGrab وضعیتی است که در آن تمام رویدادهای مرتبط با کیبورد و ماوس، تنها برای یک کلاینت خاص ارسال می‌شود. به عبارت دیگر، یک کلاینت رویدادهایی که در اصل برای کلاینت‌های دیگر هستند را از آن‌ها می‌قاپد. یک کلاینت می‌تواند درخواست قاپیدن رویدادهای کیبورد، ماوس یا هر دو را از سرور درخواست کند. اگر سرور درخواست کلاینت را برآورده سازد، آنگاه تمام رویدادهای مرتبط با ماوس/کیبورد، برای آن کلاینت ارسال می‌شود؛ تا وقتی که کلاینت grab را رها کند. در این حالت، تمام رویدادها طوری برای کلاینت ارسال می‌شوند که انگار مرتبط با آن پنجره هستند. با این حال دیگر کلاینت‌ها هیچ رویدادی را دریافت نمی‌کنند، حتی اگر آن رویدادها را در پنجره قاپیدن انتخاب کرده باشند. پسیو: تنها زمانی صورت می‌گیرد که یک کلید خاص از کیبورد یا یک دکمه خاص از ماوس (که از قبل تعیین شده) فشرده شود و وقتی که کلید رها شد، قاپیدن رویدادها هم پایان می‌یابد. کلاینت‌ها می‌توانند بر روی کیبورد، مکان‌نما، یا هر دو آن‌ها درخواست قاپیدن رویدادها را بکنند. تفاوت گرب کردن (قاپیدن رویدادها) و فریز کردن در این است که در گرب، گیرندهٔ رویدادها تغییر می‌کند و رویدادها به کلاینتی غیر از کلاینت اصلی‌شان تحویل داده می‌شوند، در حالی که فریز کردن باعث می‌شود تا رویدادها به هیچ گیرنده‌ای تحویل داده نشوند. وقتی که دستگاهی فریز می‌شود، رویدادهایی که آن دستگاه تولید می‌کند در یک صف ذخیره می‌شوند تا بعدها پس از اتمام شدن عمل فریز، به گیرنده تحویل داده شوند. پارامتر دیگری هم در رابطه با رویدادهای مکان‌نما وجود دارد که در تحویل دادن رویدادها مؤثر است: ماسک رویداد، که مشخص می‌کند چه نوع رویدادهایی باید تحویل داده شوند و از چه نوع رویدادهایی باید صرف نظر شود. برخی دیگر از درخواست‌ها، دربارهٔ انتخاب‌هاSelections هستند، با این حال، بیشتر این درخواست‌ها به‌دست پروتکل‌های دیگری جز پروتکل اصلی تعریف و مشخص می‌شوند. همچنین یک کلاینت می‌تواند درخواست دهد مالک یک منبع (پنجره، pixmap و ...)، از بین برود که خود باعث از بین رفتن ارتباط سرور با آن می‌شود. اضافات و افزونه‌ها انگشتی|چپ|افزونه shape به پنجره ساعت اجازه می‌دهد تا یک پنجره گرد و مدور ایجاد کند که فاقد قاب و نوار عنوان است. این پروتکل سازوکاری را فراهم می‌کند که یک کلاینت به کمک آن می‌تواند از وجود داشتن یک افزونه مطمئن شود. همچنین پروتکل اصلی، چگونگی ساخته شدن بسته‌های درخواست، رویداد و خطایی که متعلق به یک افزونه هستند را هم مشخص می‌کند. یک کلاینت می‌تواند برای داده‌هایی که وابسته و مرتبط به یک افزونه دلخواه هستند، فهرست همه افزونه‌های موجود را درخواست کند. پروتکل اصلی، مشخص می‌کند که بسته‌های نوع درخواست، رویداد یا خطا، باید دربرگیرنده یک عدد صحیح باشند که این عدد صحیح، نوع آن بسته را مشخص می‌کند (برای نمونه، درخواست‌هایی که برای ساختن یک پنجره تازه بکار می‌روند، با عدد ۱ شماره‌گذاری می‌شوند). اعتبارسنجی و تأیید هویت در ابتدا، وقتی که کلاینت می‌خواهد ارتباطی را با سرور برقرار کند، سرور می‌تواند ارتباط را بپذیرد، آن را رد کند، یا کلاینت را اعتبارسنجی کند و در صورت تأیید شدن هویت کلاینت، ارتباط با آن را بپذیرد. یک درخواست اعتبارسنجی، روشی که باید برای اعتبارسنجی بکار برده شود را در خود دارد. پروتکل، مراحل انجام اعتبارسنجی را مشخص و تعریف نمی‌کند، چرا که مراحل اعتبارسنجی بستگی به روشی دارد که برای اعتبارسنجی بکار برده می‌شود، پروتکل تنها مشخص می‌کند که این فرایند، یا با فرستادن بسته پذیرش یا با فرستادن بسته عدم پذیرش از سوی سرور، پایان می‌یابد. به‌طور دقیق‌تر، یک کلاینت می‌تواند از سرور بخواهد که این روش فعال باشد یا نه، و همین‌طور می‌تواند از سرور بخواهد که فهرستی از میزبان‌هایی (کلاینت‌هایی) که مجاز به برقراری ارتباط هستند را بخواند یا تغییر دهد. برنامه‌های عادی از این‌گونه درخواست‌ها استفاده نمی‌کنند، این درخواست‌ها توسط برنامه xhost استفاده می‌شوند. این برنامه از این درخواست‌ها به این منظور استفاده می‌کند تا به یک کاربر یا یک اسکریپت، اجازه دسترسی داشتن به سرور اکس را بدهد. اکس‌لیب و دیگر کتابخانه‌های مرتبط بیشتر برنامه‌های کلاینت با استفاده از کتابخانه اکس‌لیب با سرور ارتباط برقرار می‌کنند. استفاده می‌کنند که این کتابخانه‌ها خود در واقع در سطوح پایین‌تر از اکس‌لیب برای برقراری ارتباط با سرور استفاده می‌کنند. استفاده از اکس‌لیب اثرات زیر را به‌دنبال دارد: اکس‌لیب کلاینت را نسبت به پاسخ‌ها و رویدادها همگام می‌کند: توابعی که در اکس‌لیب، درخواستی به طرف سرور ارسال می‌کنند، تا زمانی که پاسخ مناسب از طرف سرور برسد، بلوکه می‌شوند. به عبارت دیگر، کلاینتی که از اکس‌لیب استفاده نمی‌کند می‌تواند درخواستی را ارسال کند و سپس به انجام کارهای دیگری بپردازد تا وقتی که پاسخ درخواست را از سرور دریافت کند. اما کلاینتی که از اکس‌لیب استفاده می‌کند تنها می‌تواند درخواستی را برای سرور ارسال کند و منتظر رسیدن پاسخ آن درخواست بماند و از این رو کلاینتی که منتظر رسیدن پاسخ درخواستش است، بلوکه می‌شود (مگر اینکه کلاینت قبل از فراخوانی تابع، یک ریسه جدید را اجرا کرده باشد) چون سرور رویدادها را به صورت ناهمگام ارسال می‌کند، اکس‌لیب رویدادهای دریافت شده توسط کلاینت را در یک صف ذخیره می‌کند. کلاینت تنها می‌تواند با فراخوانی کردن صریح توابعی خاص در اکس‌لیب به این رویدادهای موجود در صف دسترسی داشته باشد. به عبارت دیگر، اگر کلاینت منتظر یک رویداد باشد، مجبور به بلوکه شدن یا کشیدن انتظار مشغول می‌شود. اکس‌لیب درخواست‌ها را بلافاصله برای سرور ارسال نمی‌کند، ابتدا آن‌ها را در یک صف ذخیره می‌کند که به آن بافر خروجیoutput buffer می‌گویند، سپس در یکی از حالات زیر درخواست‌های موجود در این بافر ارسال می‌شود: برنامه با فراخوانی کردن یک تابع خاص به نام XFlush صریحاً از اکس‌لیب بخواهد که این کار را انجام دهد. این کتابخانه به صف رویدادها سرکشی می‌کند و در هنگام نیاز، توابع منظور شده را اجرا می‌کند. برخی از رویدادها، همانند رویدادهایی که نیازمند ترسیم دوباره یک پنجره هستند، به گونه توکار به‌دست Xt مدیریت می‌شوند. کتابخانه‌های سطح پایین همانند XCB، دسترسی ناهمگام به پروتکل را شدنی می‌سازند، که باعث می‌شود تأخیر زمانی پنهان بماند. بخش‌های تشریح‌نشده پروتکل اصلی سامانه پنجره‌ای اکس در مورد ارتباطات بین کلاینتی حکم نمی‌کند و مشخص نمی‌کند که برای ساختن عناصر دیداری رایج در واسط‌های گرافیکی کاربر (دکمه‌ها، منوها و ...)، چگونه باید پنجره‌ها را بکار برد. این موارد، روش‌هایی هستند که یک کاربر می‌تواند آن‌ها را برای جابجا کردن داده‌ها از یک کلاینت به کلاینت دیگر بکار برد. از آنجا که پنجره‌ها ممکن است به‌دست برنامه‌های گوناگونی کنترل شوند، پروتکلی برای جابجایی این داده‌ها نیاز هست تا هماهنگی و ارتباط بین برنامه‌ها ساماندهی. مدیر پنجره‌ها برنامه‌هایی هستند که ظاهر پنجره‌ها و نما و حس کلی رابط کاربری را کنترل می‌کنند. چگونگی آغاز یک نشست کاربری، مسئله دیگری است که در پروتکل اصلی در مورد آن بحث نشده‌است. انتقادها معماری اکس به‌گونه‌ای است که کلاینت و سرور دو موجودیت جداگانه هستند که با شبکه با هم ارتباط برقرار می‌کنند، حتی اگر هر دو بر روی یک رایانه یکتا اجرا شوند. اطلاعات باید در یک سو بسته‌بندی شده، بر روی کانال مخابراتی فرستاده و سپس در سوی دیگر، از حالت بسته‌بندی بیرون آورده شود. به گونه پیش‌فرض، کلیه اطلاعات به‌صورت رمزنگاری‌نشده بر روی شبکه جابجا می‌شوند که یک مهاجم می‌تواند با شنود کردن کانال مخابره‌ای بین سرور و کلاینت، اطلاعات را کشف و ضبط کند. یک راه حل رایج برای حل این مشکل، برقرار کردن یک تونل پوسته امن بین کلاینت و سرور است. پروتکل اکس به گونه ناهمگام طراحی شده‌است که این مسئله می‌تواند در برخی موارد منجر به به وجود آمدن شرایط رقابتی در بخش‌های گوناگون سیستم شود. نداشتن رهنمود در مورد چگونگی طراحی رابط کاربری باعث به وجود آمدن رابط‌های ناسازگار شده‌است. | ## جمع‌بندی | اکس به خاطر طراحی پیچیده آن مورد انتقاد قرار گرفته‌است و همچنین برنامه‌های کاربردی ناچار هستند تا با پیچیدگی‌های سطح پایین سخت‌افزاری سروکار داشته باشند.