.TH gensio 5 01/02/19 "تعیین و مشخص کردن یک gensio" .SH "نام (NAME)" gensio \- نحوه تعیین و پیکربندی یک gensio .SH "خلاصه دستور (SYNOPSIS)" .B [(options)][,gensio|terminaloptions] .SH "توضیحات (DESCRIPTION)" .BR gensio مخفف GENeral Stream Input Output (ورودی/خروجی جریانی عمومی) است. این کتابخانه یک انتزاع (abstraction) برای انواع I/O جریانی فراهم می‌کند و حتی برخی I/Oهای بسته‌ای (مانند UDP) را به شکل I/O جریانی درمی‌آورد. به‌ویژه، gensio ایجاد اتصالات رمزگذاری‌شده و احرازهویت‌شده را آسان می‌سازد. کتابخانه .BR gensio یک اتصال (gensio) را با استفاده از یک قالب رشته‌ای (string format) مشخص می‌کند. این ساختار شامل یک نوع gensio و گزینه‌های اختیاری درون پرانتز است. برای یک gensio پایانی یا انتهایی (terminal gensio - گزینه‌ای که در پایین پشته قرار دارد)، می‌تواند گزینه‌های انتهایی (terminaloptions) بیشتری را که با کاما جدا شده‌اند دریافت کند. برای gensioهای فیلتر (آن‌هایی که در پایین پشته نیستند)، باید یک gensio دیگر پس از کاما مشخص شود. برای نمونه: .IP serialdev,/dev/ttyS0 .PP یک gensio پورت سریال را مشخص می‌کند. یا: .IP tcp(readbuf=100),localhost,4000 .PP یک اتصال TCP با بافر خواندن ۱۰۰ بایتی را برای اتصال به پورت 4000 روی localhost مشخص می‌کند. یا: .IP telnet,tcp,localhost,4000 .PP یک فیلتر telnet را روی یک اتصال TCP مشخص می‌کند. توجه داشته باشید که گزینه‌های معمولی همیشه درون پرانتز قرار می‌گیرند. تنها terminaloptions پس از کاما روی یک terminal gensio می‌آیند. هنگام تعیین یک gensio، می‌توانید از نقل‌قول‌ها (تکی یا جفتی) برای حذف معنای خاص برخی نویسه‌ها استفاده کنید تا بتوانید در گزینه‌ها و موارد مشابه کاما داشته باشید. همچنین می‌توان آن‌ها را با «\e» اسکیپ کرد. برای نمونه، اگر در حال تعیین یک laddr در آدرس sctp هستید، باید این کار را انجام دهید. آدرس زیر: .IP sctp(laddr=localhost,4001),localhost,3023 .PP به شکست منجر خواهد شد زیرا کد تجزیه گزینه، رشته را در محل کاماها جدا می‌کند. در عوض، بنویسید: .IP sctp(laddr="localhost,4001"),localhost,3023 .PP و این کار خواهد کرد. Gensioهای پذیرنده (Accepter gensios)، یعنی gensioهایی که برای پذیرش اتصالات استفاده می‌شوند، در مقابل gensioهای متصل‌شونده (connecting gensios)، به همان شیوه مشخص می‌شوند. هر نوع منفرد می‌تواند متفاوت باشد و برخی gensioها فقط اتصال‌دهنده هستند. گزینه‌ها می‌توانند بین gensioهای پذیرنده و متصل‌شونده از همان نوع تفاوت داشته باشند. برای نمونه، یک TCP gensio پذیرنده نیازی به داشتن hostname ندارد، اما نوع متصل‌شونده به آن نیاز دارد. هنگامی که یک gensio پذیرنده اتصالی دریافت می‌کند، یک gensio پذیرفته‌شده (accepted gensio) ایجاد خواهد کرد. این عمدتاً شبیه به یک gensio متصل‌شونده کار می‌کند، به جز اینکه برخی توابع ممکن است محدود باشند. ممکن است نتوانید یک gensio پذیرفته‌شده را بسته و سپس دوباره باز کنید. کتابخانه gensio دارای مفهوم کلاینت و سرور است. gensioهای پذیرفته‌شده عموماً سرور در نظر گرفته می‌شوند. gensioهای متصل‌شونده عموماً کلاینت در نظر گرفته می‌شوند. برخی gensioها ممکن است اجازه دهند این رفتار بازنویسی و لغو شود. یک gensio ممکن است قابل اعتماد (reliable) باشد یا نباشد. یک gensio قابل اعتماد تمامی داده‌ها را به ترتیب و با اطمینان تحویل می‌دهد، مانند TCP. یک gensio غیرقابل اعتماد ممکن است داده‌ها را از دست بدهد یا بدون ترتیب تحویل دهد، مانند UDP. این مورد را می‌توان با تابع .B gensio_is_reliable() استعلام کرد. یک gensio ممکن است بسته‌ای (packet) باشد یا نباشد. یک gensio بسته‌ای عملیات نوشتن و خواندن را دقیقاً تطبیق می‌دهد. بنابراین اگر ۱۵ بایت در یک سمت بنویسید، یک خواندن ۱۵ بایتی برای آن داده در سمت دیگر ظاهر خواهد شد. یک gensio غیربسته‌ای مرزهای نوشتن را رعایت نمی‌کند؛ آن نوشتن ۱۵ بایتی ممکن است منجر به چندین خواندن شود یا با نوشتن دیگری ترکیب شده و به بیش از ۱۵ بایت تبدیل شود. I/O بسته‌ای برای عملکرد صحیح نیازمند استفاده دقیق است. اگر gensio فضایی برای بسته دیگری نداشته باشد، نوشتن موفق خواهد بود اما ۰ بایت می‌نویسد. در غیر این صورت اگر بزرگتر از اندازه بسته بنویسید، تنها به تعداد بایت‌هایی که در یک بسته جا می‌شود دریافت کرده و داده کوتاه (truncate) خواهد شد. این در صورتی مفید است که بخواهید روی یک رابط بسته‌ای جریان داده برقرار کنید، اما اگر واقعاً بسته می‌خواهید باید مطمئن شوید که همه اندازه‌ها به درستی تنظیم شده‌اند. به ویژه، باید حداکثر اندازه خواندن و نوشتن را روی یک مقدار یکسان تنظیم کنید. باید در هنگام نوشتن بررسی کنید که آیا همه داده‌ها نوشته شده‌اند یا خیر. در صورت تمایل می‌توانید مدیریت خواندن جزئی (partial read) را انجام دهید، اما باقی‌مانده بسته را فقط در خواندن دوم و موارد پس از آن دریافت خواهید کرد. یک gensio ممکن است پیام‌محور (message oriented) باشد. این پیاده‌سازی از SCTP اقتباس شده است (هرچند در حال حاضر روی لینوکس به طور کامل پشتیبانی نمی‌شود). اساساً به این معنی است که می‌توانید صراحتاً هنگام ارسال داده مرزهای پیام را علامت‌گذاری کنید، و آن علامت صریح در سمت خواندن تنظیم خواهد شد. شما این کار را با افزودن auxdata با مقدار "eom" در هنگام نوشتن انجام می‌دهید؛ پایان آن نوشتن به عنوان پایان پیام فرض می‌شود. اگر نوشتن تمام داده‌ها را نپذیرد، "eom" نادیده گرفته می‌شود و باید داده‌های باقی‌مانده را دوباره با تنظیم "eom" بنویسید. همچنین می‌توانید نوشتن جزئی پیام‌ها را انجام دهید و "eom" را در انتها تنظیم کنید. در سمت دریافت، وقتی انتهای یک پیام تحویل داده شود، "eom" تنظیم خواهد شد. داده‌های تحویل داده شده در کال‌بک دریافت، تنها داده‌های مربوط به آن پیام خواهند بود. اگر کاربر تمام داده‌ها را نپذیرد، داده‌های باقی‌مانده در پیام دوباره با تنظیم "eom" به کاربر ارائه می‌شوند. گزینه‌ها بین gensioهای مختلف بسیار متغیر هستند. هر نوع gensio در یک بخش جداگانه پوشش داده خواهد شد. همچنین توجه داشته باشید که انواع gensio می‌توانند به صورت پویا توسط کاربر اضافه شوند، بنابراین ممکن است gensioهایی در دسترس باشند که در اینجا شرح داده نشده‌اند. مگر در مواردی که خلاف آن ذکر شده باشد، هر gensio گزینه زیر را می‌پذیرد: .TP .B readbuf= گزینه‌ای برای تعیین اندازه بافر خواندن. .SH "پیش‌فرض‌ها (DEFAULTS)" هر گزینه مربوط به یک gensio (از جمله گزینه‌های serialdev و ipmisol)، مگر اینکه خلاف آن ذکر شده باشد، به عنوان یک پیش‌فرض برای gensioها در دسترس است. می‌توانید از gensio_set_default() برای تنظیم مقدار پیش‌فرض استفاده‌شده توسط همه gensioهایی که پس از آن نقطه تخصیص می‌یابند استفاده کنید. اگر کلاس (class) را روی NULL بگذارید، پیش‌فرض پایه تنظیم می‌شود که بر همه gensioها تأثیر می‌گذارد مگر اینکه دارای بازنویسی باشند. اگر کلاس را تنظیم کنید، فقط بر gensioهای دارای آن نام کلاس تأثیر خواهد گذاشت. در مورد برخی پیش‌فرض‌ها بسیار مراقب باشید. برای مثال تنظیم پیش‌فرض "mode" می‌تواند واقعاً اوضاع را به هم بریزد. برای پیش‌فرض‌های رشته‌ای، تنظیم مقدار پیش‌فرض روی NULL باعث می‌شود که gensio از پیش‌فرض پشتیبان خود استفاده کند. .SH "جریان‌ها و کانال‌ها (STREAMS AND CHANNELS)" برخی gensioها از مفهوم جریان (stream) و/یا کانال (channel) پشتیبانی می‌کنند. یک جریان به عنوان بخشی از جریان داده عادی یک gensio تحویل داده می‌شود. با جریان "default" به طور معمول رفتار خواهد شد. سایر جریان‌ها دارای "stream=" در auxdata خواهند بود تا مشخص شود روی کدام جریان باید نوشته شود یا از کدام جریان خوانده شده است. جریان‌ها را نمی‌توان به صورت جداگانه کنترل جریان (flow control) کرد. یک کانال جریانی از داده‌ها مانند یک stream است، اما می‌توان آن را به طور جداگانه کنترل جریان کرد. کانال به عنوان یک gensio جدید در کال‌بک .I GENSIO\_EVENT\_NEW\_CHANNEL ظاهر می‌شود. می‌توانید با .B gensio\_alloc\_channel() یک کانال ایجاد کرده و سپس با .B gensio\_open() آن را باز کنید. پس از باز شدن، کانال مانند یک gensio عادی کار می‌کند. اگر کانال اصلی را برای یک gensio ببندید، سایر کانال‌ها باز خواهند ماند؛ منابع مربوط به کانال اصلی تا زمان بسته شدن همه کانال‌ها حفظ خواهند شد. برای اطلاعات بیشتر در مورد جریان‌ها و کانال‌ها به توضیحات مربوط به هر gensio مراجعه کنید. .SH "رمزنگاری کلید عمومی (PUBLIC KEY CRYPTOGRAPHY)" Gensioهای ssl و certauth از رمزنگاری کلید عمومی استفاده می‌کنند. این بخش نمای کلی کوتاهی از نحوه کارکرد آن ارائه می‌دهد. اگر قبلاً با این مفاهیم آشنایی دارید، می‌توانید با خیال راحت این بخش را نادیده بگیرید. رمزنگاری کلید عمومی برای احراز هویت و رمزگذاری اطلاعات در آغاز یک نشست (session) استفاده می‌شود. این یک عملیات نسبتاً سنگین است و عموماً برای رمزگذاری اطلاعات پس از شروع نشست استفاده نمی‌شود. در رمزنگاری کلید عمومی، سه مؤلفه اساسی وجود دارد: یک کلید خصوصی (private key)، یک گواهی یا کلید عمومی (certificate / public key)، و یک مرجع صدور گواهی (CA). کلید خصوصی کاملاً خصوصی است. شما حتی کلید خصوصی خود را برای امضای گواهی به مرجع صدور گواهی ارسال نمی‌کنید. آن را خصوصی و غیرقابل خواندن برای دیگران نگه دارید. از آن محافظت کنید؛ اگر فاش شود گواهی شما بی‌فایده خواهد شد و هر کسی می‌تواند خود را به جای شما جا بزند. گواهی همان کلید عمومی است و از نظر ریاضی با یک کلید خصوصی منفرد مرتبط است. این کلید عمومی است و هر کسی می‌تواند با درخواست از شما برای امضای برخی داده‌ها، بررسی کند که آیا کلید خصوصی را در اختیار دارید یا خیر. داده‌های موجود در گواهی (مانند Common Name) بخشی از گواهی هستند. اگر آن داده‌ها دستکاری شوند، اعتبارسنجی گواهی با شکست مواجه خواهد شد. مرجع CA عموماً یک شخص ثالث مورد اعتماد است که شما را اعتبارسنجی کرده و گواهی شما را (عموماً در ازای هزینه) امضا می‌کند. مراجع CA گواهی‌های عمومی خود را صادر می‌کنند که شناخته‌شده بوده و عموماً روی سیستم شما در دسترس هستند. گواهی‌های CA برای اثبات معتبر بودن گواهی شما استفاده می‌شوند. .SS "امضا کردن (SIGNING)" فرایند امضا قبلاً ذکر شد، اما تشریح نشد. اساساً، شما از کلید خصوصی خود برای تولید مقداری بر روی داده‌های مشخص استفاده می‌کنید که ثابت می‌کند کلید خصوصی را در اختیار دارید. از گواهی برای اعتبارسنجی ریاضی امضا استفاده می‌شود. معمولاً دو کار با این انجام می‌شود: در تبادل کلید عمومی، نهادی که مایل به احراز هویت است یک گواهی ارسال می‌کند. نهاد مجوزدهنده درون CA خود به دنبال گواهی‌ای می‌گردد که گواهی ارسال‌شده را امضا کرده باشد. اگر نهاد مجوزدهنده گواهی‌ای پیدا کند که بتواند برای اعتبارسنجی گواهی ارسال‌شده استفاده شود، گواهی ارسال‌شده معتبر است. پس از آن، نهاد مجوزدهنده داده‌هایی عموماً تصادفی را به نهاد دیگر ارسال می‌کند. نهاد دیگر آن داده‌ها (و شاید برخی داده‌های مهم دیگر را که می‌خواهد مطمئن شود در حین انتقال تغییر نیافته‌اند) گرفته و امضا می‌کند. سپس امضا را به نهاد مجوزدهنده بازمی‌گرداند. نهاد مجوزدهنده می‌تواند از داده‌ها و امضا برای اعتبارسنجی اینکه نهاد فرستنده کلید خصوصی مرتبط با گواهی را دارد استفاده کند. این اساساً نحوه کار https است. توجه داشته باشید که این .B کلاینت وب (web client) است که .B سرور وب (web server) را احراز هویت می‌کند، نه برعکس. این ثابت می‌کند که شما به همان نهادی که مد نظر دارید متصل می‌شوید. احراز هویت یک کلاینت وب برای سرور وب عموماً از طریق سازوکار متفاوتی انجام می‌شود (هرچند SSL/TLS مورد استفاده توسط ssl gensio روشی برای انجام آن دارد، اما معمولاً برای این منظور استفاده نمی‌شود). در سناریوی سرور وب، داده‌های درون گواهی (به ویژه Common Name و Subject Alternate Name) باید با نام صفحه وبی که به آن متصل می‌شوید مطابقت داشته باشد. Gensioهای ssl و certauth این احراز هویت را انجام نمی‌دهند؛ این کار در صورت لزوم بر عهده کاربر است. .SS "رمزگذاری (ENCRYPTING)" از گواهی می‌توان برای رمزگذاری داده‌هایی استفاده کرد که فقط با کلید خصوصی قابل رمزگشایی هستند. هنگام برقراری یک اتصال رمزگذاری‌شده، این سازوکار معمولاً برای انتقال یک کلید رمزنگاری متقارن از یک نهاد به نهاد دیگر (نهاد مجوزدهنده به نهاد درخواست‌کننده در مورد بالا) استفاده می‌شود. شما می‌توانید تمام داده‌ها را با کلید عمومی رمزگذاری کنید، اما این کار بسیار سنگین است و در مثال بالا نیازمند گواهی‌ها و کلیدهای خصوصی در هر دو طرف است. .SS "گواهی‌های خودامضا (SELF-SIGNED CERTIFICATES)" امکان ایجاد گواهی‌ای وجود دارد که بتواند به عنوان مرجع صدور گواهی خود عمل کند. این روش کارکرد ssh است. شما یک کلید عمومی و خصوصی ایجاد می‌کنید. کلید عمومی را در مسیر .ssh/authorized_keys روی سیستم‌هایی که می‌خواهید به آن‌ها وارد شوید قرار می‌دهید. گواهی هم به عنوان کلید عمومی (به عنوان بخشی از انتقال اولیه) و هم به عنوان CA (در دایرکتوری authorized_keys) برای مجاز کردن استفاده شما از سیستمی که به آن وارد می‌شوید عمل می‌کند. ابزار ssh همچنین مکان‌هایی را که به آن‌ها متصل شده است در .ssh/known_hosts ذخیره می‌کند که همان CA در جهت مخالف است. به همین دلیل است که اگر قبلاً هرگز به سیستمی متصل نشده باشید از شما سؤال می‌پرسد، زیرا کلید را در CA خود ندارد. یا به همین دلیل اگر به سیستمی متصل شوید که قبلاً متصل شده بودید و گواهی‌ها مطابقت نداشته باشند یا اعتبارسنجی با شکست مواجه شود، هشدار می‌دهد. بنابراین اگر از گواهی‌های خودامضا استفاده می‌کنید، باید مراقب باشید که فقط مواردی را که به آن‌ها اعتماد دارید در CA قرار دهید. این امر بدیهی است که در یک سیستم بزرگ مانند وب جهان‌گستر امکان‌پذیر نیست، از این رو مراجع CA شخص ثالث معتبر ایجاد شده‌اند. .SS "اعتماد و رمزنگاری (TRUST AND CRYPTOGRAPHY)" مباحث فوق چندین بار به اعتماد اشاره کردند. رمزنگاری نیاز به اعتماد را از بین نمی‌برد، بلکه فقط اعتماد را ساده‌تر و راحت‌تر می‌سازد. اگر کسی برای شما گواهی ارسال کرد، باید تأیید کنید که در واقع او بوده که گواهی را ارسال کرده و در حین انتقال دستکاری نشده است. اگر آن گواهی را به CA خود اضافه کنید، به گواهی اعتماد کرده‌اید و بهتر است مطمئن شوید (عموماً با اثرانگشت‌ها یا fingerprints، برای جزئیات به اسناد openssl مراجعه کنید) که از یک نهاد مورد اعتماد آمده است. سخت‌ترین بخش رمزنگاری به طور کلی مدیریت کلید است. شکستن الگوریتم‌های رمزنگاری بسیار دشوار است؛ ترغیب افراد به افشای کلیدهای خصوصی یا استفاده از کلیدهای اشتباه بسیار آسان‌تر است. برای اطلاعات بیشتر در مورد رمزنگاری به طور کلی، و رمزنگاری و اعتماد، بروس اشنایر (Bruce Schneier) کتاب‌های بسیار عالی در این زمینه دارد. .SH "IPv6، IPv4 و نام‌های میزبان (IPv6, IPv4, and host names)" توجه داشته باشید که یک نام میزبان واحد ممکن است منجر به بیش از یک آدرس شود. برای نمونه، ممکن است هم آدرس IPv4 و هم IPv6 داشته باشد. با این‌ها دقیقاً مانند چندین نام میزبان رفتار می‌شود. به عنوان مثال، اگر از localhost به عنوان نام میزبان استفاده کنید، عموماً هر دو نسخه IPv4 و IPv6 را دریافت می‌کنید: .IP $ gensiot -a -p tcp,localhost,1234 .br Address 0(0): ipv6,::1,1234 .br Address 1(0): ipv4,127.0.0.1,1234 .PP نام میزبان می‌تواند با پیشوند ipv4 یا ipv6 همراه باشد که اتصالات را به آن پروتکل‌ها اجبار می‌کند. مشخص کردن ipv6n4 سوکتی ایجاد می‌کند که IPv6 است اما اتصالات IPv4 را نیز مدیریت می‌کند. توجه داشته باشید که استفاده از ipv6n4 به طور خودکار سوکتی ایجاد نمی‌کند که برای IPv4 در دسترس باشد. مثلاً می‌توانید .B tcp,ipv6n4,::1,1234 را انجام دهید و کار خواهد کرد، اما از آنجا که .B ::1 یک آدرس IPv4 نیست، نمی‌توانید از طریق IPv4 به آن دسترسی داشته باشید. باید یک آدرس IPv4 مشخص کنید، مانند: .B tcp,ipv6n4,127.0.0.1,1234 که منجر به یک سوکت IPv6 واحد نگاشت‌شده در فضای IPv4 خواهد شد: .IP $ gensiot -a -p tcp,ipv6n4,localhost,1234 .br Address 0(0): ipv6,::ffff:127.0.0.1,1234 .PP اگر روی یک gensio پذیرنده (مانند sctp,1234) نام میزبان را مشخص نکنید، فقط یک سوکت IPv6 ایجاد می‌کند که به IPv4 نگاشت شده است. به این ترتیب هر دو اتصال IPv4 و IPv6 را می‌پذیرد. حتی اگر getaddrinfo معمولاً دو آدرس بازگرداند، فقط آدرس IPv6 استفاده می‌شود مگر اینکه هیچ آدرس IPv6 پیکربندی نشده باشد که در این صورت یک آدرس IPv4 بازمی‌گرداند. به طور کلی، برای gensioهای متصل‌شونده تنها اولین آدرسی که پیدا شود استفاده خواهد شد. پروتکل SCTP استثنا است و قابلیت چندمیزبانی (multi-homing) را روی تمام آدرس‌هایی که به دست می‌آیند اجرا می‌کند. بنابراین ممکن است نیاز باشد در تعیین آدرس‌ها کاملاً دقیق باشید. می‌توانید یک ماسک زیرشبکه (subnet mask) همراه با آدرس مشخص کنید، مانند: .IP 192.168.33.0/24 .PP این مورد به جز برای فراخوانی‌های .B gensio_addr_addr_present() که آدرس داده‌شده را با استفاده از ماسک زیرشبکه مشخص‌شده مقایسه می‌کند، عمدتاً نادیده گرفته می‌شود. در این حالت، طبق کاربرد عادی ماسک زیرشبکه، هر آدرسی از 192.168.33.0 تا 192.168.33.255 را می‌پذیرد. در حال حاضر هیچ چیزی در کتابخانه gensio از این استفاده نمی‌کند، اما ser2net از این ویژگی با گزینه remaddr خود برای مجاز کردن زیرشبکه‌ها به عنوان آدرس‌های راه دور استفاده می‌کند. به طور کلی اگر هر دو در دسترس باشند، آدرس‌های IPv6 ترجیح داده می‌شوند. .SH "زمان در gensio (یا gtime)" زمان شامل مجموعه‌ای از اعداد است که پس از هر کدام یک حرف تکی قرار دارد. آن حرف می‌تواند 'D'، 'H'، 'M'، 's'، 'm'، 'u' یا 'n' باشد که به ترتیب به معنای روز، ساعت، دقیقه، ثانیه، میلی‌ثانیه، میکروثانیه یا نانوثانیه است. بنابراین برای نمونه "10D5H4M9s100u" برابر با ۱۰ روز، ۵ ساعت، ۴ دقیقه، ۹ ثانیه و ۱۰۰ میکروثانیه خواهد بود. اگر یک عدد ساده بدون حرف در انتها داده شود، مقدار ممکن است به یک واحد خاص پیش‌فرض شود که توسط gensio مربوطه مشخص خواهد شد. .SH "مهلت تخلیه (Drain Timeout)" بسیاری از gensioها داده‌ها را در صف ارسال ذخیره می‌کنند. هنگام بستن اتصال، به طور پیش‌فرض منتظر می‌مانند تا خروجی قبل از اتمام بسته شدن به طور کامل ارسال شود. معمولاً این همان چیزی است که می‌خواهید، اما در برخی شرایط ممکن است مطلوب نباشد. بنابراین این gensioها گزینه .B drain_timeout را پیاده‌سازی می‌کنند و یک کنترل متناظر برای تنظیم آن پس از ایجاد وجود دارد. گزینه .B drain_timeout میزان زمان انتظار برای تخلیه داده‌ها هنگام بستن است. این مقدار زمان (به میلی‌ثانیه) را تعیین می‌کند که gensio قبل از خاموش شدن با داده‌های معلق منتظر تخلیه داده‌ها خواهد ماند. اگر این مقدار را منفی تنظیم کنید، برای همیشه منتظر می‌ماند که این حالت پیش‌فرض است. هرچند واقعاً برای همیشه نیست، زیرا لایه‌های پایین‌تر قبل از رسیدن به این زمان دچار مهلت زمانی (timeout) شده و اتصال را قطع می‌کنند. .SH "پارامتر nbits در auxdata" برخی gensioها توانایی انتقال داده‌ها در تعداد بیت‌هایی را دارند که مضربی از ۸ نیستند. مواردی که پردازش در سطح بیت انجام می‌دهند، مانند .B hdlc و .B convcode این کار را انجام می‌دهند. این gensioها یک پارامتر "nbits" در auxdata روی رابطی که داده‌ها را از آن دریافت می‌کنند دریافت خواهند کرد و "nbits" را برای داده‌هایی که به لایه بعدی تحویل می‌دهند ارائه می‌دهند. این به صورت "nbits=n" است که در آن n یک عدد است. مقدار "nbits" همیشه باید بین ۱ تا ۷ کمتر از طول بافر ارائه‌شده (به بایت) ضربدر ۸ باشد. بنابراین اگر بافری به طول ۱۰ بایت دارید، nbits می‌تواند از ۷۳ تا ۷۹ متغیر باشد. یا به عبارت دیگر، طول بافر همیشه از تعداد بیت‌ها به بایت بعدی گرد می‌شود: ((nbits + 7) / 8). اگر یک رابط "nbits" بپذیرد، در صورت عدم ارائه آن فرض می‌کند که nbits برابر با (<طول بافر> * 8) است. این بدان معناست که اگر یک رابط داده دریافت کند، در صورتی که کل بافر را مصرف نکند همیشه باید مضربی از ۸ بیت مصرف کند. هیچ راهی برای بازگرداندن تعداد بیت‌های مصرف‌شده وجود ندارد و تنها تعداد بایت‌ها بازگردانده می‌شود. .SH "TCP" .B tcp[()][,],[[,],[...]] .br .B hostname = [ipv4|ipv6|ipv6n4,] یک TCP gensio متصل‌شونده باید hostname مشخص‌شده داشته باشد. می‌توان چندین جفت hostname/port را مشخص کرد. برای یک TCP gensio متصل‌شونده، هر کدام به ترتیب آزمایش می‌شوند تا اتصال برقرار شود. برای gensioهای پذیرنده، به هر جفت hostname/port مشخص‌شده گوش داده می‌شود. .SS "پورت‌های پویا (Dynamic Ports)" برای پذیرنده‌ها، اگر پورت به صورت صفر مشخص شود، یک پورت تصادفی در محدوده پورت‌های پویای مشخص‌شده توسط IANA انتخاب می‌شود. اگر بیش از یک آدرس وجود داشته باشد، پورت یکسانی برای تمام آدرس‌ها انتخاب خواهد شد. می‌توانید با استفاده از تابع gensio_acc_control() با گزینه GENSIO_ACC_CONTROL_LPORT پورت را دریافت کنید. .SS "داده‌های خارج از باند (Out Of Band Data)" پروتکل TCP از داده‌های خارج از باند (oob) پشتیبانی می‌کند؛ داده‌هایی که در اسرع وقت و خارج از ترتیب عادی تحویل داده می‌شوند. این داده‌ها در یک خواندن عادی اما با مقدار "oob" در auxdata می‌آیند. می‌توانید با افزودن "oob" به auxdata در هنگام نوشتن داده oob ارسال کنید، اما نوشتن oob به ۱ بایت محدود است و نوشتن بیش از این مقدار منجر به رفتار تعریف‌نشده می‌شود. توجه داشته باشید که "oobtcp" نیز در auxdata تحویل و پذیرفته می‌شود، بنابراین می‌توانید داده‌های oob پروتکل TCP را از سایر داده‌های oob تشخیص دهید. .SS "گزینه‌ها (Options)" علاوه بر readbuf، سوکت tcp gensio گزینه‌های زیر را می‌پذیرد: .TP .B nodelay[=true|false] گزینه nodelay را روی سوکت تنظیم می‌کند. .TP .B laddr= یک مشخصه آدرس برای bind شدن روی سوکت محلی جهت تنظیم آدرس محلی. .TP .B reuseaddr[=true|false] گزینه SO_REUSEADDR را روی سوکت تنظیم می‌کند. برای سوکت‌های پذیرنده، این امکان را می‌دهد که سوکت به محض بسته شدن مجدداً استفاده شود. در صورت false بودن، تأخیری قبل از امکان استفاده مجدد وجود خواهد داشت. برای سوکت‌های متصل‌شونده، اجازه می‌دهد laddr تنظیم‌شده برای چندین اتصال استفاده شود تا زمانی که به یک مقصد یکسان نباشند. در اینجا محدودیت‌هایی وجود دارد؛ به "SO_REUSEADDR" در "man 7 socket" مراجعه کنید. پیش‌فرض true است. این ممکن است بهترین پیش‌فرض نباشد، زیرا ممکن است تداخل‌ها و شرایط رقابتی (race conditions) ناشی از استفاده مجدد خیلی سریع سوکت‌ها رخ دهد. .TP .B tcpd=on|print|off فقط برای پذیرنده، مدیریت tcpd را روی سوکت تنظیم می‌کند. اگر "on" باشد، tcpd اعمال می‌شود و اتصال در صورت رد شدن توسط tcpd بسته می‌شود. مقدار "print" شبیه به on است، با این تفاوت که قبل از بستن سوکت عبارت "Access Denied" را روی آن می‌نویسد. مقدار "off" مدیریت tcpd را روی سوکت غیرفعال می‌کند. پیش‌فرض on است. در صورتی که tcpd در زمان کامپایل غیرفعال شده باشد در دسترس نیست. .TP .B tcpdname= فقط برای پذیرنده، نام مورد استفاده برای کنترل دسترسی tcpd را تعیین می‌کند. پیش‌فرض "gensio" است و می‌توان آن را با gensio_set_progname() تغییر داد. این گزینه به شما امکان می‌دهد آن را به ازای هر پذیرنده gensio بازنویسی کنید. در صورت غیرفعال بودن tcpd در زمان کامپایل در دسترس نیست. .SS "رشته آدرس راه دور (Remote Address String)" آدرس راه دور در قالب "[ipv4|ipv6],," خواهد بود که در آن آدرس در قالب عددی، IPv4 یا IPv6 است. .SS "آدرس راه دور (Remote Address)" پروتکل TCP یک struct sockaddr استاندارد را برای کنترل GENSIO_CONTROL_RADDR_BIN بازمی‌گرداند. .SS "تخصیص مستقیم (Direct Allocation)" به عنوان یک terminal gensio با gdata به صورت "const struct gensio_addr *" تخصیص می‌یابد. .SH "UDP" .B udp[()][,],[[,],[...]] .br .B hostname = [ipv4|ipv6|ipv6n4,] .B unixdgram[()][,] یک UDP gensio یک سوکت UDP ایجاد می‌کند، اما آن را شبیه به یک جریان داده غیرقابل اعتماد جلوه می‌دهد. مشخصات آن مانند سوکت TCP است، به جز اینکه بدیهی است سوکت UDP ایجاد می‌شود. سوکت unixdgram یک سوکت دیتاگرام یونیکس است. این سوکت معنایی شبیه به UDP دارد که در زیر شرح داده شده است. تنها تفاوت این است که اگر بدون اختصاص دادن laddr داده ارسال کنید، آدرسی نخواهید داشت. gensio پذیرنده آدرسی دریافت نخواهد کرد و اگر تلاش کند پاسخی برای شما ارسال کند، با خطا مواجه خواهد شد. معنای سوکت UDP کمی متفاوت است. یک سوکت UDP متصل‌شونده نسبتاً ساده است: یک سوکت محلی باز می‌کند و داده‌ها را به سوکت راه دور می‌فرستد. یک UDP gensio پذیرنده چندان ساده نیست. gensio پذیرنده برای هر بسته‌ای که از یک میزبان راه دور جدید دریافت می‌کند یک gensio پذیرفته‌شده جدید ایجاد خواهد کرد. اگر خواندن را روی هر یک از gensioهای پذیرفته‌شده غیرفعال کنید یا پذیرش‌ها را روی gensio پذیرنده غیرفعال کنید، تمام خواندن‌ها روی همه gensioهای مرتبط با آن gensio پذیرنده متوقف خواهد شد. توجه داشته باشید که gensioهای پذیرنده UDP واقعاً برای استفاده از UDP الزامی نیستند؛ آن‌ها اساساً برای مدیریت مفاهیم پذیرنده ser2net حضور دارند. می‌توانید دو UDP gensio متصل‌شونده ایجاد کرده و بین آن‌ها ارتباط برقرار کنید. Gensioهای UDP قابل اعتماد نیستند، اما بدیهی است که بسته‌محور هستند. پورت 0 درست مانند TCP برای پذیرنده‌ها پشتیبانی می‌شود؛ برای جزئیات به بخش پورت‌های پویا در بخش TCP در بالا مراجعه کنید. آدرس مقصد به طور پیش‌فرض همان آدرس مشخص‌شده در تعریف gensio (برای gensioهای متصل‌شونده) یا آدرس راه دوری است که اتصال را آغاز کرده است (برای gensioهای پذیرنده)، اما می‌توان آن را با استفاده از "addr:" در auxdata هنگام نوشتن بازنویسی کرد. .SS "گزینه‌ها (Options)" علاوه بر readbuf، سوکت udp gensio گزینه‌های زیر را می‌پذیرد: .TP .B laddr= یک مشخصه آدرس برای bind شدن روی سوکت محلی جهت تنظیم آدرس محلی. .TP .B nocon[=true|false] اتصال‌محور نباشد، فقط همه بسته‌ها را دریافت کرده و بدون برقراری اتصال تحویل دهد. فقط برای gensio کلاینت معتبر است. آدرس دریافت به صورت پیشوند با "addr:" به auxdata ارسال می‌شود؛ این آدرسی است که توسط gensio_addr_to_str() قالب‌بندی شده است. .TP .B mloop[=true|false] فقط برای UDP. اگر false باشد، بسته‌های چندپخشی ارسال‌شده روی میزبان محلی دریافت نخواهند شد. اگر true باشد، دریافت می‌شوند. .TP .B mttl=[1-255] فقط برای UDP. مقدار Time-to-Live چندپخشی را تنظیم می‌کند. پیش‌فرض ۱ است، به این معنی که چندپخشی در شبکه محلی باقی می‌ماند. افزایش این مقدار تعداد گام‌ها (hops) روی روترهای چندپخشی را که بسته ارسالی طی می‌کند افزایش می‌دهد. .TP .B mcast= فقط برای UDP. آدرسی برای دریافت بسته‌های چندپخشی اضافه می‌کند. شماره پورتی وجود ندارد، این فقط آدرس است. می‌توانید چندین آدرس را در یک گزینه چندپخشی مشخص کنید و/یا گزینه چندپخشی می‌تواند چندین بار برای افزودن چندین آدرس چندپخشی استفاده شود. .TP .B reuseaddr[=true|false] فقط برای UDP. گزینه SO_REUSEADDR را روی سوکت تنظیم می‌کند که برای gensioهای متصل‌شونده و پذیرنده مناسب است. پیش‌فرض false است. .B delsock[=true|false] فقط برای unixdomain. اگر مسیر سوکت از قبل وجود دارد، قبل از باز کردن سوکت آن را حذف کن. .TP .B umode=[0-7|[rwx]*] فقط برای unixdomain. حالت فایل کاربر را برای فایل سوکت یونیکس تنظیم می‌کند. این همان ماسک بیتی معمولی read(4)/write(2)/execute(1) طبق chmod است، اما فقط برای بخش کاربر. اگر حالتی مشخص شود، سایر حالت‌ها به طور پیش‌فرض "6" (rw) خواهند بود مگر اینکه مشخص شوند، و حالت نهایی توسط umask طبق اصول استاندارد نایکس تغییر می‌یابد. اگر حالتی مشخص نشود، روی مقدار پیش‌فرض تنظیم شده و تغییر نمی‌کند. توجه داشته باشید که گزینه perm در زیر احتمالاً راه بهتری برای تنظیم این مورد است. .TP .B gmode=[0-7|[rwx]*] فقط برای unixdomain. حالت فایل گروه را برای فایل سوکت یونیکس تنظیم می‌کند، برای جزئیات به umode مراجعه کنید. .TP .B omode=[0-7|[rwx]*] فقط برای unixdomain. حالت فایل دیگران را برای فایل سوکت یونیکس تنظیم می‌کند، برای جزئیات به umode مراجعه کنید. .TP .B perm=[0-7][0-7][0-7] فقط برای unixdomain. حالت کامل فایل سوکت یونیکس را طبق اصول استاندارد نایکس تنظیم می‌کند که مانند عملیات‌های فوق توسط umask تغییر می‌یابد. .TP .B owner= فقط برای unixdomain. مالک فایل سوکت یونیکس را روی کاربر داده‌شده تنظیم می‌کند. .TP .B group= فقط برای unixdomain. گروه فایل سوکت یونیکس را روی گروه داده‌شده تنظیم می‌کند. .SS "رشته آدرس راه دور (Remote Address String)" آدرس راه دور در قالب "[ipv4|ipv6],," خواهد بود که در آن آدرس در قالب عددی، IPv4 یا IPv6 است. یا برای unixdomain به صورت "unix," خواهد بود. .SS "آدرس راه دور (Remote Address)" پروتکل UDP یک struct sockaddr استاندارد را برای کنترل GENSIO_CONTROL_RADDR_BIN بازمی‌گرداند. .SS "چندپخشی UDP (UDP Multicast)" چندپخشی را می‌توان روی gensioهای UDP با گزینه‌های .B nocon, maddr و .B laddr استفاده کرد. برای راه‌اندازی یک چندپخشی، یک UDP gensio کلاینت ایجاد کرده و laddr را برای پورت دریافت و آدرس مقصد را روی چندپخشی تنظیم کرده و nocon را فعال کنید، مانند: .IP "udp(mcast='ff02::1',laddr='ipv6,3000',nocon),ff02::1,3000" .PP و شما داده‌ها را روی آدرس چندپخشی دریافت کرده و ارسال خواهید کرد. گزینه .B laddr برای تنظیم پورت دریافت الزامی است. این بدان معناست که شما یک آدرس محلی نیز خواهید داشت و بسته‌ها را روی آن نیز دریافت خواهید کرد. .SS "تخصیص مستقیم (Direct Allocation)" به عنوان یک terminal gensio با gdata به صورت "const struct gensio_addr *" تخصیص می‌یابد. .SH "SCTP" .B sctp[()][,],[[,],[...]] .br .B hostname = [ipv4|ipv6|ipv6n4,] یک SCTP gensio مانند UDP یا TCP مشخص می‌شود. با این حال، رفتار آن متفاوت است. برای یک gensio متصل‌شونده، تلاش می‌کند یک اتصال چندمیزبانی (multi-homed) با تمام نام‌های میزبان و پورت‌های مشخص‌شده ایجاد کند. تمام پورت‌ها باید یکسان باشند. برای یک gensio پذیرنده، یک سوکت واحد با تمام آدرس‌های مشخص‌شده به عنوان مقصدهای ممکن ایجاد می‌کند. مجدداً، تمام پورت‌ها باید یکسان باشند. Gensioهای SCTP قابل اعتماد هستند. در حال حاضر آن‌ها بسته‌محور نیستند. در حال حاضر هیچ پشتیبانی از SCTP_EXPLICIT_EOR در پیاده‌سازی لینوکس SCTP وجود ندارد و بدون آن تبدیل آن به حالت بسته‌محور دشوار خواهد بود. هنگام تعیین آدرس‌های IPv6 که ممکن است به IPv4 نگاشت شوند، باید مراقب باشید. اگر یک طرف بتواند IPv4 را انجام دهد و طرف دیگر فقط بتواند IPv6 را انجام دهد، اتصال ممکن است برقرار شود، اما به سرعت قطع خواهد شد زیرا نمی‌تواند در سمت IPv4 ارتباط برقرار کند. برای نمونه، پذیرنده زیر: .IP tools/gensiot -a "sctp,ipv6,::,1234" .PP و متصل‌کننده زیر: .IP tools/gensiot "sctp,::1,1234" .PP به این شکل با شکست مواجه خواهند شد زیرا متصل‌کننده از آدرس IPv4 پشتیبانی می‌کند اما پذیرنده پشتیبانی نمی‌کند. .SS "الگوریتم Nagle و SCTP" پروتکل SCTP الگوریتم Nagle را به طور پیش‌فرض پیاده‌سازی می‌کند که در صورت تنظیم .B sack_freq روی بیش از یک، می‌تواند تداخل نامناسبی ایجاد کند. حداقل لینوکس مقدار پیش‌فرض .B sack_freq را روی ۲ قرار می‌دهد، اما gensio این مقدار را بازنویسی می‌کند تا از رفتارهای غیرمنتظره جلوگیری شود. آنچه اتفاق می‌افتد این است که در برخی شرایط ممکن است بسته‌ای تأییدنشده (unacked) باقی بماند، زیرا .B sack_freq بزرگتر از یک است. الگوریتم Nagle هیچ داده جدیدی را تا زمانی که داده‌های قبلاً ارسال‌شده تأیید نشوند ارسال نخواهد کرد. بنابراین یک طرف منتظر بسته جدیدی است تا sack ارسال کند، و طرف دیگر داده‌ها را نگه می‌دارد تا یک sack دریافت کند. بنابراین شما منتظر .B sack_delay می‌مانید که در آن زمان sack ارسال شده و کار دوباره از سر گرفته می‌شود. اگر sack_freq را تغییر می‌دهید باید از این موضوع آگاه باشید. .SS "گزینه‌ها (Options)" علاوه بر readbuf، پروتکل sctp gensio گزینه‌های زیر را می‌پذیرد: .TP .B instreams= .TP .B ostreams= این گزینه‌ها تعداد جریان‌های ورودی و خروجی را برای اتصال مشخص می‌کنند. پیش‌فرض یک است. جریان در auxdata برای خواندن و نوشتن در قالب "stream=" ارائه می‌شود. .TP .B sack_freq= .TP .B sack_delay= این گزینه‌ها نحوه مدیریت تأییدیه‌های انتخابی (sacks) را مشخص می‌کنند. .B sack_freq تعداد بسته‌های معلقی را که باید قبل از ارسال sack دریافت شوند تنظیم می‌کند. پیش‌فرض ۱ است، به این معنی که اصلاً منتظر نمی‌ماند. .B sack_delay حداکثر زمان قبل از ارسال sack در صورت وجود بسته‌های معلق را به میلی‌ثانیه تنظیم می‌کند. پیش‌فرض ۱۰ است، اما در صورتی که .B sack_freq روی ۱ تنظیم شده باشد غیرفعال می‌شود. تنظیم هر یک از این‌ها روی ۰ پیش‌فرض‌های سیستم را فعال می‌کند. .TP .B nodelay[=true|false] گزینه nodelay را روی سوکت تنظیم می‌کند. .TP .B laddr= یک مشخصه آدرس برای bind شدن روی سوکت محلی جهت تنظیم آدرس محلی. .TP .B reuseaddr[=true|false] گزینه SO_REUSEADDR را روی سوکت تنظیم می‌کند. برای سوکت‌های پذیرنده، اجازه می‌دهد سوکت به محض بسته شدن مجدداً استفاده شود. در صورت false بودن، تأخیری قبل از امکان استفاده مجدد وجود خواهد داشت. برای سوکت‌های متصل‌شونده، اجازه می‌دهد laddr تنظیم‌شده برای چندین اتصال استفاده شود تا زمانی که به یک مقصد یکسان نباشند. در اینجا محدودیت‌هایی وجود دارد؛ به "SO_REUSEADDR" در "man 7 socket" مراجعه کنید. پیش‌فرض true است. این ممکن است بهترین پیش‌فرض نباشد، زیرا تداخل‌های احتمالی ناشی از استفاده مجدد خیلی سریع سوکت‌ها وجود دارد. .TP 0 پورت 0 درست مانند TCP برای پذیرنده‌ها پشتیبانی می‌شود؛ برای جزئیات به بخش پورت‌های پویا در بخش TCP در بالا مراجعه کنید. پروتکل SCTP از داده‌های خارج از باند (oob) پشتیبانی می‌کند؛ داده‌هایی که در اسرع وقت و خارج از نوبت تحویل داده می‌شوند. این داده‌ها در یک خواندن عادی اما با "oob" در auxdata می‌آیند. می‌توانید با افزودن "oob" به auxdata در هنگام نوشتن داده oob ارسال کنید. برای جزئیات بیشتر به اسناد SCTP مراجعه کنید. .SS "رشته آدرس راه دور (Remote Address String)" آدرس راه دور در قالب "[ipv4|ipv6],,[;[ipv4|ipv6],,[...]]" خواهد بود که در آن آدرس در قالب عددی، IPv4 یا IPv6 است. هر آدرس راه دور برای اتصال SCTP فهرست می‌شود. .SS "آدرس راه دور (Remote Address)" پروتکل SCTP یک struct sockaddr فشرده را برای کنترل GENSIO_CONTROL_RADDR_BIN طبق اصول SCTP بازمی‌گرداند. .SS "تخصیص مستقیم (Direct Allocation)" به عنوان یک terminal gensio با gdata به صورت "const struct gensio_addr *" تخصیص می‌یابد. .SH "UNIX" .B unix[()], .B unixseq[()], یک سوکت جریانی یونیکس دامین را به عنوان پذیرنده ایجاد می‌کند، یا به عنوان متصل‌کننده به یک سوکت یونیکس دامین متصل می‌شود. گزینه unixseq مانند unix است، اما سوکت‌های SOCK_SEQPACKET را به جای سوکت SOCK_STREAM ایجاد می‌کند. این سوکت مانند unix کار می‌کند، به جز اینکه بسته‌محور است. اگرچه ممکن است عجیب به نظر برسد، اما unix gensio روی ویندوز نیز در دسترس است و تقریباً همانند سیستم‌های یونیکس کار می‌کند. با این حال unixseq و unixdgram در حال حاضر روی ویندوز در دسترس نیستند. با این وجود، نمی‌توانید مجوزها را مانند ویندوز تنظیم کنید. ایجاد چیزی که کار کند ممکن است، اما پیچیده است. برای مجوزها، می‌توانید دایرکتوری با مجوزهای مورد نظر خود ایجاد کنید و سپس سوکت را در آن دایرکتوری بسازید. سوکت به طور پیش‌فرض مجوزهای دایرکتوری را به ارث می‌برد. فایلی با مسیر سوکت داده‌شده ایجاد خواهد شد؛ شما باید مجوزهای ایجاد یک فایل قابل نوشتن را در آن مکان داشته باشید. اگر فایل از قبل وجود داشته باشد، روی یک سوکت پذیرنده خطا بازگردانده می‌شود مگر اینکه .I delsock را مشخص کنید که باعث حذف فایل می‌شود. برای جزئیات بیشتر در مورد اصول این سوکت‌ها، به ویژه مجوزها، باید صفحه راهنمای unix(7) را بخوانید. گزینه‌های زیر امکان تنظیم مجوزها و مالکیت‌های مختلف فایل را فراهم می‌کنند، اما بسته به سیستم‌عامل خاص ممکن است تأثیری بر اینکه چه کسی می‌تواند سوکت را باز کند نداشته باشد. .B برنامه‌های چندسکویی نباید برای امنیت به این مجوزها تکیه کنند. همچنین توجه داشته باشید که اعتبارسنجی راه دور لینوکس (Linux remote credentials) در حال حاضر پیاده‌سازی نشده است. .SS "گزینه‌ها (Options)" علاوه بر readbuf، سوکت unix gensio گزینه‌های زیر را می‌پذیرد: .TP .B delsock[=true|false] اگر مسیر سوکت از قبل وجود دارد، قبل از باز کردن سوکت آن را حذف کن. .TP .B umode=[0-7|[rwx]*] حالت فایل کاربر را برای فایل سوکت یونیکس تنظیم می‌کند. این همان ماسک بیتی معمولی read(4)/write(2)/execute(1) طبق chmod است، اما فقط برای بخش کاربر. اگر حالتی مشخص شود، سایر حالت‌ها به طور پیش‌فرض "6" (rw) خواهند بود مگر اینکه مشخص شوند، و حالت نهایی توسط umask طبق اصول استاندارد نایکس تغییر می‌یابد. اگر حالتی مشخص نشود، روی مقدار پیش‌فرض تنظیم شده و تغییر نمی‌کند. توجه داشته باشید که گزینه perm در زیر احتمالاً راه بهتری برای تنظیم این مورد است. روی ویندوز موجود نیست. .TP .B gmode=[0-7|[rwx]*] حالت فایل گروه را برای فایل سوکت یونیکس تنظیم می‌کند، برای جزئیات به umode مراجعه کنید. .TP .B omode=[0-7|[rwx]*] حالت فایل دیگران را برای فایل سوکت یونیکس تنظیم می‌کند، برای جزئیات به umode مراجعه کنید. .TP .B perm=[0-7][0-7][0-7] حالت کامل را برای فایل سوکت یونیکس طبق اصول استاندارد نایکس تنظیم می‌کند که مانند عملیات‌های فوق توسط umask تغییر می‌یابد. روی ویندوز موجود نیست. .TP .B owner= مالک فایل سوکت یونیکس را روی کاربر داده‌شده تنظیم می‌کند. روی ویندوز موجود نیست. .TP .B group= گروه فایل سوکت یونیکس را روی گروه داده‌شده تنظیم می‌کند. روی ویندوز موجود نیست. .TP .B peerusers=[;[;...]] کاربران مجاز نایکس را برای اتصال به این سوکت تعیین می‌کند. در صورت تنظیم، هر اتصالی که از کاربری خارج از این فهرست دریافت شود باعث می‌شود اتصال فوراً بسته شود. می‌توانید peerusers و peergroups را با هم استفاده کنید؛ در این صورت اگر هر یک از بررسی‌ها موفق باشد، اتصال مجاز خواهد بود. روی ویندوز موجود نیست. .TP .B peergrps=[;[;...]] گروه‌های مجاز نایکس را برای اتصال به این سوکت تعیین می‌کند. در صورت تنظیم، هر اتصالی که از کاربرانی دریافت شود که گروه آن‌ها در این فهرست نیست باعث می‌شود اتصال فوراً بسته شود. روی ویندوز موجود نیست. .SS "رشته آدرس راه دور (Remote Address String)" آدرس راه دور به این صورت خواهد بود: "unix,". .SS "آدرس راه دور (Remote Address)" پروتکل UNIX یک struct sockaddr_un استاندارد را برای کنترل GENSIO_CONTROL_RADDR_BIN بازمی‌گرداند. .SS "تخصیص مستقیم (Direct Allocation)" به عنوان یک terminal gensio با gdata به صورت "const struct gensio_addr *" تخصیص می‌یابد. .SH "serialdev" connecting = .B serialdev[()],[,[,]] یک اتصال serialdev یک پورت سریال محلی است. دستگاه در سیستم‌های شبیه یونیکس از نوع .B /dev/xxx است و باید یک دستگاه جریانی واقعی از نوعی باشد که پردازش عادی termios یا سریال روی آن کار می‌کند. در سیستم‌های ویندوز، دستگاه به صورت .B //./COM است که در آن شماره پورتی است که در Device Manager می‌بینید. توجه داشته باشید که این‌ها هنگام راه‌اندازی مجدد سیستم ممکن است جا‌به‌جا شوند؛ مطمئن نیستم راهی برای رفع آن وجود داشته باشد. برای دستگاه‌های غیرسریال، از gensio نوع "dev" استفاده کنید. این گزینه، بدون شگفتی، یک gensio سریال است. همچنین می‌توانید برای خلاصه کردن به جای "serialdev" از "sdev" استفاده کنید. یک مشکل در مورد serialdev و قفل‌گذاری UUCP این است که اگر در حین باز بودن دستگاه، یک فرایند را با fork() منشعب کنید، فرایند منشعب‌شده دارای serialdev خواهد بود اما مقدار موجود در فایل قفل UUCP نادرست خواهد بود. کار زیادی نمی‌توان در این مورد انجام داد، بنابراین مراقب باشید. .SS "گزینه‌ها (Options)" علاوه بر readbuf، ماژول serialdev gensio گزینه‌های زیر را می‌پذیرد: .TP .B uucplock[=true|false] قفل‌گذاری UUCP را روی دستگاه فعال یا غیرفعال می‌کند. پیش‌فرض برای همه چیز به جز دستگاه‌های pty و /dev/tty برابر با true است. در سیستم‌هایی که از این قابلیت پشتیبانی نمی‌کنند نادیده گرفته می‌شود. .TP .B flock[=true|false] قفل‌گذاری flock را روی دستگاه فعال یا غیرفعال می‌کند. پیش‌فرض برای همه چیز به جز /dev/tty برابر با true است. توجه داشته باشید که این کار هم "flock(fd, LOCK_EX | LOCK_NB)" و هم "ioctl(fd, TIOCNXCL)" را برای قفل کردن دستگاه انجام می‌دهد. در سیستم‌هایی که از این قابلیت پشتیبانی نمی‌کنند نادیده گرفته می‌شود. .TP .B drain_time=off|