1. وصف البنية يتميز البروتوكول الحالي بالخصائص التالية: 1) يرسل العميل طلبًا إلى الخادم، ويكون طول كل طلب متغيرًا ويتم تحديد طول الطلب في INT الأول. 2) يقدم كل خادم عادةً خدمات لعملاء متعددين، على سبيل المثال، يحتاج TS إلى تقديم خدمات لـ CP وNP في نفس الوقت. يوفر CP خدمات لـ NP وCPs الآخرين، وهو أيضًا عميل لـ CP وTS وSPs آخرين. 3) عندما يخدم كل خادم عميلاً، عادةً ما يكون ذلك طويل الأمد ويتضمن عدة طلبات وردود ذهابًا وإيابًا.
تم تصميم مثل هذا الهيكل بشكل أساسي لدعم عدد كبير من اتصالات العميل المتزامنة. عندما يكون هناك عدد كبير من اتصالات العميل المتزامنة، بغض النظر عما إذا تم استخدام الخيوط أو العمليات، لا يمكن تقديم خدمات فعالة، لذلك يجب استخدام التحديد. وضع الاقتراع.
2. وصف بنية البيانات الأساسية: لكل عميل، يجب حفظ بعض المعلومات المقابلة للعميل وهو في الأساس نفس بنية البيانات الأساسية لـ TSnew.c، والتي تتكون من الجلسة، وهو يتألف من SessionCluster (في TSnew.c) أو ServerDesc (CPnew.c وSPnew.c). من بينها، الجلسة هي البيانات المتعلقة بكل عميل، وSessionCluster (أو ServerDesc) هي المعلومات حول كل خدمة، والتي تحتوي على مؤشر لكل جلسة تتعلق بالخدمة لا يتم تخصيص بنية البيانات هذه ديناميكيًا عندما يكون هناك طلب من العميل، ولكن يتم تخصيصها عند التهيئة الأولية. عندما يأتي طلب عميل جديد، يبحث الخادم عن هذه الجلسات المخصصة مسبقًا ويجد أن هناك بعض الجلسات الخاملة ثم يستخدمها ذلك، والإبلاغ عن خطأ إذا لم يكن هناك وقت خامل.
بالنسبة لـ TS وCP(SP)، فإن الاختلاف الأكبر هو أن TS يستخدم بروتوكول UDP، بينما يستخدم CP وSP بروتوكول TCP. 1) بالنسبة لعملاء بروتوكول TCP، نظرًا لأن كل عميل يستخدم مقبسًا مختلفًا، بعد التحديد، ما عليك سوى التحقق من تعيين fd_set لكل عميل، بالنسبة لعملاء UDP، فأنت بحاجة إلى العثور على العميل المقابل الذي يستخدمه TS بعض التدابير لتقليل النفقات العامة الناجمة عن البحث. 2) في بروتوكول TCP، تكون البيانات المرسلة في شكل دفق، لذلك يجب تقسيم الرسالة إلى كتل، ومن الممكن قراءة رسالتين في قراءة واحدة، أو قد تحتاج الرسالة إلى القراءة عدة مرات يجب أخذ كلا الحالتين في الاعتبار، لذلك تحتوي كل جلسة على buf وrstart وrlen، والتي تُستخدم لتخزين الرسائل التي تمت قراءتها ولكن لم تتم معالجتها بعد. وبالمثل، أثناء عملية الكتابة، من الضروري أيضًا مراعاة أن الكتابة قد لا تكتمل في وقت واحد، لذلك من الضروري أيضًا الاحتفاظ بـ wbuf وwstart وwlen في كل جلسة. وهذا يختلف في UDP التنفيذ، من المفترض أن كل حزمة UDP تحتوي على رسائل كاملة، لذلك لم يتم تضمين هذه العناصر.
تصف SessionCluster (أو ServerDesc) الخدمة التي تتكون من عدة أجزاء رئيسية: 1) الجورب: يصف المقبس المستخدم 2) cur: عدد العملاء الحاليين 3) الحد الأقصى: الحد الأقصى لعدد العملاء الذين يمكن استيعابهم 4) الرأس: رأس الجلسة، الرأس[0] هو الجلسة الأولى، الرأس[max-1] هو الجلسة الأخيرة 5) init: عملية التهيئة التي يجب أن تقوم بها كل جلسة في هذه الخدمة (مؤشر الوظيفة). 6) العملية: وظيفة معالجة الرسائل في هذه الخدمة 7) الإغلاق: المدمر المطلوب في هذه الخدمة
3. وصف الهيكل الرئيسي
Process_child: الوظيفة الرئيسية، تُستخدم هذه الوظيفة بشكل أساسي لتعيين الجوارب وwsocks بالنسبة لـ SP وCP، يتم تعيين wsocks فقط عندما تكون الجلسة> 0؛ يختار؛ لكل ServerDesc (أو مجموعة الجلسة)، Process_type في SP وCP، من أجل دعم عملية PUSHLIST، يجب تنفيذ العملية قبل كل دورة. في CP، يتم تنفيذperiodCheck أيضًا بشكل دوري لمسح الاتصالات منتهية الصلاحية في TS، ويتم تنفيذperiodLog بشكل دوري لمسح اتصالات العملاء منتهية الصلاحية.
نوع_العملية: لكل جلسة، تحقق مما إذا كانت قابلة للقراءة، إذا كانت قابلة للقراءة، تحقق مما إذا كانت هناك رسالة كاملة. *(unsigned int *)(rbuf+rstart) <= rlen اتصل بالعملية المقابلة حتى لا تكون هناك رسالة كاملة للتحقق مما إذا كانت قابلة للكتابة. إذا كانت قابلة للكتابة و wlen>0، فاكتبها
4. وحدات أخرى مهمة 1) وحدة التكوين تتكون وحدة التكوين بشكل أساسي من بنية NamVal وread_config وfree_config. الاسم هو الاسم الموجود في ملف cfg، وptr هو المؤشر للتخزين، والنوع هو نوع البيانات المدعومة حاليًا d: نوع عدد صحيح، ptr هو مؤشر عدد صحيح s: نوع السلسلة، ptr هو مؤشر إلى مؤشر، (char **) ب: نوع المخزن المؤقت للسلسلة، ptr هو char *، يجب الانتباه عند استخدام هذا النوع، بالنسبة للنوع s، سوف يقوم read_config بتخصيص الذاكرة (malloc) للقيمة، ولكن بالنسبة للنوع b، يجب أن يشير ptr إلى الذاكرة المخصصة.
الوظيفتان المهمتان هما: read_config، المعلمات هي اسم الملف، وبنية NamVal *، وعدد عناصر البنية NamVal free_config، المعلمات هي نفس البنية NamVal * وعدد العناصر مثل read_config
2) وحدة الخلية تتكون وحدة MySQL بشكل أساسي من MYSQL *local_mysql وثلاث وظائف هي init_mysql، تهيئة mysql، إرجاع MYSQL *، يستخدم بشكل عام لتهيئة local_mysql query_mysql، تنفيذ عبارة MySQL، التنسيق هو query_mysql (local_mysql، "بيان mysql، التنسيق هو نفس تنسيق printf، مثل الحذف من %s، وما إلى ذلك."، القيمة المطلوبة) query_mysql_select، ينفذ عبارة تحديد mysql بشكل مختلف عما سبق، ويعيد ملف MYSQL_RES *.
3) تتكون وحدة فرز الشبكة بشكل أساسي من بنية الشبكات، ووظيفة readNETBLOCK، ووظيفة getnetwork، ووظيفة CompareNet، ومن بينها، يتم استخدام readNETBLOCK لقراءة ملف تكوين الشبكة وتهيئة المتغير العام NETBLOCKS مصفوفة من بنية الشبكات، تحتوي على MAX_NET من العناصر. يتم استخدام getnetowrk للعثور على netblock الأقرب إلى عنوان IP CompareNet هي وظيفة تُستخدم في qsort لفرز NPeers التي تم العثور عليها بحيث يتم ترتيب NPeers في نفس الشبكة في المرتبة الأولى.
4) إدارة الرسم البياني في CP وSP وNP الحالي، يمكن لـ CP الانضمام إلى قنوات متعددة في نفس الوقت، ويمكن أن يكون لدى NP أيضًا موارد متعددة لوصف هذا الهيكل، يتم تقديم مفهوم الرسم البياني لكل حافة (Edge ) يتم تخزين مؤشر إلى NP، مؤشر إلى القناة، في TS، من الضروري أيضًا تخزين كل فترة زمنية لهذه الجلسة في هذه القناة يتم دمج cnext in في قائمة مرتبطة. رأس هذه القائمة المرتبطة هو PeerHead في بنية القناة، وكل جلسة يتم أيضًا دمج enext في Edge في قائمة مرتبطة، ورأس هذه القائمة المرتبطة هو الرأس في بنية الجلسة. الوظائف ذات الصلة هي: newEdge: أضف حافة جديدة، المعلمات هي القناة *، الجلسة * بالنسبة إلى TS، هناك حاجة إلى ChannelInfo لتهيئة المعلومات في Edge. delEdge: حذف حافة، المعلمة هي Edge *
5) وحدة القناة الوظائف الرئيسية لوحدة القناة هي: يتم استخدام TS لمعالجة NEED_PEERS، ويحتاج SP أيضًا إلى حفظ بيانات القناة والبحث فيها، وتتم إدارة القنوات باستخدام هياكل الرسم البياني. يستخدم البحث عن القنوات التجزئة لأسباب تتعلق بالكفاءة. التجزئة، كما هو موضح في hash_str. القناة في TS بسيطة نسبيًا. تحتاج القناة في SP وCP أيضًا إلى إدارة البيانات المتعلقة بالقناة، ويتم تخزين هذه البيانات في الدليل /var/tmp/ على القرص الصلب في شكل ملفات. لكل جزء من المعلومات ذات الصلة، تم الحفظ بواسطة BlockData وfirstsampl وmessage_size وmessage_id والإزاحة في BlockData لتخزين معلومات العينة الأولى وطول الكتلة ومعرف الكتلة والإزاحة في الملف على التوالي. تختلف معالجة SP وCP بالنسبة لـ CP، حيث يتم تخزين الكتل في وضع التجزئة. على سبيل المثال، يكون معرف الكتلة هو 1000 max_queue هو 100، ثم موقع التخزين هو 1000%100=0 بالنسبة إلى SP، إذا كان المورد عبارة عن قناة مرسلة بواسطة CS، إنها قائمة انتظار دائرية، ويتم تخزين كل كتلة في الموضع المقابل بالترتيب. إذا وصلت إلى نهاية قائمة الانتظار، فإنها تبدأ من رأس قائمة الانتظار. إذا كان المورد ملفًا، فلن يتم حفظ معلومات BlockData. ويقع الملف الأصلي مباشرة وفقًا لمعرف الكتلة.
هناك العديد من الوظائف التي تتضمن القناة، مثل location_by_id، وlocate_order_by_id، وnewChannel، قناة مجانية، saveBlock، الخ.
6) وحدة Berkeley DB متضمنة فقط في SP، فهي تفتح بشكل أساسي ملفات DB وتستعلم عن موقع md5 معين، وتتضمن بشكل أساسي DB* MediaDB. الوظيفتان openDB وopenMedia openDB: المعلمة هي اسم ملف قاعدة البيانات openMedia: المعلمات هي md5 ومؤشر عدد صحيح، وإرجاع FILE * وطول الملف، في مؤشر العدد الصحيح
7) الوحدة الوظيفية يتم استخدام وحدة الوظيفة في CP وSP لمعالجة PUSHLIST. يمكن لرسالة PUSHLIST إعادة تعيين قائمة الوظائف. يمكنك أيضًا إضافة وظيفة أو حذفها. وهي تتضمن الوظائف الموجودة في job.c ويتم استخدام بنية JobDes جلسة * وقناة * في بنية JobDes لتحديد الجلسة والقناة التي تنتمي إليها الوظيفة يمثل num عدد BlockIDs التي يجب تنزيلها، والمهمة هي مؤشر لعدد صحيح، والقناع هو أيضًا مؤشر لعدد صحيح. job[i] هو BlockID الذي يجب تنزيله. إذا كان القناع [i] يساوي 0، فيجب تنزيله إذا كان 1، فلن تكون هناك حاجة إليه.
addJob: عند إضافة وظيفة، لا يتم التحقق مما إذا كانت الوظيفة موجودة بالفعل في القائمة، ولكن يتم إنشاء وظيفة مباشرة وإضافتها إلى القائمة المرتبطة. حذف الوظيفة: عند حذف مهمة، تحقق من جميع الوظائف في قائمة الوظائف بحثًا عن الوظائف التي لها نفس الجلسة والقناة. ثم قم بتعيين القناع المقابل لمعرف الكتلة الذي يجب حذفه على 1. ProcessJob: لكل مهمة، بدءًا من cur، استخدمprocess_P2P_REQUEST_real لإرسال الكتلة الأولى بالقناع 0. إذا كانت جميعها 1، فاحذف المهمة. freeJob: حذف JobDes. freeJobList: حذف جميع JobDes الخاصة بالجلسة، ويتم استخدامه عادةً عند إنهاء الجلسة.
8) وحدة الفاصل الزمني يتم استخدام وحدة الفاصل الزمني في TS لتمثيل جميع الفواصل الزمنية السريعة على NP. حاليًا، يتم تحديد الفاصل الزمني للكتلة بواسطة حقل البداية وحقل الطول. العمليات الرئيسية للفاصل الزمني هي الدمج والحذف والدمج فهو يجمع بين الفاصل الزمني الأصلي وقائمة الفواصل الزمنية الجديدة، بينما يقوم الحذف بإزالة القائمة الجديدة من القائمة الأصلية. الدمج: الخوارزمية هي كما يلي، وذلك باستخدام قائمة الفواصل الزمنية المؤقتة tmp. if (old[i] < new[j]) tmp[k] = old[i]; else tmp[k] = new[j]; ثم انظر إلى أي من القديم والجديد يمكن دمجه مع tmp[k] حذف: أكثر تعقيدًا، ضع في اعتبارك المواقف التالية بداية القديم[i] أعظم من نهاية الجديد[j] نهاية القديم[i] قبل بداية الجديد[j] القديم[i] والجديد[j] لهما أجزاء مشتركة، و القديم[i] موجود في الجديد[j] يتم تضمين new[j] في القديم[i] ولا يشمل بعضها البعض، ويتم تضمين new[j] في السابق ولا يشمل بعضها البعض، ويتم تضمين القديم[i] في السابق.
5. بعض الخوارزميات السريعة 1) في TS باستخدام UDP، عندما يقوم العميل بتسجيل الدخول لأول مرة، من الضروري العثور على جلسة خاملة. بالإضافة إلى ذلك، قد يرسل العميل رسائل تسجيل الدخول بشكل متكرر. في هذه الحالة، من الضروري التحقق مما إذا كان العميل كذلك موجودة بالفعل في قائمة الجلسات. ثالثًا، عندما يرسل العميل رسالة، فإنه يحتاج إلى العثور على الجلسة المقابلة. لتجنب هذه الاستعلامات، يتم استخدام الطرق التالية على التوالي. أولاً، قم بإنشاء جدول التجزئة. في البداية، يتم ربط جميع الجلسات المجانية بالتجزئة[0]. وعندما يأتي عميل جديد، يتم إخراج الجلسة من التجزئة[0] وربطها بالتجزئة المقابلة لا يمكن أن تكون القيمة التي تم الحصول عليها بواسطة التجزئة 0. إذا كانت 0، فسيتم إرجاع أكبر قيمة تجزئة ممكنة. الاستعلام عن الجلسة بناءً على المنفذ المصدر وعنوان IP يستخدم أيضًا جدول التجزئة هذا. عندما يرسل العميل رسالة، فإنه يستخدم أول 3 بايت من البايتات السبعة المستخدمة للتحقق، ويستخدم هذه البايتات الثلاث لتحديد الجلسة. منخفض، وبالتالي تجنب الحمل الاستعلام.
2) استخدم الحد الأقصى لتقليل عدد عمليات البحث. لا يتم استخدام التجزئة في TCP. يتم استخدام العنصر الأقصى لتسجيل أكبر معرف في الجلسة أثناء التهيئة، يتم البحث عن الجلسة الخاملة ذات المعرف الأصغر، لذلك يمكن اعتبار الجلسة مضغوطة نسبيًا. وبما أن SP وCP يدعمان عملاء أقل بكثير من TS، فإن هذا العلاج مقبول. عند خروج العميل، قد يكون من الضروري تحديث الحد الأقصى. يتم إكمال هذا التحديث بواسطة Clientclosure. يقوم Clientclosure بتحديث الحد الأقصى ثم يستدعي أداة التدمير المقابلة.
3) معالجة المهلة للاتصالات الخاملة طويلة المدى نظرًا لأن معالجة المهلة تتطلب اجتياز القائمة بأكملها، من أجل توفير موارد النظام. يستغرق IDLE وقتًا طويلاً، بالإضافة إلى ذلك، يلزم الإبلاغ عن إحصائيات النظام بشكل منتظم، ولهذا السبب، يلزم توفير الوقت المناسب. بشكل عام، تحددperiodLog أوperiodCheck أي من العمليتين سيتم تنفيذها.
4) عند الاستعلام عن CPPeer، مع الأخذ في الاعتبار أنه لا يتم دعم سوى GCP حاليًا، يتم استخدام GCPCHOICE مباشرةً، وتعيينه على GCP بأقل تحميل حالي، ويتم تحديثه عند تقارير GCP أو تسجيل الدخول والخروج من GCP.
6. معالجة الرسائل 1) معالجة رسائل TS NP2TS_LOGIN: يقوم NP بتسجيل الدخول إلى TS والتجزئة وفقًا لعنوان IP المصدر ومنفذ np المُبلغ عنه، إذا كان الوقت منذ آخر مرة تم فيها إرسال رسالة NP2TS_LOGIN أقل من SILENCE_TIME، فسيتم إرجاعه مباشرةً، وإلا فسيتم إرسال رسالة ترحيب. NP2TS_REPORT: معلومات الفاصل الزمني للتقرير إذا كان التحديث صحيحًا، فسيتم إعادة ضبطه، وإلا فسيتم إضافته أولاً ثم حذفه. NP2TS_NEED_PEERS: الاستعلام عن معلومات النظير، استخدم findCPPeer للعثور على CP المناسب، استخدم findNPPeers البحث عن NP مناسب عند البحث عن NP، بعد العثور على النتائج، يتم فرزها حسب الشبكات لضمان ترتيب تلك الموجودة في نفس الشبكة في المرتبة الأولى. NP2TS_LOGOUT: خروج NP2TS_RES_LIST: أرسل كل الموارد الخاصة بـ NP الحالي، واستخدم addSession للمعالجة، وإذا لم تكن هذه الحافة موجودة بعد، فأضفها NP2TS_REQ_RES: أضف RES وأرجع الزملاء NP2TS_DEL_RES: حذف RES
CP2TS_REGISTER: تسجيل الدخول، يقوم CP بتسجيل الدخول إلى TS، والتجزئة وفقًا لعنوان IP المصدر ومنفذ np المُبلغ عنه، إذا مر ILENCE_TIME منذ آخر مرة تم فيها إرسال CP2TS_REGISTER، فارجع مباشرةً، وإلا أرسل رسالة ترحيب. CP2TS_UPDATE: تقرير تحميل CP CP2TS_NEED_PEERS: يستخدم لاستعلام ECP، ولم يستخدم بعد
2) معالجة الرسائل SP P2P_HELLO: انضم إلى القناة، إذا كانت القناة موجودة، إذا كانت ملف وسائط: قم بإرجاع SPUPDATE، مع الإشارة إلى الحد الأدنى والحد الأقصى لمعرف الكتلة لهذه القناة بخلاف ذلك: إذا انتهت هذه القناة، قم بإرجاع معلومات النهاية. إذا كانت القناة غير موجودة، إذا كانت ملف وسائط: قم بإرجاع SPUPDATE، مع الإشارة إلى الحد الأدنى والحد الأقصى لمعرف الكتلة لهذه القناة، وقم بإنشاء القناة تشير إلى خطأ. P2P_PUSHLIST: إعادة تعيين قائمة المهام أو إضافتها أو حذفها عند إعادة التعيين، احذف جميع المهام ذات الصلة أولاً، ثم أضفها أو احذفها.
CS2SP_REGISTER: إنشاء قناة CS2SP_UPDATE: تحديث معلومات القناة CS2SP_BLOCK: إرسال كتلة البيانات
3) معالجة رسائل CP P2P_HELLO: انضم إلى قناة وأنشئ اتصالاً مطابقًا بناءً على عنوان SP المقدم P2P_PUSHLIST: إعادة تعيين أو إضافة وحذف قائمة المهام
P2P_SPUPDATE: SPUPDATE المرسل بواسطة SP، إذا كان ملف وسائط، فلن تتم إعادة توجيهه إلى NP P2P_RESPONSE: كتلة البيانات المرسلة بواسطة SP.
بالإضافة إلى ذلك، يحتاج CP أيضًا إلى التسجيل في TS. يوجد حاليًا نوع واحد فقط من Google Cloud Platform قيد الاستخدام.
