.\" -*- coding: UTF-8 -*- .\" Copyright 1999, Andi Kleen .\" Copyright 2008-2014, Michael Kerrisk .\" Copyright, the authors of the Linux man-pages project .\" .\" SPDX-License-Identifier: Linux-man-pages-1-para .\" .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH UNIX 7 "8 فبراير 2026" "صفحات دليل لينكس 6.18" .SH الاسم unix \- مقابس للتواصل بين العمليات محلياً .SH موجز .nf \fB#include \fP \fB#include \fP .P \fIunix_socket\fP\fB = socket(AF_UNIX, type, 0);\fP \fIerror\fP\fB = socketpair(AF_UNIX, type, 0, int *\fP\fIsv\fP\fB);\fP .fi .SH الوصف عائلة المقبس \fBAF_UNIX\fP (المعروفة أيضًا باسم \fBAF_LOCAL\fP) تُستخدم للتواصل بين العمليات على نفس الجهاز بكفاءة. تقليدياً، يمكن أن تكون مقابس نطاق UNIX إما غير مسماة أو مرتبطة بمسار اسم ملف (مُعلّم كنوع مقبس). يدعم Linux أيضًا مساحة اسم مجردة مستقلة عن نظام الملفات. .P أنواع المقابس الصالحة في نطاق UNIX هي: \fBSOCK_STREAM\fP، لمقبس موجه للتيار؛ \fBSOCK_DGRAM\fP، لمقبس موجه للبيانات يحافظ على حدود الرسائل (كما في معظم تطبيقات UNIX، مقابس بيانات نطاق UNIX موثوقة دائماً ولا تعيد ترتيب البيانات)؛ و (منذ Linux 2.6.4) \fBSOCK_SEQPACKET\fP، لمقبس حزم متسلسل موجه للاتصال، يحافظ على حدود الرسائل، ويُسلم الرسائل بالترتيب الذي أُرسلت به. .P تدعم مقابس نطاق UNIX تمرير واصفات الملفات أو بيانات اعتماد العملية إلى عمليات أخرى باستخدام البيانات المساعدة. .SS "تنسيق العنوان" يُمثل عنوان مقبس نطاق UNIX في الهيكل التالي: .P .in +4n .EX .\" #define UNIX_PATH_MAX 108 .\" struct sockaddr_un { sa_family_t sun_family; /* AF_UNIX */ char sun_path[108]; /* Pathname */ }; .EE .in .P حقل \fIsun_family\fP يحتوي دائماً على \fBAF_UNIX\fP. في Linux، حجم \fIsun_path\fP هو 108 بايت؛ انظر أيضًا BUGS، أدناه. .P تأخذ استدعاءات نظام متنوعة (مثل \fBbind\fP(2)، \fBconnect\fP(2)، و \fBsendto\fP(2)) وسيط \fIsockaddr_un\fP كمدخل. تُرجع بعض استدعاءات النظام الأخرى (مثل \fBgetsockname\fP(2)، \fBgetpeername\fP(2)، \fBrecvfrom\fP(2)، و \fBaccept\fP(2)) وسيطاً من هذا النوع. .P يُميز ثلاثة أنواع من العناوين في هيكل \fIsockaddr_un\fP: .TP pathname يمكن ربط مقبس نطاق UNIX بمسار اسم ملف منتهي بقيمة فارغة باستخدام \fBbind\fP(2). عندما يُعاد عنوان مقبس مسار اسم (بواسطة أحد استدعاءات النظام المذكورة أعلاه)، يكون طوله .IP .in +4n .EX offsetof(struct sockaddr_un, sun_path) + strlen(sun_path) + 1 .EE .in .IP و \fIsun_path\fP يحتوي على مسار الاسم المنتهي بقيمة فارغة. (في Linux، تعبير \fBoffsetof\fP() أعلاه يساوي نفس قيمة \fIsizeof(sa_family_t)\fP، لكن بعض التطبيقات الأخرى تتضمن حقولاً أخرى قبل \fIsun_path\fP، لذا فإن تعبير \fBoffsetof\fP() يصف حجم هيكل العنوان بشكل أكثر قابلية للنقل.) .IP لمزيد من التفاصيل حول مقابس مسار الاسم، انظر أدناه. .TP unnamed .\" There is quite some variation across implementations: FreeBSD .\" says the length is 16 bytes, HP-UX 11 says it's zero bytes. مقبس تيار لم يُربط بمسار اسم باستخدام \fBbind\fP(2) ليس له اسم. بالمثل، المقبسان اللذان يُنشآن بواسطة \fBsocketpair\fP(2) غير مسميين. عندما يُعاد عنوان مقبس غير مسمى، يكون طوله \fIsizeof(sa_family_t)\fP، ولا يجب فحص \fIsun_path\fP. .TP abstract يُميز عنوان مقبس مجرد (عن مقبس مسار اسم) بحقيقة أن \fIsun_path[0]\fP هو بايت فارغ (\[aq]\[rs]0\[aq]). عنوان المقبس في هذه المساحة الاسمية يُعطى بالبايتات الإضافية في \fIsun_path\fP التي تُغطى بالطول المحدد لهيكل العنوان. (البايتات الفارغة في الاسم ليس لها دلالة خاصة.) الاسم ليس له اتصال بمسارات أسماء الملفات. عندما يُعاد عنوان مقبس مجرد، يكون \fIaddrlen\fP المُعاد أكبر من \fIsizeof(sa_family_t)\fP (أي أكبر من 2)، واسم المقبس موجود في أول \fI(addrlen \- sizeof(sa_family_t))\fP بايت من \fIsun_path\fP. .SS "مقابس مسار الاسم" عند ربط مقبس بمسار اسم، يجب مراعاة بعض القواعد لتحقيق أقصى قابلية للنقل وسهولة البرمجة: .IP \[bu] 3 مسار الاسم في \fIsun_path\fP يجب أن يكون منتهياً بقيمة فارغة. .IP \[bu] طول مسار الاسم، بما في ذلك البايت الفارغ الختامي، يجب ألا يتجاوز حجم \fIsun_path\fP. .IP \[bu] وسيط \fIaddrlen\fP الذي يصف هيكل \fIsockaddr_un\fP المحيط يجب أن يكون له قيمة على الأقل: .IP .in +4n .EX offsetof(struct sockaddr_un, sun_path)+strlen(addr.sun_path)+1 .EE .in .IP أو، بشكل أبسط، يمكن تحديد \fIaddrlen\fP كـ \fIsizeof(struct sockaddr_un)\fP. .P .\" Linux does this, including for the case where the supplied path .\" is 108 bytes هناك بعض الاختلاف في كيفية معالجة التطبيقات لعناوين مقابس نطاق UNIX التي لا تتبع القواعد أعلاه. على سبيل المثال، بعض التطبيقات (وليس كلها) تُلحق فاصلاً فارغاً إذا لم يكن موجوداً في \fIsun_path\fP المُقدم. .P .\" HP-UX .\" Modern BSDs generally have 104, Tru64 and AIX have 104, .\" Solaris and Irix have 108 عند برمجة تطبيقات قابلة للنقل، ضع في اعتبارك أن بعض التطبيقات لديها \fIsun_path\fP بطول 92 بايت فقط. .P .\" تُرجع استدعاءات نظام متنوعة (\fBaccept\fP(2)، \fBrecvfrom\fP(2)، \fBgetsockname\fP(2)، \fBgetpeername\fP(2)) هياكل عنوان مقبس. عند تطبيقها على مقابس نطاق UNIX، يجب تهيئة وسيط \fIaddrlen\fP ذو القيمة\-النتيجة المُقدم للاستدعاء كما هو مذكور أعلاه. عند العودة، يُضبط الوسيط للإشارة إلى \fIالحجم الفعلي\fP لهيكل العنوان. يجب على المستدعي التحقق من القيمة المُعادة في هذا الوسيط: إذا تجاوزت قيمة الإخراج قيمة الإدخال، فلا يوجد ضمان بوجود فاصل فارغ في \fIsun_path\fP. (انظر BUGS.) .SS "ملكية وصلات أسماء المسارات وأذوناتها" في تطبيق لينكس، تلتزم وصلات أسماء المسارات بأذونات الدليل الذي توجد فيه. يفشل إنشاء وصلة جديدة إذا لم تمتلك العملية إذن الكتابة والبحث (التنفيذ) على الدليل الذي تُنشأ فيه الوصلة. .P في لينكس، يتطلب الاتصال بكائن وصلة دفق إذن كتابة على تلك الوصلة؛ إرسال مخطط بيانات إلى وصلة مخطط بيانات يتطلب بالمثل إذن كتابة على تلك الوصلة. لا يُدلي POSIX بأي بيان حول تأثير الأذونات على ملف وصلة، وفي بعض الأنظمة (مثل أنظمة BSD القديمة)، تُتجاهل أذونات الوصلة. لا ينبغي للبرامج المحمولة الاعتماد على هذه الميزة للأمان. .P عند إنشاء وصلة جديدة، يُعيّن المالك والمجموعة لملف الوصلة وفقًا للقواعد المعتادة. يمتلك ملف الوصلة جميع الأذونات المُمكّنة، باستثناء تلك التي تُعطّل بواسطة \fBumask\fP(2) للعملية. .P .\" However, fchown() and fchmod() do not seem to have an effect .\" يمكن تغيير المالك والمجموعة وأذونات وصلة اسم المسار (باستخدام \fBchown\fP(2) و\fBchmod\fP(2)). .SS "الوصلات المجردة" لا معنى لأذونات الوصلة للوصلات المجردة: ليس لـ \fBumask\fP(2) للعملية أي تأثير عند ربط وصلة مجردة، وتغيير ملكية وأذونات الكائن (عبر \fBfchown\fP(2) و\fBfchmod\fP(2)) ليس له أي تأثير على إمكانية الوصول إلى الوصلة. .P تختفي الوصلات المجردة آليًا عند إغلاق جميع المراجع المفتوحة للوصلة. .P .\" مساحة أسماء الوصلة المجردة هي امتداد لينكس غير محمول. .SS "خيارات المقبس" لأسباب تاريخية، تُحدد خيارات الوصلة هذه بنوع \fBSOL_SOCKET\fP على الرغم من أنها خاصة بـ \fBAF_UNIX\fP. يمكن تعيينها باستخدام \fBsetsockopt\fP(2) وقراءتها باستخدام \fBgetsockopt\fP(2) بتحديد \fBSOL_SOCKET\fP كعائلة الوصلة. .TP \fBSO_PASSCRED\fP يؤدي تمكين خيار الوصلة هذا إلى استلام بيانات اعتماد العملية المرسلة في رسالة \fBSCM_CREDENTIALS التابعة\fP في كل رسالة تُستلم لاحقًا. بيانات الاعتماد المُعادة هي تلك التي حددها المرسل باستخدام \fBSCM_CREDENTIALS\fP، أو مبدئي يتضمن معرف العملية ومعرف المستخدم الحقيقي ومعرف المجموعة الحقيقي للمرسل، إذا لم يحدد المرسل بيانات \fBSCM_CREDENTIALS\fP التابعة. .IP عند تعيين هذا الخيار ولم تكن الوصلة متصلة بعد، يُنشأ اسم فريد في مساحة الأسماء المجردة آليًا. .IP القيمة المعطاة كمعامل لـ \fBsetsockopt\fP(2) والراجعة كنتيجة لـ \fBgetsockopt\fP(2) هي علامة منطقية صحيحة. .TP \fBSO_PASSSEC\fP يُمكّن استلام تسمية أمان SELinux لوصلة النظير في رسالة تابعة من النوع \fBSCM_SECURITY\fP (انظر أدناه). .IP القيمة المعطاة كمعامل لـ \fBsetsockopt\fP(2) والراجعة كنتيجة لـ \fBgetsockopt\fP(2) هي علامة منطقية صحيحة. .IP .\" commit 877ce7c1b3afd69a9b1caeb1b9964c992641f52a .\" commit 37a9a8df8ce9de6ea73349c9ac8bdf6ba4ec4f70 خيار \fBSO_PASSSEC\fP مدعوم لوصلات مخطط بيانات نطاق يونكس منذ لينكس 2.6.18؛ أُضيف الدعم لوصلات دفق نطاق يونكس في لينكس 4.2. .TP \fBSO_PEEK_OFF\fP انظر \fBsocket\fP(7). .TP \fBSO_PEERCRED\fP خيار الوصلة القابل للقراءة فقط هذا يُرجع بيانات اعتماد عملية النظير المتصلة بهذه الوصلة. بيانات الاعتماد المُعادة هي تلك التي كانت سارية المفعول في وقت استدعاء \fBconnect\fP(2) أو \fBlisten\fP(2) أو \fBsocketpair\fP(2). .IP الوسيط لـ \fBgetsockopt\fP(2) هو مؤشر لبنية \fIucred\fP؛ عرّف ماكرو اختبار الميزة \fB_GNU_SOURCE\fP للحصول على تعريف تلك البنية من \fI\fP. .IP .\" استخدام هذا الخيار ممكن فقط لوصلات دفق \fBAF_UNIX\fP المتصلة ولأزواج وصلات دفق ومخطط بيانات \fBAF_UNIX\fP المُنشأة باستخدام \fBsocketpair\fP(2). .SS "ميزة الربط الآلي" .\" i.e., sizeof(short) إذا حدد استدعاء \fBbind\fP(2) \fIaddrlen\fP كـ \fIsizeof(sa_family_t)\fP، أو تم تحديد خيار الوصلة \fBSO_PASSCRED\fP لوصلة لم تُربط صراحة بعنوان، فتُربط الوصلة آليًا بعنوان مجرد. يتكون العنوان من بايت فارغ متبوع بـ 5 بايتات في مجموعة الأحرف \fI[0\-9a\-f]\fP. وبالتالي، هناك حد يبلغ 2\[ha]20 عنوان ربط آلي. (من لينكس 2.1.15، عند إضافة ميزة الربط الآلي، استُخدمت 8 بايتات، وبالتالي كان الحد 2\[ha]32 عنوان ربط آلي. جاء التغيير إلى 5 بايتات في لينكس 2.3.15.) .SS "واجهة برمجة تطبيقات المقابس (Sockets API)" تصف الفقرات التالية تفاصيل خاصة بالنطاق وميزات غير مدعومة لواجهة برمجة تطبيقات الوصلات لوصلات نطاق يونكس في لينكس. .P لا تدعم وصلات نطاق يونكس إرسال البيانات خارج النطاق (علامة \fBMSG_OOB\fP لـ \fBsend\fP(2) و\fBrecv\fP(2)). .P علامة \fBMSG_MORE\fP لـ \fBsend\fP(2) غير مدعومة بواسطة وصلات نطاق يونكس. .P .\" commit 9f6f9af7694ede6314bed281eec74d588ba9474f قبل لينكس 3.4، لم يكن استخدام \fBMSG_TRUNC\fP في وسيط \fIflags\fP لـ \fBrecv\fP(2) مدعومًا بواسطة وصلات نطاق يونكس. .P خيار الوصلة \fBSO_SNDBUF\fP له تأثير على وصلات نطاق يونكس، لكن خيار \fBSO_RCVBUF\fP ليس له تأثير. لوصلات مخطط البيانات، تفرض قيمة \fBSO_SNDBUF\fP حدًا أعلى على حجم مخططات البيانات الصادرة. يُحسب هذا الحد كقيمة الخيار المضاعفة (انظر \fBsocket\fP(7)) ناقص 32 بايتًا مستخدمة للنفقات العامة. .SS "رسائل مساعدة" تُرسَل وتُستقبَل البيانات المساعدة باستخدام \fBsendmsg\fP(2) و\fBrecvmsg\fP(2). لأسباب تاريخية، تُحدَّد أنواع الرسائل المساعدة المدرجة أدناه بنوع \fBSOL_SOCKET\fP رغم أنها خاصة بـ\fBAF_UNIX\fP. لإرسالها، اضبط حقل \fIcmsg_level\fP من البنية \fIcmsghdr\fP على \fBSOL_SOCKET\fP وحقل \fIcmsg_type\fP على النوع. لمزيد من المعلومات، انظر \fBcmsg\fP(3). .TP \fBSCM_RIGHTS\fP أرسل أو استقبل مجموعة من واصفات الملفات المفتوحة من عملية أخرى. يحتوي جزء البيانات على مصفوفة أعداد صحيحة لواصفات الملفات. .IP يُشار إلى هذه العملية عادةً باسم "تمرير واصف ملف" إلى عملية أخرى. لكن، بشكل أكثر دقة، ما يُمرَّر هو مرجع إلى وصف ملف مفتوح (انظر \fBopen\fP(2))، ومن المحتمل أن يُستخدم رقم واصف ملف مختلف في العملية المستقبلة. دلاليًا، هذه العملية مكافئة لنسخ (\fBdup\fP(2)) واصف ملف في جدول واصفات الملفات لعملية أخرى. .IP إذا كانت المخبأة المستخدمة لاستقبال البيانات المساعدة المحتوية على واصفات الملفات صغيرة جدًا (أو غائبة)، فتُبتَر البيانات المساعدة (أو تُهمَل) وتُغلَق واصفات الملفات الزائدة آليًا في العملية المستقبلة. .IP إذا تسبب عدد واصفات الملفات المستلمة في البيانات المساعدة في تجاوز العملية لحد مواردها \fBRLIMIT_NOFILE\fP (انظر \fBgetrlimit\fP(2))، فتُغلَق واصفات الملفات الزائدة آليًا في العملية المستقبلة. .IP .\" commit bba14de98753cb6599a2dae0e520714b2153522d يُعرِّف الثابت النواة \fBSCM_MAX_FD\fP حدًا لعدد واصفات الملفات في المصفوفة. تؤدي محاولة إرسال مصفوفة أكبر من هذا الحد إلى فشل \fBsendmsg\fP(2) مع الخطأ \fBEINVAL\fP. قيمة \fBSCM_MAX_FD\fP هي 253 (أو 255 قبل Linux 2.6.38). .TP \fBSCM_CREDENTIALS\fP أرسل أو استقبل بيانات اعتماد UNIX. يمكن استخدام هذا للاستيثاق. تُمرَّر بيانات الاعتماد كرسالة مساعدة من نوع \fIstruct ucred\fP. تُعرَّف هذه البنية في \fI\fP كما يلي: .IP .in +4n .EX struct ucred { pid_t pid; /* Process ID of the sending process */ uid_t uid; /* User ID of the sending process */ gid_t gid; /* Group ID of the sending process */ }; .EE .in .IP منذ glibc 2.8، يجب تعريف ماكرو اختبار الميزة \fB_GNU_SOURCE\fP (قبل تضمين \fIأي\fP ملفات رأس) للحصول على تعريف هذه البنية. .IP تُفحَص بيانات الاعتماد التي يُحدِّدها المرسل بواسطة النواة. يُسمح لعملية متميزة بتحديد قيم لا تطابق قيمها الخاصة. يجب على المرسل تحديد معرف العملية الخاص به (إلا إذا كان لديه القدرة \fBCAP_SYS_ADMIN\fP، وفي هذه الحالة يمكن تحديد PID لأي عملية موجودة)، ومعرف المستخدم الحقيقي، أو معرف المستخدم الفعال، أو معرف المستخدم المحفوظ (إلا إذا كان لديه \fBCAP_SETUID\fP)، ومعرف المجموعة الحقيقي، أو معرف المجموعة الفعال، أو معرف المجموعة المحفوظ (إلا إذا كان لديه \fBCAP_SETGID\fP). .IP لاستقبال رسالة \fIstruct ucred\fP، يجب تمكين الخيار \fBSO_PASSCRED\fP على المقبس. .TP \fBSCM_SECURITY\fP استقبل سياق أمان SELinux (وسم الأمان) لمقبس النظير. البيانات المساعدة المستلمة هي سلسلة منتهية بقيمة خالية تحتوي على سياق الأمان. يجب على المستقبل تخصيص \fBNAME_MAX\fP بايت على الأقل في جزء البيانات من الرسالة المساعدة لهذه البيانات. .IP لاستقبال سياق الأمان، يجب تمكين الخيار \fBSO_PASSSEC\fP على المقبس (انظر أعلاه). .P عند إرسال بيانات مساعدة باستخدام \fBsendmsg\fP(2)، يمكن تضمين عنصر واحد فقط من كل نوع من الأنواع المذكورة أعلاه في الرسالة المرسلة. .P يجب إرسال بايت واحد على الأقل من البيانات الحقيقية عند إرسال بيانات مساعدة. على Linux، هذا مطلوب لإرسال البيانات المساعدة بنجاح عبر مقبس دفق نطاق UNIX. عند إرسال بيانات مساعدة عبر مقبس مخطط بيانات نطاق UNIX، ليس من الضروري على Linux إرسال أي بيانات حقيقية مصاحبة. لكن، يجب على التطبيقات المحمولة تضمين بايت واحد على الأقل من البيانات الحقيقية عند إرسال بيانات مساعدة عبر مقبس مخطط بيانات. .P عند الاستقبال من مقبس دفق، تشكل البيانات المساعدة نوعًا من الحاجز للبيانات المستلمة. على سبيل المثال، افترض أن المرسل يُرسل كما يلي: .P .RS .PD 0 .IP (1) 5 \fBsendmsg\fP(2) لأربعة بايتات، بدون بيانات مساعدة. .IP (2) \fBsendmsg\fP(2) لبايت واحد، مع بيانات مساعدة. .IP (3) \fBsendmsg\fP(2) لأربعة بايتات، بدون بيانات مساعدة. .PD .RE .P افترض أن المستقبل يُنفِّذ الآن استدعاءات \fBrecvmsg\fP(2) كل منها بحجم مخبأة 20 بايت. سيستقبل الاستدعاء الأول خمسة بايتات من البيانات، إلى جانب البيانات المساعدة المرسلة بواسطة استدعاء \fBsendmsg\fP(2) الثاني. سيستقبل الاستدعاء التالي البايتات الأربعة المتبقية من البيانات. .P .\" إذا كانت المساحة المخصصة لاستقبال البيانات المساعدة الواردة صغيرة جدًا، فتُبتَر البيانات المساعدة إلى عدد الرؤوس التي تناسب المخبأة المقدمة (أو، في حالة قائمة واصفات ملفات \fBSCM_RIGHTS\fP، قد تُبتَر قائمة واصفات الملفات). إذا لم تُقدم مخبأة للبيانات المساعدة الواردة (أي، حقل \fImsg_control\fP من بنية \fImsghdr\fP المقدمة إلى \fBrecvmsg\fP(2) هو NULL)، فتُهمَل البيانات المساعدة الواردة. في كلتا هاتين الحالتين، سيُضبط العلم \fBMSG_CTRUNC\fP في قيمة \fImsg.msg_flags\fP التي يُرجعها \fBrecvmsg\fP(2). .SS Ioctls استدعاءات \fBioctl\fP(2) التالية تعيد معلومات في \fIvalue\fP. الصيغة الصحيحة هي: .P .RS .nf \fBint\fP\fI value\fP\fB;\fP \fIerror\fP\fB = ioctl(\fP\fIunix_socket\fP\fB, \fP\fIioctl_type\fP\fB, &\fP\fIvalue\fP\fB);\fP .fi .RE .P يمكن أن يكون \fIioctl_type\fP: .TP \fBSIOCINQ\fP .\" FIXME . https://www.sourceware.org/bugzilla/show_bug.cgi?id=12002, .\" filed 2010-09-10, may cause SIOCINQ to be defined in glibc headers .\" SIOCOUTQ also has an effect for UNIX domain sockets, but not .\" quite what userland might expect. It seems to return the number .\" of bytes allocated for buffers containing pending output. .\" That number is normally larger than the number of bytes of pending .\" output. Since this info is, from userland's point of view, imprecise, .\" and it may well change, probably best not to document this now. بالنسبة لمقابس \fBSOCK_STREAM\fP، يُرجع هذا الاستدعاء عدد البايتات غير المقروءة في مخبأة الاستقبال. يجب ألا يكون المقبس في حالة LISTEN، وإلا يُرجع خطأ (\fBEINVAL\fP). يُعرَّف \fBSIOCINQ\fP في \fI\fP. بدلاً من ذلك، يمكنك استخدام \fBFIONREAD\fP المترادف، المُعرَّف في \fI\fP. بالنسبة لمقابس \fBSOCK_DGRAM\fP، القيمة المُرجَعة هي نفسها لمقابس مخطط بيانات نطاق الإنترنت؛ انظر \fBudp\fP(7). .SH الأخطاء .TP \fBEADDRINUSE\fP العنوان المحلي المحدد قيد الاستخدام بالفعل أو كائن مقبس نظام الملفات موجود بالفعل. .TP \fBEBADF\fP يمكن أن يحدث هذا الخطأ لـ\fBsendmsg\fP(2) عند إرسال واصف ملف كبيانات مساعدة عبر مقبس نطاق UNIX (انظر وصف \fBSCM_RIGHTS\fP أعلاه)، ويشير إلى أن رقم واصف الملف الذي يُرسَل غير صالح (مثلًا، ليس واصف ملف مفتوح). .TP \fBECONNREFUSED\fP العنوان البعيد المحدد بواسطة \fBconnect\fP(2) لم يكن مقبس استماع. يمكن أن يحدث هذا الخطأ أيضًا إذا لم يكن اسم المسار الهدف مقبسًا. .TP \fBECONNRESET\fP أُغلقت المقبس البعيد بشكل غير متوقع. .TP \fBEFAULT\fP عنوان ذاكرة المستخدم لم يكن صالحًا. .TP \fBEINVAL\fP مُمررت وسيطة غير صالحة. سبب شائع هو أن القيمة \fBAF_UNIX\fP لم تُحدد في حقل \fIsun_type\fP للعناوين المُمررة، أو أن المقبس كان في حالة غير صالحة للعملية المطبقة. .TP \fBEISCONN\fP استُدعيت \fBconnect\fP(2) على مقبس موصول بالفعل أو حُدد عنوان هدف على مقبس موصول. .TP \fBENFILE\fP وُصل إلى الحد الأقصى لإجمالي عدد الملفات المفتوحة على مستوى النظام. .TP \fBENOENT\fP اسم المسار في العنوان البعيد المُحدد لـ \fBconnect\fP(2) لم يكن موجودًا. .TP \fBENOMEM\fP نفدت الذاكرة. .TP \fBENOTCONN\fP عملية المقبس تحتاج عنوان هدف، لكن المقبس غير موصول. .TP \fBEOPNOTSUPP\fP استُدعيت عملية دفق على مقبس غير موجه للدفق أو حُاول استخدام خيار البيانات خارج النطاق. .TP \fBEPERM\fP مُمرر المرسل بيانات استيثاق غير صالحة في \fIstruct ucred\fP. .TP \fBEPIPE\fP أُغلق المقبس البعيد على مقبس دفق. إذا كان مُفعلاً، يُرسل \fBSIGPIPE\fP أيضًا. يمكن تجنب ذلك بتمرير العلم \fBMSG_NOSIGNAL\fP إلى \fBsend\fP(2) أو \fBsendmsg\fP(2). .TP \fBEPROTONOSUPPORT\fP البروتوكول المُمرر ليس \fBAF_UNIX\fP. .TP \fBEPROTOTYPE\fP المقبس البعيد لا يطابق نوع المقبس المحلي (\fBSOCK_DGRAM\fP مقابل \fBSOCK_STREAM\fP). .TP \fBESOCKTNOSUPPORT\fP نوع مقبس غير معروف. .TP \fBESRCH\fP أثناء إرسال رسالة مساعدة تحتوي على بيانات استيثاق (\fBSCM_CREDENTIALS\fP)، حدد المتصل PID لا يطابق أي عملية موجودة. .TP \fBETOOMANYREFS\fP يمكن أن يحدث هذا الخطأ لـ \fBsendmsg\fP(2) عند إرسال واصف ملف كبيانات مساعدة عبر مقبس نطاق UNIX (انظر وصف \fBSCM_RIGHTS\fP، أعلاه). يحدث إذا تجاوز عدد واصفات الملفات "قيد الطيران" حد المورد \fBRLIMIT_NOFILE\fP ولم يكن لدى المتصل القدرة \fBCAP_SYS_RESOURCE\fP. واصف الملف قيد الطيران هو الذي أُرسل باستخدام \fBsendmsg\fP(2) لكن لم يُقبل بعد في عملية المستلم باستخدام \fBrecvmsg\fP(2). .IP .\" commit 712f4aad406bb1ed67f3f98d04c044191f0ff593 شُخص هذا الخطأ منذ النواة الرئيسية Linux 4.5 (وفي بعض إصدارات النواة السابقة حيث رُجع الإصلاح). في إصدارات النواة السابقة، كان من الممكن وضع عدد غير محدود من واصفات الملفات قيد الطيران، بإرسال كل واصف ملف مع \fBsendmsg\fP(2) ثم إغلاق واصف الملف بحيث لا يُحتسب ضد حد المورد \fBRLIMIT_NOFILE\fP. .P يمكن توليد أخطاء أخرى بواسطة طبقة المقابس العامة أو بواسطة نظام الملفات أثناء توليد كائن مقبس نظام الملفات. راجع صفحات الدليل المناسبة لمزيد من المعلومات. .SH الإصدارات قُدما \fBSCM_CREDENTIALS\fP ومساحة الاسم المجردة مع Linux 2.2 ولا ينبغي استخدامهما في البرامج المحمولة. (بعض الأنظمة المشتقة من BSD تدعم أيضًا تمرير بيانات الاستيثاق، لكن تفاصيل التنفيذ تختلف.) .SH ملاحظات الربط بمقبس باسم ملف ينشئ مقبسًا في نظام الملفات يجب حذفه بواسطة المتصل عندما لا يعود مطلوبًا (باستخدام \fBunlink\fP(2)). تنطبق دلالات الإغلاق اللاحق المعتادة لـ UNIX؛ يمكن فك ربط المقبس في أي وقت وسيُزال نهائيًا من نظام الملفات عند إغلاق آخر مرجع له. .P لتمرير واصفات ملفات أو بيانات استيثاق عبر مقبس \fBSOCK_STREAM\fP، يجب إرسال أو استقبال بايت واحد على الأقل من بيانات غير مساعدة في نفس استدعاء \fBsendmsg\fP(2) أو \fBrecvmsg\fP(2). .P .\" مقابس دفق نطاق UNIX لا تدعم مفهوم البيانات خارج النطاق. .SH العلل .\" The behavior on Solaris is quite similar. عند ربط مقبس بعنوان، Linux هو أحد التطبيقات التي تُلحق مُنهيًا فارغًا إذا لم يُقدم أي في \fIsun_path\fP. في معظم الحالات هذا غير إشكالي: عند استرجاع عنوان المقبس، سيكون أطول ببايت واحد مما قُدم عند ربط المقبس. لكن، هناك حالة واحدة يمكن أن ينتج عنها سلوك مربك: إذا قُدمت 108 بايتات غير فارغة عند ربط مقبس، فإن إضافة المُنهي الفارغ تأخذ طول اسم المسار إلى ما بعد \fIsizeof(sun_path)\fP. وبالتالي، عند استرجاع عنوان المقبس (مثلاً، عبر \fBaccept\fP(2))، إذا حُددت وسيطة \fIaddrlen\fP المدخلة لاستدعاء الاسترجاع كـ \fIsizeof(struct sockaddr_un)\fP، فإن بنية العنوان المُعادة \fIلن\fP تحتوي على مُنهٍ فارغ في \fIsun_path\fP. .P .\" i.e., traditional BSD بالإضافة إلى ذلك، بعض التطبيقات لا تتطلب مُنهيًا فارغًا عند ربط مقبس (تُستخدم وسيطة \fIaddrlen\fP لتحديد طول \fIsun_path\fP) وعند استرجاع عنوان المقبس على هذه التطبيقات، لا يوجد مُنهٍ فارغ في \fIsun_path\fP. .P يمكن للتطبيقات التي تسترجع عناوين المقابس أن تُبرمج (بشكل محمول) للتعامل مع احتمالية عدم وجود مُنهٍ فارغ في \fIsun_path\fP باحترام حقيقة أن عدد البايتات الصالحة في اسم المسار هو: .P .in +4n .EX strnlen(addr.sun_path, addrlen \- offsetof(sockaddr_un, sun_path)) .EE .in .\" The following patch to amend kernel behavior was rejected: .\" http://thread.gmane.org/gmane.linux.kernel.api/2437 .\" Subject: [patch] Fix handling of overlength pathname in AF_UNIX sun_path .\" 2012-04-17 .\" And there was a related discussion in the Austin list: .\" http://thread.gmane.org/gmane.comp.standards.posix.austin.general/5735 .\" Subject: Having a sun_path with no null terminator .\" 2012-04-18 .\" .\" FIXME . Track http://austingroupbugs.net/view.php?id=561 .P بدلاً من ذلك، يمكن للتطبيق استرجاع عنوان المقبس بتخصيص مخزن مؤقت بحجم \fIsizeof(struct sockaddr_un)+1\fP يُصفّر قبل الاسترجاع. يمكن لاستدعاء الاسترجاع تحديد \fIaddrlen\fP كـ \fIsizeof(struct sockaddr_un)\fP، والبايت الصفري الإضافي يضمن وجود مُنهٍ فارغ للسلسلة المُعادة في \fIsun_path\fP: .P .in +4n .EX void *addrp; \& addrlen = sizeof(struct sockaddr_un); addrp = malloc(addrlen + 1); if (addrp == NULL) /* Handle error */ ; memset(addrp, 0, addrlen + 1); \& if (getsockname(sfd, (struct sockaddr *) addrp, &addrlen)) == \-1) /* handle error */ ; \& printf("sun_path = %s\[rs]n", ((struct sockaddr_un *) addrp)\->sun_path); .EE .in .P يمكن تجنب هذا النوع من الفوضى إذا تم ضمان أن التطبيقات التي \fIتنشئ\fP مقابس اسم المسار تتبع القواعد الموضحة أعلاه تحت \fIمقابس اسم المسار\fP. .SH أمثلة يظهر الكود التالي استخدام مقابس الحزم المتسلسلة للاتصال بين العمليات المحلية. يتكون من برنامجين. ينتظر برنامج الخادم اتصالاً من برنامج العميل. يرسل العميل كل وسيط من وسائط سطر الأوامر في رسائل منفصلة. يعامل الخادم الرسائل الواردة كأعداد صحيحة ويجمعها. يرسل العميل سلسلة الأمر "END". يرسل الخادم رسالة تحتوي على مجموع أعداد العميل الصحيحة. يطبع العميل المجموع ويخرج. ينتظر الخادم اتصال العميل التالي. لإيقاف الخادم، يُستدعى العميل مع وسيط سطر الأوامر "DOWN". .P تم تسجيل المخرجات التالية أثناء تشغيل الخادم في الخلفية وتنفيذ العميل بشكل متكرر. ينتهي تنفيذ برنامج الخادم عند استلامه الأمر "DOWN". .SS "مثال على الخرج" .in +4n .EX $\fB ./server &\fP [1] 25887 $\fB ./client 3 4\fP; Result = 7 $\fB ./client 11 \-5\fP; Result = 6 $\fB ./client DOWN\fP; Result = 0 [1]+ Done ./server $ .EE .in .SS "مصدر البرنامج" .\" SRC BEGIN (connection.h) \& .EX /* * File connection.h */ #ifndef CONNECTION_H #define CONNECTION_H \& #define SOCKET_NAME "/tmp/9Lq7BNBnBycd6nxy.socket" #define BUFFER_SIZE 12 \& #endif // include guard .EE .\" SRC END .P .\" SRC BEGIN (server.c) .EX /* * File server.c */ \& #include #include #include #include #include #include #include \& #include "connection.h" \& int main(void) { int down_flag = 0; int ret; int connection_socket; int data_socket; int result; ssize_t r, w; struct sockaddr_un name; char buffer[BUFFER_SIZE]; \& /* Create local socket. */ \& connection_socket = socket(AF_UNIX, SOCK_SEQPACKET, 0); if (connection_socket == \-1) { perror("socket"); exit(EXIT_FAILURE); } \& /* * For portability clear the whole structure, since some * implementations have additional (nonstandard) fields in * the structure. */ \& memset(&name, 0, sizeof(name)); \& /* Bind socket to socket name. */ \& name.sun_family = AF_UNIX; strncpy(name.sun_path, SOCKET_NAME, sizeof(name.sun_path) \- 1); \& ret = bind(connection_socket, (const struct sockaddr *) &name, sizeof(name)); if (ret == \-1) { perror("bind"); exit(EXIT_FAILURE); } \& /* * Prepare for accepting connections. The backlog size is set * to 20. So while one request is being processed other requests * can be waiting. */ \& ret = listen(connection_socket, 20); if (ret == \-1) { perror("listen"); exit(EXIT_FAILURE); } \& /* This is the main loop for handling connections. */ \& for (;;) { \& /* Wait for incoming connection. */ \& data_socket = accept(connection_socket, NULL, NULL); if (data_socket == \-1) { perror("accept"); exit(EXIT_FAILURE); } \& result = 0; for (;;) { \& /* Wait for next data packet. */ \& r = read(data_socket, buffer, sizeof(buffer)); if (r == \-1) { perror("read"); exit(EXIT_FAILURE); } \& /* Ensure buffer is 0\-terminated. */ \& buffer[sizeof(buffer) \- 1] = 0; \& /* Handle commands. */ \& if (!strncmp(buffer, "DOWN", sizeof(buffer))) { down_flag = 1; continue; } \& if (!strncmp(buffer, "END", sizeof(buffer))) { break; } \& if (down_flag) { continue; } \& /* Add received summand. */ \& result += atoi(buffer); } \& /* Send result. */ \& sprintf(buffer, "%d", result); w = write(data_socket, buffer, sizeof(buffer)); if (w == \-1) { perror("write"); exit(EXIT_FAILURE); } \& /* Close socket. */ \& close(data_socket); \& /* Quit on DOWN command. */ \& if (down_flag) { break; } } \& close(connection_socket); \& /* Unlink the socket. */ \& unlink(SOCKET_NAME); \& exit(EXIT_SUCCESS); } .EE .\" SRC END .P .\" SRC BEGIN (client.c) .EX /* * File client.c */ \& #include #include #include #include #include #include #include \& #include "connection.h" \& int main(int argc, char *argv[]) { int ret; int data_socket; ssize_t r, w; struct sockaddr_un addr; char buffer[BUFFER_SIZE]; \& /* Create local socket. */ \& data_socket = socket(AF_UNIX, SOCK_SEQPACKET, 0); if (data_socket == \-1) { perror("socket"); exit(EXIT_FAILURE); } \& /* * For portability clear the whole structure, since some * implementations have additional (nonstandard) fields in * the structure. */ \& memset(&addr, 0, sizeof(addr)); \& /* Connect socket to socket address. */ \& addr.sun_family = AF_UNIX; strncpy(addr.sun_path, SOCKET_NAME, sizeof(addr.sun_path) \- 1); \& ret = connect(data_socket, (const struct sockaddr *) &addr, sizeof(addr)); if (ret == \-1) { fprintf(stderr, "The server is down.\[rs]n"); exit(EXIT_FAILURE); } \& /* Send arguments. */ \& for (int i = 1; i < argc; ++i) { w = write(data_socket, argv[i], strlen(argv[i]) + 1); if (w == \-1) { perror("write"); break; } } \& /* Request result. */ \& strcpy(buffer, "END"); w = write(data_socket, buffer, strlen(buffer) + 1); if (w == \-1) { perror("write"); exit(EXIT_FAILURE); } \& /* Receive result. */ \& r = read(data_socket, buffer, sizeof(buffer)); if (r == \-1) { perror("read"); exit(EXIT_FAILURE); } \& /* Ensure buffer is 0\-terminated. */ \& buffer[sizeof(buffer) \- 1] = 0; \& printf("Result = %s\[rs]n", buffer); \& /* Close socket. */ \& close(data_socket); \& exit(EXIT_SUCCESS); } .EE .\" SRC END .P للحصول على أمثلة لاستخدام \fBSCM_RIGHTS\fP، انظر \fBcmsg\fP(3) و \fBseccomp_unotify\fP(2). .SH "انظر أيضًا" \fBrecvmsg\fP(2), \fBsendmsg\fP(2), \fBsocket\fP(2), \fBsocketpair\fP(2), \fBcmsg\fP(3), \fBcapabilities\fP(7), \fBcredentials\fP(7), \fBsocket\fP(7), \fBudp\fP(7) .PP .SH ترجمة تُرجمت هذه الصفحة من الدليل بواسطة زايد السعيدي . .PP هذه الترجمة هي وثيقة مجانية؛ راجع .UR https://www.gnu.org/licenses/gpl-3.0.html رخصة جنو العامة الإصدار 3 .UE أو ما بعده للاطلاع على شروط حقوق النشر. لا توجد أي ضمانات. .PP إذا وجدت أي أخطاء في ترجمة صفحة الدليل هذه، يرجى إرسال بريد إلكتروني إلى قائمة بريد المترجمين: .MT kde-l10n-ar@kde.org .ME .