بروتوكول من عميل إلى عميل

تحتوي هذه المقالة على العديد من المشكلات. يُرجى المساعدة في تحسينها أو مناقشة هذه المشكلات على صفحة المناقشة . ( تعرف على كيفية ومتى يمكنك إزالة هذه الرسائل ) تحتاج هذه المقالة إلى مصادر إضافية للتحقق .الرجاء المساعدة في تحسين هذه المقالة عن طريق إضافة الاستشهادات إلى مصادر موثوقة . قد يتم الطعن في المواد غير الموثقة وإزالتها. ابحث عن المصادر:  "بروتوكول العميل إلى العميل" - الأخبار  · الصحف  · الكتب  · العلماء  · JSTOR ( يونيو 2024 )( تعرف على كيفية ومتى يمكنك إزالة هذه الرسالة ) تمت كتابة هذه المقالة كدليل أو دليل .من فضلك ساعد في إعادة كتابة هذه المقالة وإزالة النصائح أو التعليمات. ( يونيو 2024 ) ( تعرف على كيفية ومتى يمكنك إزالة هذه الرسالة )

بروتوكول العميل إلى العميل ( CTCP ) هو نوع خاص من الاتصالات بين عملاء الدردشة عبر الإنترنت (IRC).

CTCP هو بروتوكول شائع يتم تنفيذه بواسطة معظم عملاء IRC الرئيسيين المستخدمين اليوم. ^{[ بحاجة لمصدر ]} يمتد CTCP إلى بروتوكول IRC الأصلي من خلال السماح للمستخدمين بالاستعلام عن عملاء أو قنوات أخرى، وهذا يتسبب في رد جميع العملاء في القناة على CTCP للحصول على معلومات محددة. بالإضافة إلى ذلك، يمكن استخدام CTCP لتشفير الرسائل التي لا يسمح بروتوكول IRC الخام بإرسالها عبر الرابط، مثل الرسائل التي تحتوي على أسطر جديدة أو قيمة البايت 0 (NULL). لا ينشئ CTCP اتصالاً مباشرًا بين العملاء؛ ومع ذلك، يتم استخدامه عادةً للتفاوض على اتصالات DCC .

يتيح بروتوكول CTCP للمستخدمين الاستعلام عن إصدار العميل الذي يستخدمونه (عبر CTCP VERSION)، أو الوقت (عبر CTCP TIME)، من بين أشياء أخرى، من خلال عميل بعيد. كما يُستخدم أيضًا لتنفيذ الأمر /me (عبر CTCP ACTION).

كان ircII أول عميل IRC ينفذ بروتوكولي CTCP وDCC. ^[1] تم تنفيذ بروتوكول CTCP بواسطة Michael Sandrof في عام 1990 لإصدار ircII 2.1، ^[2] بينما تم تنفيذ بروتوكول DCC بواسطة Troy Rollo في عام 1991 للإصدار 2.1.2. ^[3]

يتم تنفيذ رسالة CTCP كـ PRIVMSGأو NOTICEحيث تكون الأحرف الأولى والأخيرة من الرسالة عبارة عن قيمة ASCII 0x01. بالإضافة إلى ذلك، يتم إفلات الأحرف التي لن يُسمح بها في بروتوكول IRC. نظرًا لأن a NOTICEكمعيار لا ينبغي أن يولد ردًا، يتم إرسال رسائل CTCP كـ PRIVMSGويتم تنفيذ الرد باستخدام a NOTICEبدلاً من PRIVMSG.

يتم بدء استعلام CTCP على معظم العملاء على النحو التالي:

CTCP <الهدف> <الأمر> <الحجج>

حيث أن <target> هو الاسم المستعار أو القناة المستهدفة، و <command> هو أمر CTCP (على سبيل المثال VERSION)، و <arguments> هي معلومات إضافية يجب إرسالها إلى <target> .

أوامر CTCP والردود عليها خاصة بالعميل؛ وبالتالي، اعتمادًا على عميل IRC، قد لا تؤدي بعض أوامر CTCP التالية إلى تشغيل استجابة، أو قد يتم تنسيقها بشكل مختلف عما هو موضح هنا.

سيقوم الطلب CTCP VERSIONبإرجاع اسم وإصدار عميل IRC الذي يستخدمه الهدف، وفي بعض الحالات المعلومات الفنية مثل نظام التشغيل ومعدل الساعة ومصنع وحدة المعالجة المركزية وهندسة وحدة المعالجة المركزية / مجموعة التعليمات .

نموذج الرد لطلب CTCP VERSIONموجه إلى هدف يستخدم عميل HexChat هو:

الإصدار HexChat 2.9.1 [x86] / Windows 8 [1.46GHz]

CTCP TIMEسيعيد الطلب الوقت المحلي للكمبيوتر المستهدف. اعتمادًا على عميل IRC، قد تتكون الإجابة من التاريخ والوقت ( إما بتنسيق 12 ساعة أو بتنسيق 24 ساعة ) والسنة ( مثل 2012) وأحيانًا المنطقة الزمنية (مثل EST ).

نموذج الرد لطلب CTCP TIMEموجه إلى هدف يستخدم عميل ChatZilla هو:

الوقت الجمعة 23 نوفمبر 2012 الساعة 19:26:42 بالتوقيت الشرقي

CTCP PINGسيحدد الطلب معدل ping الموجود مباشرة بين عميلين (أي خصم الخادم). CTCP PINGيعمل الأمر عن طريق إرسال وسيطة عددية صحيحة (طابع زمني ) إلى العميل المستهدف، ثم يستجيب العميل المستهدف عن طريق توفير نفس المعلمة الرقمية بالضبط. يتم حساب الفرق بين الطابع الزمني الأصلي والطابع الزمني الحالي، مع عرض النتيجة للمستخدم الذي بدأ CTCP PING . في أغلب الأحيان، يتم استخدام طابع زمني يستخدم مللي ثانية نظرًا لأن غالبية المستخدمين الذين لديهم اتصالات إنترنت ذات نطاق عريض لديهم ping أقل من ثانية واحدة.

نموذج CTCP PINGطلب لاستهداف <nickname> من عميل XChat هو:

CTCP PING 23152511

وبالمثل، فإن الناتج النموذجي الناتج عن الفرق (انظر أعلاه) هو:

رد Ping من <nickname>: 0.53 ثانية

تتيح خدمة CHAT للمستخدمين الدردشة مع بعضهم البعض عبر اتصال DCC. ^[4] ستنتقل حركة المرور مباشرة بين المستخدمين، وليس عبر شبكة IRC. عند مقارنتها بإرسال الرسائل بشكل طبيعي، فإن هذا يقلل من تحميل شبكة IRC، ويسمح بإرسال كميات أكبر من النص دفعة واحدة، بسبب عدم وجود التحكم في الفيضانات، ويجعل الاتصال أكثر أمانًا من خلال عدم تعريض الرسالة لخوادم IRC (ومع ذلك، لا تزال الرسالة في نص عادي ).

يتم عادةً بدء تشغيل DCC CHAT باستخدام مصافحة CTCP . يرسل المستخدم الذي يرغب في إنشاء الاتصال CTCP التالي إلى الهدف، حيث ip و port هما عنوان IP ورقم المنفذ للمرسل، ويتم التعبير عنهما كأعداد صحيحة. البروتوكول هو chat لـ DCC CHAT القياسي. يمكن للطرف المستقبل بعد ذلك الاتصال بالمنفذ وعنوان IP المحددين. DCC CHAT protocol ip port

بمجرد إنشاء اتصال، يكون البروتوكول المستخدم في DCC CHAT بسيطًا للغاية: يتبادل المستخدمون رسائل منتهية بـ CRLF . يتم تفسير الرسائل التي تبدأ بـ ASCII 001 (control-A، والممثلة أدناه بـ [^A] ) وكلمة ACTION ، والتي تنتهي بـ ASCII 001 آخر ، على أنها تعبيرات: . [^A]ACTION waves goodbye[^A]

هذا امتداد لـ DCC CHAT، يسمح بإرسال أوامر رسم بسيطة بالإضافة إلى أسطر نصية. يتم بدء تشغيل DCC Whiteboard بمصافحة مشابهة لـ DCC CHAT، مع استبدال بروتوكول الدردشة بـ wboard : . DCC CHAT wboard ip port

بمجرد إنشاء الاتصال، يتبادل العميلان الرسائل التي تنتهي بـ CRLF . يتم تفسير الرسائل التي تبدأ (وتنتهي اختياريًا) بـ ASCII 001 كأوامر خاصة؛ يمثل الأمر ACTION تعبيرًا تعبيريًا، بينما تتسبب أوامر أخرى في رسم خطوط على سطح السبورة البيضاء للمستخدم، أو تسمح للعميلين بالتفاوض على مجموعة من الميزات.

تتيح خدمة SEND للمستخدمين إرسال الملفات إلى بعضهم البعض. لم تسمح المواصفات الأصلية للمصافحة للمستقبل بمعرفة الحجم الإجمالي للملف أو استئناف النقل. وقد دفع هذا العملاء إلى تقديم امتداداتهم الخاصة للمصافحة، والتي أصبح العديد منها مدعومًا على نطاق واسع.

تتكون المصافحة الأصلية من قيام المرسل بإرسال CTCP التالي إلى المستقبل: . DCC SEND filename ip port

كما هو الحال مع DCC CHAT، فإن ip و port هما عنوان IP والمنفذ حيث سيستمع الجهاز المرسل إلى اتصال وارد. يضع بعض العملاء أسماء الملفات بين مسافات بين علامتي اقتباس مزدوجتين. ومن الممارسات الشائعة إضافة حجم الملف كحجة أخيرة: . DCC SEND filename ip port filesize

في هذه المرحلة، كان المواصفات الأصلية تتطلب من المتلقي إما الاتصال بالعنوان والمنفذ المحددين وانتظار البيانات، أو تجاهل الطلب، ولكن بالنسبة للعملاء الذين يدعمون امتداد DCC RESUME، فإن البديل الثالث هو مطالبة المرسل بتخطي جزء من الملف عن طريق إرسال رد CTCP: . DCC RESUME filename port position

إذا كان العميل المرسل يدعم DCC RESUME، فسوف يرد بـ ، ويمكن للمستقبل الاتصال بالعنوان والمنفذ المحددين والاستماع إلى البيانات لإضافتها إلى ملف موجود بالفعل. DCC ACCEPT filename port position

يتم إرسال البيانات إلى العميل في كتل، ويجب على العميل تأكيد استلام كل منها عن طريق إرسال العدد الإجمالي للبايتات المستلمة في شكل عدد صحيح من 32 بت لترتيب بايتات الشبكة . يؤدي هذا إلى إبطاء الاتصالات وهو أمر زائد عن الحاجة بسبب بروتوكول التحكم في الإرسال. يعمل امتداد الإرسال المسبق على تخفيف هذه المشكلة إلى حد ما من خلال عدم انتظار الإقرارات، ولكن نظرًا لأن المستقبل لا يزال يتعين عليه إرسالها لكل كتلة يستقبلها، في حالة توقع المرسل لها، فإن هذه المشكلة لا يتم حلها تمامًا.

هناك ملحق آخر، TDCC، أو turbo DCC، يزيل الإقرارات، لكنه يتطلب مصافحة معدلة قليلاً ولا يتم دعمه على نطاق واسع. استبدلت الإصدارات الأقدم من TDCC كلمة SEND في المصافحة بـ TSEND؛ تستخدم الإصدارات الأحدث كلمة SEND لكنها تضيف حرف T بعد المصافحة، مما يجعل هذا الإصدار من TSEND متوافقًا مع العملاء الآخرين (طالما يمكنهم تحليل المصافحة المعدلة).

يمكن أن يشير "استغلال إرسال DCC" إلى خطأين: خطأ تجاوز سعة المخزن المؤقت المتغير في mIRC الذي يتم تشغيله بواسطة أسماء ملفات أطول من 14 حرفًا، ^[5] وخطأ التحقق من صحة الإدخال في بعض أجهزة التوجيه المصنعة بواسطة Netgear و D-Link و Linksys ، والذي يتم تشغيله باستخدام المنفذ 0. ^{[6] [7]} قد يتم تشغيل استغلال جهاز التوجيه، على وجه الخصوص، عندما تظهر العبارة " DCC SEND " متبوعة بستة أحرف على الأقل بدون مسافات أو أسطر جديدة في أي مكان في دفق TCP على المنفذ 6667، وليس فقط عند إجراء طلب DCC SEND فعلي. في العقد الأول من القرن الحادي والعشرين، كان من الممكن دمج ثغرات متعددة في سلسلة واحدة، DCC SEND startkeylogger 0 0 0 ، والتي إذا تم نشرها في قناة عامة يمكن أن تتسبب في قطع اتصال العديد من المستخدمين (إما عن طريق تعطل عملاء IRC أو تعطل أجهزة التوجيه أو تشغيل إعدادات افتراضية صارمة للغاية في برنامج مكافحة الفيروسات). ^{[ بحاجة لمصدر ]}

خدمة XMIT هي نسخة معدلة من خدمة DCC SEND التي تسمح باستئناف الملفات وتقليص حركة المرور غير الضرورية من رسائل ACK الطويلة. لا يتم دعم خدمة XMIT على نطاق واسع.

تختلف مصافحة XMIT إلى حد ما عن مصافحة SEND. يرسل المرسل CTCP يعرض ملفًا على المستقبل:DCC XMIT protocol ip port[ name[ size[ MIME-type]]]

الأقواس المربعة هنا تحيط بأجزاء اختيارية. protocol هو البروتوكول الذي سيتم استخدامه للنقل؛ فقط clear هو المحدد حاليًا. على عكس DCC SEND القياسي، يمكن أن يكون ip في أشكال إضافية من التدوين المنقط القياسي لـ IPv4، أو إما تدوين سداسي عشري أو مختلط لـ IPv6. لترك معلمة مبكرة فارغة، مع الاستمرار في توفير معلمة لاحقة، يمكن تحديد المعلمة السابقة على أنها - . إذا لم ينفذ المستقبل البروتوكول المستخدم، فسوف يرسل رد CTCP بالتنسيق: . ERRMSG DCC CHAT protocol unavailable

يتم استخدام CHAT هنا للحفاظ على التوافق مع رسائل الخطأ المرسلة بواسطة CHAT الموسعة DCC. إذا رفض المتلقي التحويل، فإنه يرسل رد CTCP التالي: . ERRMSG DCC CHAT protocol declined

يتم الإبلاغ عن الأخطاء الأخرى بنفس الطريقة. إذا كان المتلقي راغبًا وقادرًا على استقبال الملف، فسوف يتصل بالعنوان والمنفذ المحددين. ما يحدث بعد ذلك يعتمد على البروتوكول المستخدم.

في حالة البروتوكول الواضح ، سيرسل خادم XMIT، عند تلقي اتصال، 32 بتًا بترتيب بايتات الشبكة ، وهو ما يمثل وقت تعديل الملف. ومن المفترض أن العميل سيرسل بعد ذلك ترتيب بايتات شبكة آخر بناءً على وقت تعديل الملف المحلي ، وهو الإزاحة التي يجب أن يسعى إليها الخادم عند إرسال الملف. يجب ضبط هذا على الصفر إذا كان الملف بأكمله مطلوبًا، أو حجم الملف المحلي إذا كان العميل يرغب في استئناف تنزيل سابق. time tlong

على الرغم من أن XMIT أسرع من SEND، إلا أنه يحمل أحد القيود نفسها حيث أنه من المستحيل معرفة حجم الملف، ما لم يتم تحديد حجمه في مفاوضات CTCP أو معرفته مسبقًا. علاوة على ذلك، من غير الممكن استئناف ملف يتجاوز علامة 2 جيجابايت بسبب الإزاحة 32 بت.

في اتصال DCC العادي، يعمل البادئ كخادم ، ويكون الهدف هو العميل . وبسبب انتشار جدران الحماية وانخفاض الشفافية من البداية إلى النهاية بسبب NAT ، فقد لا يتمكن البادئ من العمل كخادم. وقد تم ابتكار طرق مختلفة لطلب الهدف للعمل كخادم:

تم تقديم هذا الامتداد لـ DCC SEND وCHAT العاديين بواسطة عميل IRC mIRC . يتمتع خادم DCC بدعم معتدل، ولكنه ليس قياسيًا على جميع العملاء (انظر مقارنة عملاء Internet Relay Chat ).

يسمح ببدء اتصال DCC من خلال عنوان IP، دون الحاجة إلى خادم IRC. يتم إنجاز ذلك من خلال عمل العميل المستقبل كخادم (ومن هنا جاء الاسم) يستمع (عادةً على المنفذ 59) إلى مصافحة من المرسل.

بالنسبة للدردشة، يرسل المبادر . ثم يرد الهدف بـ ، ويستمر الباقي وفقًا لبروتوكول DCC CHAT القياسي. 1000 initiator nick1000 target nick

بالنسبة لعملية الإرسال، يرسل المبدئ . ويرد الهدف بـ ، حيث يكون موضع الاستئناف هو الإزاحة في الملف الذي يجب البدء منه. ومن هنا، يستمر النقل كإرسال DCC عادي. 1200 initiator nick filesize filename1210 target nick resume position

يدعم DCC Server أيضًا خوادم الملفات بنمط mIRC وDCC GET.

لا يوفر خادم DCC أي طريقة لتحديد المنفذ المراد استخدامه، لذا يجب التفاوض على ذلك يدويًا، وهو أمر غير ممكن دائمًا، حيث قد لا يكون أحد الطرفين إنسانًا. RDCC عبارة عن آلية مصافحة لخادم DCC، والتي توفر بالإضافة إلى المنفذ أيضًا عنوان IP الخاص بالخادم، والذي قد لا يتمكن العميل من العثور عليه بخلاف ذلك بسبب إخفاء المضيف. لا يتم دعمه على نطاق واسع.

يطلب المبدئ المنفذ الذي يستمع إليه الهدف عن طريق إرسال استعلام CTCP، حيث تكون الوظيفة هي c للدردشة، أو s للإرسال، أو f لخادم الملفات. RDCC function comment

قد يرد الهدف بعد ذلك بـ CTCP، حيث يكون لكل من ip و port نفس المعاني كما هو الحال بالنسبة لـ DCC SEND وCHAT العاديين. بعد ذلك، يتصل المبادر بـ ip و port ، ويتبع ذلك مصافحة خادم DCC. RDCC 0 ip port

على عكس خادم DCC، حيث تتم معالجة المصافحة عبر اتصال IP مباشر، فإن DCC REVERSE لديه مصافحة CTCP عادية، مماثلة لتلك المستخدمة بواسطة DCC SEND. هذا غير مطبق على نطاق واسع. يقدم المرسل ملفًا إلى المستقبل عن طريق إرسال رسالة CTCP: . key عبارة عن سلسلة من الأحرف ASCII بطول 1 إلى 50 حرفًا في النطاق 33 إلى 126، ويعمل كمعرف للنقل. DCC REVERSE filename filesize key

إذا قبل المستقبل، فإنه يرسل رد CTCP،DCC REVERSE key start ip port

هنا، start هو الموضع في الملف الذي يجب أن تبدأ منه عملية الإرسال، وip هو عنوان IP للمستقبل بالترميز المنقط القياسي لـ IPv4 ، أو الترميز السداسي عشر لـ IPv6 . ثم يتصل المرسل بعنوان IP والمنفذ الذي يشير إليه المستقبل، ويتبع ذلك إرسال DCC عادي. يمكن لكل من المرسل والمستقبل إلغاء المصافحة عن طريق إرسال رد CTCP، . DCC REJECT REVERSE key

هذا هو البديل الذي يقدمه عميل KVIrc لـ DCC REVERSE. يقدم المرسل ملفًا عن طريق إرسال CTCP: . ثم يمكن للمستقبل قبول ذلك عن طريق الرد بـ CTCP بـ ، ويتصل المرسل بالمستقبل ويرسل كما هو الحال أثناء إرسال DCC العادي. DCC RSEND filename filesizeDCC RECV filename ip port start

يتم دعم آلية DCC السلبية هذه على الأقل بواسطة mIRC و Visual IRC و HexChat و KVIrc و DMDirc و Klient و Konversation و PhibianIRC. يقدم المرسل ملفًا عن طريق إرسال رسالة CTCP، . ip هو عنوان IP للمرسل بترتيب بايتات الشبكة، معبرًا عنه كعدد صحيح واحد (كما هو الحال في DCC القياسي). يتم إرسال الرقم 0 بدلاً من منفذ صالح، مما يشير إلى أن هذا طلب DCC عكسي. الرمز هو عدد صحيح فريد؛ إذا تم استخدام TSEND (من قبل عميل يدعمه)، يتم إلحاق الحرف T بالرمز، مما يتيح للمستقبل معرفة أنه لا يحتاج إلى إرسال إقرارات. DCC SEND filename ip 0 filesize token

يمكن للمستقبل قبول الملف عن طريق فتح مقبس استماع والاستجابة برسالة CTCP، . وهذا مماثل لرسالة Reverse DCC الأصلية، باستثناء أن عنوان IP والمنفذ يحددان المقبس الذي يستمع إليه المستقبل. الرمز هو نفسه الموجود في الطلب الأصلي، مما يتيح للمرسل معرفة الطلب الذي يتم قبوله. (نظرًا لأن هذه الرسالة تتبع نفس تنسيق طلب إرسال DCC العادي، فقد تتطلب بعض الخوادم التي تقوم بتصفية طلبات DCC من المرسل إضافة المستقبل إلى قائمة "DCC allow" الخاصة بها.) DCC SEND filename ip port filesize token

يقوم المرسل بعد ذلك بالاتصال بمقبس المستقبل، وإرسال محتوى الملف، وينتظر المستقبل لإغلاق المقبس عند انتهاء الملف.

عند استخدام ملحق RESUME لبروتوكول SEND، تصبح تسلسل الأوامر (مع الإشارة >> إلى رسالة صادرة على الجانب المبدئي، و << استجابة من نظيره):

>> DCC SEND filename ip 0 filesize token
<< DCC RESUME filename 0 position token
>> DCC ACCEPT filename 0 position token
<< DCC SEND filename peer-ip port filesize token

وبعد ذلك يمضي البروتوكول بشكل طبيعي (أي يتصل المرسل بمقبس المستقبل).

يتيح خادم الملفات DCC fserve ، أو خادم الملفات، للمستخدم تصفح الملفات وقراءتها وتنزيلها الموجودة على خادم DCC.

عادةً، يتم تنفيذ ذلك باستخدام جلسة DCC CHAT (التي تعرض على المستخدم موجه الأوامر) أو أوامر CTCP خاصة لطلب ملف. يتم إرسال الملفات عبر DCC SEND أو DCC XMIT. هناك العديد من تطبيقات خوادم ملفات DCC، من بينها أمر FSERV في عميل mIRC الشهير .

• الدردشة عبر الإنترنت (IRC)
• عميل IRC
• مقارنة بين عملاء Internet Relay Chat
• DCC (التعامل المباشر من العميل إلى العميل)

• تفاصيل CTCP