فهرس المحتويات مقدمة...6 دوافع المشروع :...7 مراحل المشروع وأهدافه :...7 الفصل األول : Streaming مقدمة : : Media Streaming : St

النسخ

1 فهرس المحتويات مقدمة...6 دوافع المشروع :...7 مراحل المشروع وأهدافه :...7 الفصل األول : Streaming مقدمة : : Media Streaming : Streaming Methods : Streaming Protocols -1-4 الفصل الثاني : Shoutcast : Shoutcast Server : Winamp Media Player 2-2 الفصل الثالث : : 15...:Ubuntu 2-1 اعداد خدمة Shoutcast 3-1 -إعداد مخدم وتحقيقها وتحقيق الخدمة :...21 Shoutcast في بيئة 3-2- إعداد المصدر( (Winamp الفصل الرابع :...24 تحليل الخدمة...24 تحليل بروتوكوالت الخدمة وألية العمل :...24 تحليل سيناريوهات مطبقة على الخدمة : السيناريو األول :...32 الثاني السيناريو الفصل الخامس : Power saving Mode 5-1 مقدمة : المعيار : IEEE

2 5-3 استراتيجيات تقليل استهالك الطاقة : مقارنة بين الصيغتين MP3 و AAC و مراقبة استهالك الطاقة المراجع :

3 فهرس األشكال الشكل : 1 1 الشكل Streaming Procedure 1-2 حاالت بروتوكول 11...RTSP الشكل :3-1 انشاء حساب جديد...15 الشكل 3-2 تنزيل Shoutcast server archive for linux الشكل 3: 3 الشكل : فك الضغط نسخ الملفات الى مسار الServer...16 الشكل 3-5 ملف االعدادات الخاص الشكل 3-6 بالمخدم...17 أجل تشغيل sc_server من المسار الحالي...17 الشكل: 3-7 اختبار حالة ال 18...server الشكل : 3-8 الشكل : 3-9 الشكل تنزيل ال...18 firewall فتح البورت واجهه المخدم بعد اعداده...19 الشكل : 3-11 التحكم باعدادات المخدم...19 الشكل : 3-12 التحكم بإعدادات المخدم الشكل : script for start and stop الشكل : 3-14 جعل الملف قابل للتنفيذ...20 الشكل : 3-15 تشغيل المخدم باستخدام في ال 20...background الشكل : 3-16 تشغيل المخدم في الforeground...21 الشكل : 3-17 واجهه الDSP Shoutcast sourve الشكل : 3 18 معلومات المخدم الشكل : 3-19 معلومات المخدم...23 الشكل : 3-20 معلومات المخدم...23 الشكل : 4-1 الطرود المتبادلة بين المخد م والمصدر...25 الشكل 4-2 البيانات المتبادلة بين المصدر والمخد م...26 الشكل 4-3 بيانات الصوت المرسلة...27 الشكل 4-4 شكل الMetadata...27 الشكل: 4-6 البيانات المرسلة من قبل الزبون

4 الشكل 4-7 البيانات المرسلة من قبل المخد م الشكل 4-8 البيانات المتبادلة بين الزبون والمخد م...29 الشكل 4-9 الرسائل المتبادلة بين الزبون والمخد م...30 الشكل 4-10 البيانات المتبادلة بين الزبون والمخد م...30 الشكل 4-11 الرسائل المتبادلة بين الزبون والمخد م...31 الشكل 4-12 البيانات المتبادلة بين الزبون والمخد م...31 الشكل 4-14 مخطط round trip time الشكل : 4-15 اإلنتاجية باستخدام مخطط...33 الشكل 4-16 مخطط Time sequence الشكل 4-18 النافذة الشكل 4-17 مخطط االنتاجية Expert Infos الشكل warnings الشكل 4-20 الشكل رسائل الwarnings الطرود المعاد ارسالها...37 الشكل 4-23 رسائل ال...38 Notes الشكل 4-24: مخطط I/O الشكل : 4-25 رسائل االشعارات المكررة الشكل 4-26 مخطط I/O الشكل 4-27 : مخطط Time sequence تناقص االنتاجية الشكل: 4-28 التأخير مخطط...42 I/O الشكل : 4-29 الشكل : 43...delays between TCP packets and ACKs 4-30 العالقة بين اعاده االرسال والتأخير...43 الشكل : Round Trip Time الشكل : 4-32 رسائل الجهاز ذو العنوان الشكل : 4-33 زمن وصول االشعار...45 الشكل : Round Trip Time الشكل: 4-35 مخطط Round Trip Time ورسائل الجهاز ذو العنوان الشكل : 4-36 زمن وصول االشعار

5 5 لكشلا 4-37 : ةيجاتنلإا ةزهجلأل ثلاثلا لكشلا : 4-38 ططخم ةيجاتنلإا Stream8لل لكشلا : 4-39 ططخم ةيجاتنلإا لل لكشلا 4-40 ططخم ةيجاتنلإا stream 16لل لكشلا : 4-41 ططخم هيجاتنلاا stream 18لل لكشلا : 4-42 هذفان Expert Infos لكشلا : nots لكشلا : لئاسر 4-44 لا nots لكشلا : 4-45 ططخم ليلحتI/O ةيجاتنلإا لكشلا : 4-46 Chats لكشلا : 4-47 لئاسرلا هصاخلا لكشلا : 4-48 ليلحت ريخأتلا : لكشلا ريخأتلا مادختساب I/O ططخم :لكشلا كلاهتسا ةقاطلا لكشلا 5-4 : كلاهتسا 61...ةقاطلا لكشلا 5: ريخأتلا لكشلا 5-6: لمحلا ىلع جلاعملا لكشلا 5-7: مادختسا ةركاذلا لكشلا 5-8: كلاهتسا ةقاطلا لكشلا 5-9: لمحلا ىلع جلاعملا لكشلا 5-10: مادختسا ةركاذلا لكشلا 5-11 : كلاهتسا ةقاطلا لكشلا 5-12: ريخأتلا :لكشلا لمحلا ىلع جلاعملا لكشلا : 5-14 مادختسا ةركاذلا لكشلا 5-15: كلاهتسا 66...ةيراطبلا لكشلا 5-16: لمحلا ىلع جلاعملا لكشلا 5-17: مادختسا ةركاذلا 66...

6 مقدمة : مر الراديو بأوقات عصيبة وأزمات كبرى هددت وجوده واستمراره مع ظهور التليفزيون وانزوى في ركن صغير وقص ر موجاته على عشاق الرياضة والمسافرين والركاب والمراهقين من عشاق الموسيقى وكبار السن وظل الراديو يكافح باستماته لكي يبقى ويستمر عقودا عديدة حتى كتبت له والدة جديدة بفضل ثورات اإلنترنت واالتصاالت. أصبح اآلن بإمكان أي شخص من أن يقيم محطة إذاعية خاصة به تبث أفكاره وتعزز عالقاته بجمهوره ومحيطه الخارجي ولم تعد إقامة المحطات اإلذاعية قاصرة على الدول والحكومات فبفضل اإلنترنت أصبح بإمكان المدرس والبلدية والشركة والجامعة والمؤسسات والجمعيات الخيرية واألهلية واألحزاب إنشاء محطات الراديو الخاصة بها في غضون ساعات. يتوازى ظهور راديو اإلنترنت مع تطور تكنولوجيا البث المتتابع والتطورات األخيرة في معدات الصوت حيث يمكنك االستماع إلى الكمبيوتر بنفس الطريقة التي استمع بها الجيل السابق إلى جهاز الراديو وإذا كنت متصال باإلنترنت يمكنك التقاط األصوات من جميع أنحاء العالم. من مزايا مذياع الشبكة )اإلنترنت( انخفاض تكلفة اإلدارة والتشغيل حيث ال حاجة الستئجار معدات إلكترونية وأسالك للتوصيل وخالفه وال حاجة لتوظيف تقنيين إلدارة المحطة. كما تتميز محطات اإلذاعة في الشبكة بعدم الحاجة إلى المنافسة على نطاقات التردد بخالف المحطات اإلذاعية التقليدية. راديو اإلنترنت موجود منذ نهاية التسعينات حيث استخدمت محطات اإلذاعة التقليدية اإلنترنت في بث برامجها وفقراتها في نفس الوقت وبالتزامن مع األثير الوسيط األصيل للبث اإلذاعي بمعنى أنه يمكنك االستماع إلى نفس الفقرة أو البرنامج عبر جهاز الراديو أو عبر اإلنترنت في نفس الوقت دون أي تأخير أو إبطاء. طور كارل ماالمود أول محطة راديو إنترنت في التاريخ في عام 1993 واستخدمت محطة ماالمود تقنية أسماها عصب البث المتعدد على االنترنت باستخدام بروتوكول. MBONE يمر راديو اإلنترنت حاليا بثورة ستؤدي إلى توسيع نطاق اتساعه ومداه بحيث يستطيع أي شخص استقبال البث اإلذاعي من أي مكان وفي أي وقت. بالمقارنة بالراديو التقليدي ال يقتصر راديو اإلنترنت على الصوت حيث يمكن مصاحبة البث اإلذاعي عبر اإلنترنت بالصور أو الرسومات والنصوص أو الروابط باإلضافة إلى التفاعلية مثل غرف الدردشة ولوحات الرسائل ويتيح هذا التطور للمستمع أن يفعل أكثر من مجرد االستماع فمن الممكن أن يقوم المستمع الذي يستمع إلعالن عن طابعة أن يطلب شراء هذه الطابعة من خالل رابط على موقع هذه المحطة وبذلك تصبح العالقة بين المعلنين والمستهلكين أكثر تفاعلية في محطات راديو اإلنترنت ويوسع ذلك من إمكانيات الوسائط بعدة طرق فمن خالل راديو اإلنترنت يمكنك إجراء التدريب أو التعليم و تقديم روابط للمستندات وخيارات الدفع والسداد ويمكنك كذلك التفاعل مع المتدرب أو المعلم وغيرها من المعلومات من موقع محطة راديو اإلنترنت. 6

7 دوافع المشروع : انطالقا من المقدمة التي تحدثنا فيها عن اإلمكانات التي يتيحها راديو اإلنترنت لكل شخص ببناء إذاعته الخاصة كانت فكرة المشروع بناء إذاعة ذات مواصفات قياسية و دقيقة ليست باألمر السهل أو العشوائي لذلك ال بد من دراسة الموارد التي ستقدم لهذه اإلذاعة من معدل نقل و صيغة الضغط المعتمد و عرض الحزمة و ما هو االستهالك األمثل من هذه الموارد لتحقيق جودة الخدمة و إنتاجية مقبولة بإجراء هذه الدراسة نستطيع مجاراة سوق العمل ومتطلبات الزبائن والتكيف مع اإلمكانات المادية المتوفرة لدينا. م ارحل المشروع : وأهدافه نقدم من خالل هذا المشروع دراسة عملية عن خدمات البث عبر الشبكة نحاكي من خاللها البث اإلذاعي عبر اإلنترنت ونتعرف على هذه الخدمة ضمن بيئة Shoutcast Server و تحليل أدائها عبر Wireshark و من ثم إجراء دراسة تقريبية الستهالك الطاقة ضمن الهواتف الذكية و بعض الحلول المتبعة للتخفيف من هذه المشكلة. انطالقا من التعرف على مفهوم Streaming و أنواع البروتوكوالت المستخدمة في هذه العملية [11] و من ثم كيفية تحقيقها عن طريق [9] Shoutcast server و مشغل الموسيقا Shoutcast server وذلك بعد التعرف بشكل نظري مفصل على ال [10] Winamp [2][3] انتهاءا باستقبال الخدمة عبر أجهزة استقبال( (Mobiles. عن طريق برنامج [4] Wireshark نقوم بتحليل بروتوكول الخدمة السابقة وماهي أية عمله [1][5][7][8] وما هو شكل البيانات التي يتعامل معها [6] و من ثم تحليل أداء الخدمة وفق نماذج متعددة تشمل عدة حاالت ( مستقبل واحد أو عدة مستقبلين ) مع تحديد قيم بارامترات التأخير واإلنتاجية وغيرها من بارامترات جودة الخدمة. في القسم األخير نقدم دراسة لمفهوم حفظ الطاقة ضمن البيئة المستخدمة من أجل اإلضاءة على هذه المشكلة التي تعتبر تحديا كبيرا أمام الهواتف الذكية عند استعراض Video أو Audio عبر الشبكات الالسلكية مع تقديم بعض االستراتيجيات التي تساهم في الحد من استهالك الطاقة من قبل بطاريات الهواتف الذكية.[11] تجدر اإلشارة أن جميع القياسات تم ت ضمن بيئة شبكة حقيقية ( كما سنرى الحقا ) وليست عبر برامج محاكاة حيث فضلنا اتباع طريقة Measurement في تحليل الخدمة وذلك من أجل تقديم نتائج دقيقة و حقيقية قدر اإلمكان. 7

8 الفصل األول : Streaming - مقدمة : 1-1 Video بينما يتم أو Audio هي العملية التي يتم من خاللها تشغيل ملفات Streaming تحميلها من اإلنترنت. : من خالل هذه التقنية يستطيع المستخدمون تشغيل الوسائط الرقمية دون الحاجة إلى تخزين ملف الوسائط المشغل محليا". إن المحطة الراديوية عبر اإلنترنت تتمتع بكلفة منخفضة وسهولة في االستخدام وخاصة فيما يتعلق باستخدام األدوات البرمجية و المتمثلة هنا في Shoutcast server والمدعوم من عدة بروتوكوالت وال سيما ICY مع زيادة في فعالية عرض الحزمة Bandwidth و زيادة في التفاعل هذا النوع من المخد مات يقدم دفق ) (stream من الصوت إلى المستخدمين الذين يستخدمون أنواع مختلفة من مشغالت الوسائط ومنها. winamp Media Streaming بث الصوت عبر شبكات الحاسب : بث الصوت ) (Audio والذي هو عبارة عن تدفق مستمر لبيانات الصوت باتجاه واحد من المخدم إلى واحد أو أكثر من مستقبلي الخدمة ) (clients. Streaming audio يستخدم بشكل واسع لبث الموسيقا األخبار واألحاديث عبر اإلنترنت. األهداف العامة لنظام بث الصوت عبر اإلنترنت : الموثوقية التوسعية ( من خالل زيادة عدد المستخدمين عن طريق الزيادة في عرض الحزمة ) األمان والحماية من خالل حفظ معلومات حقوق النشر سهولة في االستخدام لتحقيق األهداف السابقة يتم استخدام العديد من البروتوكوالت منها : بروتوكوالت الزمن الحقيقي ) protocols (real-time بروتوكوالت التسليم الموثوق ) protocols (reliable-delivery بروتوكوالت النقل بالزمن الحقيقي مثل ) protocols UDP (User datagram يحقق االستجابة السريعة. الذي

9 فلتحقيق النقل بالزمن الحقيقي و تحقيق السرعة يجب استخدام المميزات التي تقدمها مجموعة البروتوكوالت السابقة. إن نظام بث الوسائط الكامل يعمل من خالل إنشاء و تخديم ومن ثم تشغيل الوسائط على البرنامج الموجود لدى المستخدم و الذي هو عبارة عن مشغل موسيقا. العناصر المفتاحية التي يتضمنها هذا النظام إلنجاز المهمة على أكمل وجه يشمل العمليات التالي : : Capturing المدخل إلنشاء Streaming Media هو الحصول على الصوت أو الفيديو ( محتوى الوسائط ) المراد بثه من المصدر التماثلي ) source (analog ومن ثم عملية digitize و تخزين الوسائط على القرص. Editing :بعد أن تم تخزين Media Stream فإننا باستخدام أدوات معينة نستطيع تعديلها وذلك لتضمين Meta data ولتحقيق التكامل والحصول على Multimedia. Presentation : Encoding حالما تنتهي عملية Editing نستطيع البدء بترميز المحتوى إلى الصيغة المناسبة مع تحديد الدقة rate frame وغيرها. و ربما هذا يتطلب إنشاء ملفات مفصلة لنفس المحتوى وفق معد ل بيانات مختلف وذلك من أجل دعم أكبر عدد من المستخدمين والتعامل مع التغيرات المخالفة بعرض الحزمة. : Servering عند هذه المرحلة تكون الوسائط مشفرة و بالتالي جاهزة من أجل تقديمها للمستخدمين حيث تقوم المخدمات بتقديم محتوى الوسائط عن طريق بروتوكول نقل مناسب. Playing :بعد أن يتم استقبال الطلب من قبل المستخدم الطالب للخدمة يبدأ مشغل الوسائط الخاص بالمستخدم باستقبال Media stream ليتم تشغيلها. 9

10 Streaming Procedure الشكل : 1 1 : Streaming Methods 1-3 يوجد لدينا نمطين من : Streaming Methods : On demand في هذه الحالة يكون محتوى الوسائط متاح للجميع ويتم تسليمها عند الطلب. لتحقيق هذه العملية يتم تسجيل محتوى الوسائط مسبقا" ويكون للمستخدمين إمكانية التحكم من خالل,pause, stop وحتى إمكانية االنتقال إلى إطارات جديدة. : Live Streaming من خاللها يتم تقديم الخدمة ( محتوى الوسائط ) إلى المستخدمين في غضون ثوان قبل أن يتم العرض كما أنه يمكن للعديد من المستخدمين الوصول إلى نفس محتوى الوسائط في نفس الوقت. في هذه الطريقة ال يتمتع المستخدمون بإمكانية التحكم بالstream كتأخير أو تقديم و ذلك ألن العرض يتم في الزمن الحقيقي كما أن هذه الطريقة تتطلب وجود buffer )مخزن مؤقت ) عند المستخدم لتخزين الجزء الصغير المستقبل من المصدر قبل عرضه ليتم حذف محتوى buffer بعد أن يتم عرضه. : Streaming Protocols -1-4 عمليات التخديم المتعلقة بنظام الوسائط أصبحت أسهل مع استخدام بروتوكوالت طبقة التطبيقات حيث تكون البروتوكوالت هي المسؤولة عن التحكم بنمط الجلسة وعمليات تغليف البيانات والتحكم بعمليات التسليم. بروتوكوالت تدفق البيانات ) protocol ( streaming المتعارف عليه ضمن طبقة التطبيقات هي عبارة عن بروتوكوالت تعمل ضمن الزمن الحقيقي و منها : 10

11 : RTSP(real time streaming protocol ) وهو عبارة عن بروتوكول يعمل ضمن طبقة التطبيقات وذلك ليؤسس ويتحكم بعدة جلسات وسائط )يؤسس و يتحكم بالخدمات المتعلقة بالوسائط المتعددة ( فهو يقدم إطار موسع يسمح باختيار قنوات التسليم RTP UDP,TCP or و ذلك اعتمادا" على آلية التسليم. إن جلسة RTSP تبدأ عنما يقوم المستخدم بطلب الحصول على الوسائط من المخدم المخدم يصن ف كل جلسة بمعر ف خاص بها وهذا المعر ف يمثل حالة مشتركة بين المخد م والمستخدم و يستخدم في عمليات التحكم. جلسة RTSP ال يتم تقييدها ببروتوكول معين من بروتوكوالت طبقة النقل فخالل جلسة RTSP يمكن للمستخدم أن يستخدم UDP ليرسل و يستقبل رسائل التحكم أو رب ما يؤسس عدد من اتصاالت. TCP إن RTSP يقد م بعض االختالفات عن HTTP ومنها : RTSP مستقل عن البروتوكوالت الموجودة في طبقة النقل. مخدم RTSP يمكنه حفظ حالته افتراضيا" والشكل التالي يوض ح هذه الحاالت : الشكل 1-2 حاالت بروتوكولRTSP. RTP كل من الزبون والمخدم يمكنهما معالجة طلبات RTSP بيانات الوسائط يمكن تحميلها عبر بروتوكوالت يدعمها RTSP منها 11

12 : HTTP Streaming Protocol هناك عدة خدمات بث متوفرة وتتطلب مخدمات و بروتوكوالت خاصة لتقديم محتوى الوسائط إلى المستخدمين. إن RTSP يتطلب وجود بروتوكولين أساسيين في عمله هما RTP & RTCP أما HTTP فإنه يعتمد في عمله على TCP كما أن البث يتم من خالل طلبات HTTP لهذا السبب فإن HTTP Streaming يستهلك الجزء األكبر من عرض الحزمة المستخدمة وهو يستخدم HTTP pseudostreaming Pseudo streaming حيث يتم تشغيل الملف بينما يتم تحميله كما إن تستخدم بروتوكوالت التسليم الموثوق وبشكل أخص نسخ معدلة عن HTTP. TCP عبر اتصال Protocols إن HTTP Streaming تتضمن صيغ وسائط متنوعة مثل MP3, flash video وغيرها كما أن ها تتضمن خدمات متنوعة نذكر منها : : QuickTime HTTP Streaming Protocol Microsoft Media HTTP Streaming Apple HTTP Streaming Protocol Shoutcast Streaming Protocol في موضوع دراستنا سوف نتناول Shoutcast Streaming Protocol على هذه الخدمة بشكل عملي ونقوم بدراستها وتحليل أدائها. بالتفصيل ونتعرف 12

13 الفصل الثاني : Shoutcast : Shoutcast Server 2-1 يعتبرserver Shoutcast إحدى التقنيات التي تستخدم لبث ملفات الصوت المرمزة بصيغة.MP3 وهي عبارة عن تقنية (MP3) MPEG layer3 ترتكز خدمتها على تقديم الملفات الصوتية ألي مستخدم يقوم باالتصال عبر IP موافق للمخدم هذا ال IP يتم وضعه عند ضبط إعدادات المخدم ومن خالله يستطيع طالبو الخدمة الحصول عليها واستقبال الملفات عن طريق مشغالت الموسيقا المتنوعة مخدم Shoutcast صدر في عام 1998 من قبل Nullsoft يمكن تحميله بشكل مجاني و استخدامه لكنه غير مفتوح المصدر. هو عبارة عن server) DNAS(distributed network audio يستطيع بث بيانات الصوت المخزنة ضمنه كما بإمكانه تمرير المحتوى الصوتي من المصدر عبر الشبكة إلى المتلقين. برمجيات Nullsoft تقد م DSP-Plug_in خاصة بمشغل الموسيقا winamp والتي تسمح لهذا المشغل أن يقوم بدور المصدر ل DNAS مع هذه البنية يكون عرض الحزمة الخاصة بالمخدم هو العامل الحاسم في تحديد عدد الدفقات التي يمكن دعمها. 100kbps دفقات MP3 عادة تستخدم (50-150)kbps 15 مستمع )مع إهمال حمولة ) tcp. وبذلك تكون تستطيع أن تخدم يعمل Shoutcast من خالل نسخة معدلة من HTTP protocols وهي yell) ICY (I can ألرسال الصوت بصيغ MP3 عبر اتصال TCP دفقات Shoutcast يمكن الوصول إليها من خالل العديد من مشغالت الموسيقا الشائعة ومنها winamp, vlc ملفات قوائم التشغيل ذات الالحقة pls المحددة من قبل URL الخاصة بالمخدم يمكن الوصول إليها عبر الويب من خالل المواقع المخصصة لمحطات البث اإلذاعي عبر اإلنترنت. عندما يتم تحميل قوائم التشغيل ضمن مشغل الوسائط المتصل إلى المخدم المحدد عبر port. audio المحدد يتم تخزين البيانات التي تمثل number إن النظام الذي يقوم علية مخدم Shoutcast يقدم تقنية إلنشاء webcaster وذلك من خالل Sender) Shoutcast DNAS (Distributed Network Audio هذه البرمجيات تفع ل عند المرسل )المصدر( المرتبط مع IP الشبكة وفق عرض حزمة متوافق مع استقبال الصوت 13

14 عند webcaster ومن خالل عملية التحديث المستمر لمحتوى Shoutcast استالمه ومن ثم إرساله إلى المستخدمين. الذي يتم Shoutcast سوف يستقبل اتصال من مشغ ل الموسيقا ( وهنا حالما يبدأ البث فإن مخدم ال stream المرسلة من المصدر( (Winamp إلى كل استخدمنا ) Winamp لكي يقوم بث Shoutcast DSP يقبل االتصال القادم من Winamp عن طريق مستخدم. مخدم Shoutcast. Winamp والتي هي جزء من مشغل الموسيقا يتم ضبطها عند القيام بإعدادات plug-in إن streaming server في هذه الحالة هو عبارة عن تطبيق برمجي هذا التطبيق يحم ل مباشرة على الحاسب المستخدم ليقوم بوظيفة Broadcaster والمتض من المحتوى الصوتي بصيغة MP3 : Winamp Media Player 2-2 وهو عبارة عن مشغل موسيقا مستخدم في نظام التشغيل windows تم تطويره و تقديمه من كأداة متوافقة مع Shoutcast streaming وبشكل عام يعر ف على أنه قبل Nullsoft. Shoutcast مشغل MP3 ويستخدم بشكل مرتبط مع Shoutcast باستخدام DSP plug-in يكون مشغل Winamp عبارة عن واجهة لمخدم وبذلك فإن Webcasting تكون عملية بسيطة تتطلب عدة خطوات من اختيار صيغة MP3 Shoutcast لتتم بعدها عملية البث الشبكي. وتأسيس االتصال مع مخدم من أهم مميزات ال : Winamp يدعم صيغ MP3 يقدم أدوات تخصيص للمستخدمين متوافق مع مخدم Shoutcast 14

15 الفصل الثالث : : اعداد خدمة Shoutcast وتحقيقها حين نريد اعداد خدمة يجب أن نبحث أوال في األلية التي تعمل وفقها هذه الخدمة ما هي المتطلبات الالزمة لكي تعمل بنجاح. بالنسبة ل Shoutcast radio stream فأننا نحتاج إلى اعداد المخدم في بيئة Ubuntu وتنصيب مشغل الموسيقى الذي سوف يقوم بدور المصدر الذي يزود المخدم بالبيانات التي سوف يقوم ببثها وهو Winamp media player كما ذكرنا سابقا 3-1 -إعداد مخدم في بيئة Shoutcast :Ubuntu ضمن بيئة عمل Ubuntu يتم إنشاء حساب باسم radio من خالل التعليمات المبينة في الصورة أدناه.. الشكل :3-1 انشاء حساب جديد بعدها يتم الدخول إلى radio Account الذي تم إنشاؤه إلكمال اإلعدادات الالزمة لعمل. download & server هما two directories إنشاء.يتم Shoutcast server Shoutcast server archive for linux ضمن مسار ال download خالل سطر األوامر التالي : تنزيل يتم من 15

16 الشكل 3-2 تنزيل Shoutcast server archive for linux sc_serv ضمن download موضح : بوجد الملف الثنائي يتم فك ضغط هذا الملف كما هو logs & الشكل :3 3 فك الضغط يتم إجراء عملية نسخ ل sc_serv إلى مسار ال server control وإنشاء كل من الشكل : 3-4 نسخ الملفات الى مسار الServer لتشغيل ال server وضبط اإلعدادات الخاصة به نحن بحاجة إلى إنشاء ملف إعدادات : home/radio/server ضمن المسار التالي sc_serv.conf يتم تحديد server's ip سوف يتم البث عبرها. وهو عنوان ال ip الذي يدخله المستخدم عندما يتصل بالشبكة التي 16

17 : 8000 number port هذا ال port خاص بخدمة بالبروتوكول TCP ويقدم خدمة Shoutcast عبر هذا المنفذ وسوف نتطرق الى هذه الفكرة مفصال في الفصول الالحقة. Admin login : admin, password2 Server login : admin, password الشكل 3-5 ملف االعدادات الخاص بالمخدم من أجل تشغيل sc_server من المسار الحالي الذي نعمل به والذي هو server directory نضع الملف ضمن background ومن ثم نفتح المتصفح الخاص بنا وفق ال url التالية : :8000 الشكل 3-6 أجل تشغيل sc_server من المسار الحالي port ويتم استخدام األمر netstat لمعرفة فيما إذا كان ال server numbers التي يتنصت عليها. يعمل وما هي ال 17

18 الشكل: 3-7 اختبار حالة الserver حتى اآلن فإن ال server يعمل لكنه غير قادر على استقبال اتصاالت لذلك ال بد من ضبط إعدادات firewall من خالل إضافة القاعدة التي تسمح بفتح ال 8000 port:. الشكل : 3-8 تنزيل الfairwawll الشكل : 3-9 فتح البورت 8000 ضمن المتصفح يتم إضافة url المتضمنة number: 8000 port. Shoutcast server لتظهر الواجهة الخاصة ب Ip :

19 من خالل ملف الشكل 10-3 واجهه المخدم بعد اعداده server يتم التحكم بإعدادات ال sc_serv.conf الشكل : 3-11 التحكم باعدادات المخدم الشكل : 3-12 التحكم بإعدادات المخدم executable script ضمن ومن أجل استخدام أوامر بسيطة لتشغيل ال server المسار التالي : Usr/local/bin نقوم بإنشاء 19

20 الشكل : 3-13 script for start and stop نجعل الملف السابق قابل للتنفيذ : لتشغيله ضمن الشكل : 3-14 جعل الملف قابل للتنفيذ radio start daemon server نكتفي باألمر بعد ذلك من أجل تشغيل. background الشكل : 3-15 تشغيل المخدم باستخدام في الbackground 20

21 . radio stop واألمر radio start لتشغيله ضمن foreground ومن أجل إيقفه الشكل : 3-16 تشغيل المخدم في الforeground اآلن أصبحت إعدادات المخد م جاهزة ويستطيع أي زبون متصل على الشبكة طلب عنوان المخد م للحصول على خدمة الراديو ولكن ال يمكن للمخد م أن يقدم الخدمة إال بعد أن نقوم بإعداد المصدر -3-2 إعداد المصدر( (Winamp وتحقيق الخدمة : كما ذكرنا أن المصدر هو عبارة عن مشغل الموسيقي winamp ولكن هناك برمجيات خاصة يجب تنصيبها باإلضافة الى مشغل الموسيقى تدعم عمليه البث من ال winamp الى ال Shoutcast server إذن يجب علينا : أوال : تنصيب مشغل موسيقى winamp في بيئة العمل ثانيا : تحميل وتنصيب البرمجية -dsp Shoutcast من أجل االتصال مع المخدم. Shoutcast نفتح مشغل الموسيقى ثم نختار options ثم preferences source dsp v2 3.5 فتظهر لدينا الواجهة التالية : ثم DSP/Effect ثم الشكل : 3-17 واجهه الDSP Shoutcast sourve وهنا نقوم بإدخال إعدادات المخد م و إعدادات اإلرسال التي نرغب بها كمديري المحطة 21

22 تعيين المعلومات التي تم وضعها في ملف إعدادات المخد م وهي عنوان ال ip رقم ال port كلمة السر الخاصة بعملية االتصال بين المصدر والمخدم وهي هنا password3 كما تم تحديدها في ملف اإلعدادات )1 : 3 الشكل 18 معلومات المخدم تعيين اسم المحطة التي نقوم بإنشائها ونوع الموسيقى الذي سوف نقوم ببثه ونجعل هذه المحطة عامه ليراها جميع المتصلين على الشبكة كما يتم تحديد ال home page للراديو ولكن لسنا بصدد هذا الموضوع ألننا نقوم بتحقيق خدمه الراديو في شبكة محلية وليس على شبكة األنترنيت. )2 22

23 الشكل : 3-19 معلومات المخدم تحديد نمط التشفير المطبق على ال audio المرسل ومعدل البتات الذي يتم اإلرسال وفقه ونميز هنا نوعين من التشفير هما mp3 و ADTS-AAC )3 الشكل : 3-20 معلومات المخدم بعد االنتهاء نقوم باالتصال بعد ان نقوم بتشغيل المخدم radio start المصدر المخدم ويبدأ انتقال البيانات من 23

24 الفصل ال اربع : الخدمة تحلي ل اآلن سوف ندرس آلية عمل بروتوكول Shoutccst protocol_icy بشكل مفصل من خالل تحليل الرسائل المتبادلة ما بين المصدر والمخد م وبين المخد م والزبون وسوف نستخدم Wiresharkوهو برنامج قياس يقوم بمراقبة الرسائل والطرود المتبادلة عبر الشبكة ويقوم بعرض محتوى كل طرد ويوفر لنا طرق وأساليب ومخططات تمكننا من فهم وتحليل ما يجري ضمن الشبكة. 4-1 تحليل بروتوكوالت الخدمة وألية العمل : ICY هو بروتوكول معد ل من HTTP إلرسال اإلطارات ذات الصيغة MP3 من مخدم. (clients ) إلى المت لقين DNAS يستخدم هذا البروتوكول مع مخدم Shoutcast وسوف ندرس بالتفصيل الترويسات الخاصة بهذا البروتوكول من خالل دراستنا آللية عمل الخدمة باستخدام Wireshark بين المصدر والمخد م ينشأ المصدر اتصال الى بورت الخدمة) 8000( يرسل المصدر كلمه السر اذا كانت كلمة السر صحيحة يرد المخد م بالموافقة ok هذا يعلم المصدر بشكل اساسي أن المخد م قام بالمصادقة مع ال DSP ليكون مصدرا وأنه جاهز الستقبال البيانات. اذا لم تكن الكلمة صحيحه سوف يرسل المخد م password( )invalid اذا استقبل المصدر رسالة الموافقة من المصدر فانه يبدأ بإرسال معلومات حول ال stream للمخد م وهي غالبا بهذا الشكل : )1 )2 )3 )4 icy-name:unnamed Serverrn icy-genre:unknown Genrern icy-pub:1rn icy-br:56rn icy-url: icy-irc:%23shoutcast rn 24

25 icy-icq:0rn icy-aim:n%2farn rn وبعدها يبدأ المصدر بإرسال البيانات الصوتية icy-name اسم المحطة icy-genre نوع االغاني التي تبثها المحطة icy-pub تتعني بشكل اساسي السماح للمخد م بنشر نفسه في الدليل او ال ) 1 تعني نعم, 0 تعني ال ) icy-br معدل البتات المستخدم في التدفق icy-url الصفحة الرئيسية للتدفق icy-irc is yp Shoutcast specific *تستخدم من اجل معلومات االتصال icy-icq is yp Shoutcast specific *تستخدم من أجل معلومات االتصال icy-aim is yp Shoutcast specific *تستخدم من اجل معلومات االتصال يمكن ان نرى أيضا : c:en: memnmc:enyo-tnocnoc نوع البيانات في هذا التدفق تخبر المخدم فيما اذا كان يحتاج الى افراغ الbuffer icy-reset: 1rn اآلن سنرى كيف يتم انتقال الطرود وتبادل الرسائل بين المصدر والمخد م من خالل االتصال بعد إدخال المعلومات األساسية لالتصال في مشغل الموسيقى تبدأ عملية تبادل الرسائل في هذا المثال لدينا : Server ip : Source ip : مراقبة 4-1 الطرود المتبادلة بين المخدم والمصدر الشكل : 25

26 الشكل 4-1 يظهر الطرود المتبادلة بين المخدم والمصدر حيث ترسل ضمن حقل ال data لل. packet فيما يلي سنرى المعلومات المتبادلة بشكل واضح : اللون األزرق هي الرسائل التي يرسلها المخدم للمصدر أما اللون االحمر فهي من المصدر للمخدم. الشكل 4-2 البيانات المتبادلة بين المصدر والمخد م كما ذكرنا سابقا المصدر يرسل كلمه السر للمخدم وبعد موافقة المخدم على الكلمة يبدأ بإرسال معلومات حول التدفق والمصدر بعد سماح المخدم بذلك وهي تتضمن في هذا المثال نوع المحتوى audio اسم المحطة green نوع الموسيقا misc عنوان الصفحة الرئيسية Shoutcast.com نالحظ وجود كود xml تظهر فيه المعلومات التي تظهر على واجهة المخد م في المتصفح وبعد ذلك يبدأ إرسال ال audio stream بين المخدم ر والزبون يكون هناك معلومات على شكل metadata عن األغنية التي يتم تشغيلها حاليا يجب ان ننتبه الى جزئيين من بروتوكول : Shoutcast الطلب الذي يشكله الزبون ليبدأ استقبال ال stream وشكل االستجابة متضمنه اآللية request reply 26

27 الزبون والذي يمكن تمثيله بمشغل موسيقى vlc او أي مشغل أخر يتصل مع المخد م عن طريق ارسال request. HTTP GET في هذا الطلب الزبون يسأل عن تغذية محددة بشكل مشابه تماما لطلب صفحة ويب في ترويسه الطلب يصرح الزبون عن إمكانيه استقباله ال metadata ويرسل أيضا معلومات خاصه متعلقة به. ترويسه الIcy-Metadata مهمه جدا ألنها اشارة إلى أن الزبون قادر على استقبال الMetadata في تدفق الصوت stream.( )audio بالنسب لإلجابة التي يرسلها المخد م أكثر ما يهمنا هو header. icy-metaint بشكل نموذجي تحمل القيمة 8192 والتي تعبر عن عدد البايتات في كل MP3-block مرسل, بما أن معدل البتات لتدفق الصوت هو 128kb/s فإن 8192 byte block سوف يحتوي على نصف ثانية من الموسيقا الشكل 4-3 بيانات الصوت المرسلة الmeta-data تأتي على شكل سلسلة من البتات بعد كل block. audio طول السلسلة 16*N حيث أن N عدد صحيح يصرح عنه في البايت االول من ال. block, meta data أكبر قيمة يمكن أن يأخذها N هي 255 وبالتالي يكون أقصى طول ممكن 4080 نالحظ أن طول الdata meta يأخذ القيمة 0 أغلب الوقت وهذا يعني أنه ال يوجد, meta data الdata meta ترسل بشكل طبيعي في موقعين معينين : مباشرة بعد االتصال )الربط( وعندما تتغير األغنية وهنا سوف تستغرق بعض الوقت للحصول على الكتلة األولى حيث تستخدم هنا إلرسال عنوان األغنية الفنان ومعلومات أخرى عند ارسال كامل المعلومات الالزمة في ال metadata وبقاء بتات فارغة فإنها تحشى أصفار الشكل 4-4 شكل الMetadata 27

28 اآلن سوف نراقب تسلسل الرسائل المتبادلة بين الزبون والمخد م الحصول عليها منذ طلب الزبون للخدمة حتى الشكل 4-5 الرسائل المتبادلة بين الزبون والمخدم للمخد م يتم توليد رسالة الطلب عند فتح المتصفح في جهاز الموبايل وإدخال عنوان ال url وهي وهي طلب Get http عادية تتضمن رسالة الطلب مجموعه من الheaders Host وهو ip &port المخد م Connection يحوي القيمة Keep_aliveاشارة من الجهاز الى استعداده الستقبال الرد على نفس المقبس قبولها في جسم رسالة يحدد من خاللها أنواع البيانات التي يستطيع ال client Accept اإلجابة User-Agent إخبار المخد م بأنواع المتصفحات التي يستطيع ال client التعامل معها Accept -Language اخبار المخد م باللغات التي يستطيع إرسال اإلجابة بها اخبار المخد م عن أنماط التشفير التي يتعامل بها الclient Accept -ENCODING الشكل: 4-6 البيانات المرسلة من قبل الزبون 28

29 رسالة الرد يتم توليدها من قبل المخد م وتخبر الclient أن الموقع الذي طلبه موجود 302 Status وذلك ضمن الLine found وضمن ال : headers نوع المحتوى الذي يتضمنه الموقع ونوع التشفير المستخدم وطول المحتوى باإلضافة الى عنوان الموقع. الشكل 4-7 البيانات المرسلة من قبل المخد م بعد ذلك يقوم الزبون بتأكيد طلب الموقع بعد أن تأكد من وجوده ويخبر المخد م الزبون أن الطلب قد نجح 200 ok ويرسل له المحتوى الذي طلبه )صفحه الويب( الشكل 4-8 البيانات المتبادلة بين الزبون والمخد م 29

30 الشكل 4-9 الرسائل المتبادلة بين الزبون والمخد م يتم توليد الطلب التالي عند الضغط على الخيار listen في صفحه الويب الظاهرة على شاشة الموبايل وتتضمن نوع مشغل الموسيقى الذي يستخدمه ال ) VLC( client وان االتصال سوف يغلق بعد أن يكتمل الرد باإلضافة الى icy-metadata:1 الذي تحدثنا عنه سابقا تخبر رسالة االجابة الزبون أن الطلب قد نجح باالضافة الى نوع المحتوى وطوله وان االتصال تم اغالقه. وفي جسم اإلجابه يوجد معلومات خاصة بالراديو كالنسخة واسم القناة وعنوان ال url للملف المطلوب كما هو واضح في الصورة التالية: الشكل 4-10 البيانات المتبادلة بين الزبون والمخد م 30

31 الشكل 4-11 الرسائل المتبادلة بين الزبون والمخد م تتضمن رسالة الطلب من قبل الزبون الحصول على مورد والدخول المخد م لسماع الstream في حين يرد المخد م بأن الطلب قد نجح نالحظ أن المخد م يرسل البيانات ضمن tcp segment سنرى اآلن ماذا تتضمن هاتين الرسالتين : الشكل 4-12 البيانات المتبادلة بين الزبون والمخد م أهم ما تحويه رساله الطلب icy-metadata:1 بينما نالحظ ظهور الترويسات الخاصة ببروتوكول icyفي رسالة اإلجابة وهي الترويسات التي تحدثنا عنها في الفقرات السابقة وهي : icy-url icy-br icy-metaint icy-pub icy-genre icy-name باإلضافة الى نوع المحتوى وبعد ذلك يبدأ الزبون باستقبال الstream 31

32 4-2 تحليل سيناريوهات مطبقة على الخدمة : بعد أن تعرفنا على اآللية التي تعمل بها الخدمة سوف نقوم بافتراض سيناريوهات لكي ندخل بعمق األداء ولمعرفه ما هي األمور التي تؤثر في أداء الخدمة وكيف تؤثر. mobile السيناريو األول : عقدة وحيدة تطلب الخدمة وهي عبارة ولفتره معينه ثم ينتقل بشكل عشوائي عن جهاز يكون ثابت عند طلب الخدمة هو 128 stream ip الجهاز الزبون هو ومعدل االرسال من قبل المخدم bit/sec وبما أن االرسال الفعلي للبيانات )الموسيقى( وال metadata يكون في واحدة فإننا سوف نركز دراستنا على هذه ال stream لتحليل الخدمة الشكل 4-13 الرسائل المتبادلة بين الزبون والمخد م سيناريو 1 عند تحليل خدمه معينه أو نظام هناك العديد من االسئلة التي يجب أن نطرحها ما الشي الذي تقوم به هذه الخدمة وما هي األمور التي تؤثر سلبا على األداء ما هو البروتوكول الذي تقوم عليه هذه الخدمة ماهي األمور التي يمكننا القيام بها لتحسين االداء هذه األسئلة وغيرها سنجيب باستخدام األدوات التي يقدمها ال Wireshark كما نعرف أن Shoutcast radio server يحقق اتصال موثوق من خالل بروتوكول TCP ومن المهم في هذه الناحية أن نعلم كم من الوقت يستغرق وصول الطرد إلى المستقبل وعودة االشعار بذلك. 32

33 الشكل 4-14 مخطط round trip time نالحظ من الشكل أن معظم األرقام التسلسلية للبيانات المرسلة من المخد م الى الزبون تم اشعارها في فتره زمنيه صغيره ال تتجاوز 0.2 sec وهي الحالة المستقرة أما الحاالت غير المستقرة المشار لها في الرسم فأنها تؤثر على أداء البروتوكول وبما أن الخدمة المقدمة ال تتطلب وجود تأخير فإن احتمال وجود حاالت عدم استقرار مرتبط بطبيعة الخدمة أمر مرفوض وبالتالي فان هذا التأخير يدل على وجود مشاكل. االنتاجية )throughput( : الشكل : 4-15 اإلنتاجية باستخدام مخطط I/O 33

34 باستخدام مخطط I/O نرى المخطط باللون األسود يمثل ال Traffic الكلية في الخدمة أما اللون األحمر فيمثل ال traffic الخاصة بال stream 4 التي تحوي البيانات الرئيسية نالحظ في المخطط أن اإلنتاجية تصل الى أقل من byte/sec تزداد في لحظات معينه وتنقص في لحظات أخرى وسوف نتعرف على االسباب المؤدية الى هذا التأرجح لمالحقه السلوك الذي يسلكه المخد م الذي يقدم الخدمة نستخدم مخطط Time-Sequence ( Stevens )يبين هذا المخطط تقدم نقل البيانات مع مرور الوقت الشكل 4-16 مخطط Time sequence من الشكل نالحظ أن البيانات تنتقل من ال Shoutcast server الى الزبون طالب الخدمة بشكل متزايد )قطري( مع انخفاض في معدل النقل في اللحظان ما بين 250_300 ثانيه من عمليه االرسال )كما هو مؤشر باللون األحمر( وتظهر االنقطاعات في الخط أن هناك مشاكل في عمليه االرسال هذه المشاكل ناتجه عن أمور سوف نقوم بدراستها بالتفصيل مثل اعادة ارسال الطرود أو االشعارات المكررة وقد ظهرت عند تحريك الزبون وابعاده عن نقطه الوصول التي تربطه مع المخد م... يمكننا حساب االنتاجية إلرسال البيانات في لحظه معينه من المخطط كما يلي اإلنتاجية = عدد البايتات المنقولة / الزمن مثال في الثانية 120 والثانية 240 تكون اإلنتاجية متساوية Byte/sec /120= /240=16667 أي أن االنتاجية غير مستقرة وهذا ما سوف نراه ضمن مخطط اإلنتاجية. من الشكل نالحظ أن االنتاجية متباينة ما بين byte/sec و byte/sec ولكن عمليه االرسال الفعلية وكما هو ظاهر تكون حوالي 16000byte/secوهو ما وجدناه بمخطط. time sequence 34

35 الشكل 4-17 مخطط االنتاجية اآلن سوف نستخدم اإلمكانيات التي يتيحها ال Wireshark في الخدمة. لتحديد المشاكل والعيوب الموجودة النافذة Expert Infos وهي احد الخيارات الموجودة في الWireshark الشكل 4-18 النافذة Expert Infos 35

36 في البداية سوف نقوم بشرح لمحتويات هذه النافذة : : Errors وتتضمن معلومات عن مشاكل تعتبر ذات أهمية عالية وتتصف بأنها جدية كحدوث تعديالت ضمن الطرود أو فقدان حقول ضمنها. TCP التحذيرات تتضمن حدوث مشاكل ضمن التطبيق أو االتصال مثل : Warnings window full, TCP widow zero, out-of order segment وأمور أخرى تعتبر على أنها سلوك غير طبيعي للبروتوكول. Notes :هنا ال Wireshark يشير إلى حدث من شأنه أن يسبب مشكلة ولكن البروتوكول ال يزال ضمن السلوك الطبيعي. مثال TCP re-transmission يمكن أن تظهر هنا على الرغم من أنها تعتبر حدث مهم ألنها تبطئ عمل الشبكة لكن عمل البروتوكول يبقى ضمن المستوى الطبيعي. TCP يتم تزويدنا بمعلومات عن سير العمل الطبيعي وعلى سبيل المثال :هنا Chats connection start (SYN),connection end (FIN), connection reset. (RST ). ordered list معلومات عن كل األحداث ضمن :يعطي Details : Packet Comments يعطي إمكانية إضافة تعليقات بشكل يدوي إلى كل طرد. من الشكل السابق نالحظ أنه ال يوجد errors األسباب التي أدت إلى حدوثها. أما بقيه المشاكل سوف نناقشها بالتفصيل وما هي warnings الشكل 4-19 warnings عند تحليل الطرود في الشبكة ظهر نوعين من ال warning Out-of-order packet :وهذا يحدث عندما يظهر طرد له رقم تسلسلي أقل من الرقم التسلسلي للطرد السابق الذي تم استقباله في ذلك االتصال. 36

37 الشكل 4-20 رسائل الـ warnings معظم الطرود الواصلة في ترتيب خاطئ هي ضمن ال stream 0 بين المخد م والمصدر وعند مالحقه التدفق ضمن ال stream 0 نالحظ انه ال يوجد إعادة ارسال للطرود أو اشعارات مكرره وهذا يدل على ان هذه المشكلة هي مشكلة التقاط باإلضافة الى وجود 3 اشعارات لم تتم رؤيتها وهذه اإلشعارات هي لطرود واصلة بترتيب خاطئ ولكن ما يهمنا هو الطرود الواصلة ضمن ترتيب خاطئ ما بين المخد م والزبون وعددها 3 نستطيع أن ندرك أن هذا الوصول يسبب مشكلة من خالل الطرود المعاد ارسالها واإلشعارات المكررة التي يرد من خاللها بروتوكول tcp على الطرود الواصلة بترتيب خاطئ. الشكل 4-21 الطرود المعاد ارسالها 37

38 Notes إعادة اإلرسال Retransmissions الشكل: 4-22 Notes الشكل 4-23 رسائل ال Notes الى الزبون إعادة االرسال هو بورت الخدمة كما نرى إن جميع الطرود المعاد أرسالها هي من المخد م اي أن البورت الذي يتم عبره 38

39 Shoutcast (8000) بالنظر الى مخطط I/O نرى أن الخط غير مشغول الشكل :4-24 مخطط I/O وبالتالي فإن السبب وراء إعادة االرسال هو إما أن المستقبل بطيء) وهو السبب الحقيقي بالفعل ألن عمليات إعادة االرسال حدثت بشكل كبير عندما اصبح الجهاز بعيد عن نقطه االتصال التي تربطه بالمخد م ) أو أن هناك مشكله بالمخد م. إشعارات مكررة وسرعة إعادة اإلرسال Duplicate ACKs and fast retransmissions عندما تصبح الشبكة بطيئة فمن اإلرسال السريعة. أحد األسباب المؤدية لذلك هي اإلشعارات وإعادة المكررة وفي معظم األحيان فإن سبب اإلشعارات المكررة قد يكون االختالف في التأخير ( delayed )variations او high latency أو أن نقطة النهائية بطيئة مما يعني ببساطة أنها ال تستجيب لإلشعارات 39

40 4-25 رسائل االشعارات المكررة الشكل : بالتأكيد إعادة اإلرسال واإلشعارات المكررة بينهما عالقة وثيقة كما نالحظ أن االشعارات المكررة تكون من المخد م الى المصدر وذلك في ال STREAM 0 ومن الزبون الى المخد م في ال 4 stream سنركز على اإلشعارات الخاصة بال stream4 لدينا 51 اشعار مكرر بما أن الشبكة غير مشغولة فال نستطيع أن نعتبر أن اإلشعارات المكررة تحدث بسبب االزدحام ولكن طالما أن عدد اإلشعارات المكررة كبير وأن االتصال يتم من خالل شبكة ال سلكية أو عبر االنترنيت فإن السبب هو التأخير أو التأخير غير المنتظم وال نستطيع أن نفعل الكثير حيال ذلك. اإلشعارات المكررة تقلل اإلنتاجية وهذا التقليل يعتمد على نسخه بروتوكول tcp المستخدمة يمكن أن تقل اإلنتاجية الى نصف ما كانت عليه سابقا أو الى الحد األدنى 40

41 الشكل 4-26 مخطط I/O تناقص االنتاجية نالحظ في المخطط السابق كيف تنخفض اإلنتاجية عما كانت عليه عند ورود إشعار مكرر أو إعادة اإلرسال مثال ما بين الزمنين 255 و 260 تنخفض اإلنتاجية من حوالي 80 بايت/ثانيه الى 40 بايت /ثانية أي انها تنخفض إلى النصف تقريبا. Chats ترسل هذه الطرود عادة عند التعافي من حالة حجم النافذة استقبال المزيد من البيانات ) الصفرية)المستقبل لم يعد قادر على ولكن خالل عملية االتصال التي قمنا بالتقاطها قادر على استقبال كميات من البيانات دون أية مشاكل وهذا يظهر في المخطط التالي حيث كلما أصبحت المسافة بين المنحنين البيانين اكبر كلما كان حجم ال buffer أكبر وقادر على استيعاب المزيد من البيانات. الشكل 4-27 : مخطط Time sequence 41

42 إذا السبب وراء هذا التغيير هو مشاكل في أداء األجهزة النهائية مشاكل في الذاكرة أو في التطبيق...نالحظ من خالل االلتقاط الذي قمنا به ان هذه التغييرات تحدث عند حدوث إعادة إرسال او اشعارات مكررة للتغيير. مما يسبب بطئ االستقبال في الجهاز المستقبل وهو سبب محتمل إذن : لقد اصبحنا نعرف ما يحدث أثناء االتصال وماهي األمور التي تؤثر على أداء الخدمة وعند حديثنا عن خدمة راديو فان أكثر ما يهمنا هو التأخير delay وأيضا الjitter نستطيع تحديد delay/jitter من خالل مخطط i/o الشكل: 4-28 التأخير مخطط I/O نالحظ من المخطط السابق أن التأخير ال يتجاوز 30 ميلي ثانية بل غالبية الطرود التي تعاني من تأخير ال يتجاوز 15 ميلي ثانية ولكن نالحظ انه عند اللحظة 530 تقريبا يصل التأخير الى حوالي 70 ميلي ثانية وهذا بسبب المشاكل التي تحدثنا عنها أما Jitter فهو التباين في توقيت وصول حزم البيانات الناجم عن الضغط على الشبكة و الذي يسببه االزدحام مما يسبب التقطع في الصوت. التأخير ) (Delay : اآلن سوف نرى.delays between TCP packets and ACKs 42

43 .delays between TCP packets and ACKs الشكل : 4-29 لكي نوضح ما هي العالفة ما بين إعادة اإلرسال والتأخير سوف نلجأ الى المخطط التالي : 4-30 العالقة بين اعاده االرسال والتأخير الشكل : نالحظ أنه عند إعادة اإلرسال بشكل كبير)النقط باللون األخضر( فإن التأخير يزداد بشكل ملحوظ وبالتالي نستطيع القول أن إعادة اإلرسال عبر الشبكة هي السبب الرئيسي للتأخير أما بالنسبة لسبب إلعادة االرسال في مثالنا هذا وكما ذكرنا فيما سبق هو من األجهزة النهائية التي 43

44 تتحرك بعيدا عن نقطه الوصول مما يضعف االتصال ما بن الجهاز الزبون والمخد م. نستنتج مما سبق : األمور التي تؤثر على جودة الخدمة غير محصورة وتتعلق بطبيعة الشبكة تخزين البيانات في نقطة الوصول قبل ارسالها يؤدي الى ارتفاع اإلنتاجية في بداية عمليه االستقبال. من أهم المشاكل التي يمكن أن تتعرض لها عملية البث هي إعادة االرسال وفي مثالنا هذه اإلعادة ناتجة عن كون المستقبل بطئ وهذا ما يسبب التأخير. تقل االنتاجية الى النصف عند وجود إشعارات مكررة أو إعادة إرسال سريعة. كون البروتوكول المستقبل هو TCP فمن الطبيعي أن تؤثر االجهزة المستقبلة من حيث سرعتها وحجم الذاكرة الحرة وقدرات المعالج على جوده الخدمة السيناريو الثاني : من إعدادات المخدم تم تحديد عدد األجهزة المسموح لها بالوصول الى الخدمة ب 3 أجهزة bit rate =48bit/sec ونوع المحتوى audio/aacp يتصل على الخدم 3 أجهزة ومعدل االرسال من قبل المخد م ثم يعود يخرج عن الخدمة فترة زمنية قصيرة SAMSUNG G2 SAMSUNG S2 SAMSUNG cor2 الجهاز ذو العنوان لالتصال. : Round Trip Time الشكل : 4-31 Round Trip Time 44

45 المخطط السابق يظهر لنا الزمن الذي يحتاجه وصول الطرد من المخد م الى الجهاز ذو العنوان وعودة االشعار نالحظ أن التأخير معدوم إال في بعض الحاالت والتي نذكرها هنا الشكل : 4-32 رسائل الجهاز ذو العنوان نالحظ أن أطول فترة زمنية تستغرقها عودة االشعار عندما تفعيل البت FIN وهذا يدل على أنه تم تحرير الوصلة من قبل الجهاز ذلك بعد أن قام بإرسال عدة طرود ولم يتمكن من الوصول إلى الهدف Unreachable بعد ذلك يستمر الزبون باستقبال بيانات لفترة زمنيه غير محددة بعدها يتم فيه تفعيل البت RSTمما يدل على وجود إرباك في الوصلة )بسبب تحرير الوصلة(ومحاولة إعداد وصلة جديدة في الحاالت األخرى سبب التأخير هو طلب أجهزة أخرى للخدمة في ذات الوقت وحصول تأخير بسبب االزدحام أقصى تأخير هنا هو في االشعار الذي يفعل البت FIN الشكل : 4-33 زمن وصول االشعار عند عوده الجهاز للخدمة نالحظ أن زمن عودة اإلشعار من الزبون للمخد م يزداد ولكن الطرود سليمة وال تدل على وجود أية مشاكل في ال Streamكإعادة ارسال أو تلف وصلة أو ما شابة نستنج من ذلك أن استخدام الحزمة المتاحة من قبل األجهزة الثالثة المتصلة هو سبب التأخير. 45

46 الشكل Round Trip Time 4-34 : بالنسبة للجهاز ذو العنوان يظهر لدينا المخطط التالي : الشكل 4-35: مخطط Round Trip Time ورسائل الجهاز ذو العنوان

47 من األشكال السابقة نالحظ أن سبب تأخر عودة االشعار هنا هو نفسه السبب الذي ناقشناه سابقا وأن أكبر زمن يستغرقه عوده االشعار هو ثانية وذلك في الطرد والذي هو اشعار للطرد الشكل : 4-36 زمن وصول االشعار في الجهاز ذو العنوان لدينا نفس الحاالت السابقة وأقصى تأخير هو ثانية نستنتج مما سبق : عودة اإلشعار من المستقبل إلى المرسل يتأثر بوضع الشبكة من حيث االزدحام وعدد األجهزة التي تطلب الخدمة ولكن هذا التأخير بسيط جدا. يحدث التأخير الكبير عندما يقوم المستقبل بإلغاء تفعيل االتصال )الوصلة( وإعداد وصلة جديدة وفي حاالت مشاكل الشبكة التي تسبب إعادة االرسال. اإلنتاجية ) (Throughput : باستخدام مخطط I/O نستطيع أن نالحظ نفسها Byte/sec كنظره اوليه ان األجهزة الثالثة لها تقريبا اإلنتاجية الشكل : 4-37 اإلنتاجية لألجهزة الثالث 47

48 باستخدام مخططات اإلنتاجية لعمليات اإلرسال واالستقبال بين المخدم وكل جهاز نجد ما يلي : : Stream8-1 الشكل : 4-38 مخطط اإلنتاجية للStream8 عند بدء عملية إرسال البيانات تكون اإلنتاجية مرتفعة متركزة حول 30000Bayte/sec ومن ثم تستقر عند Byte/sec وتستمر على نفس السوية حتى حدوث مشاكل بالشبكة فتنعدم أو تصل الى أقل من 5000 قبل Byte/sec أن تنعدم كليا عند انقطاع االتصال. : Stream مخطط اإلنتاجية لل 10 stream الشكل : 48

49 يمكننا أن نرى بشكل واضح أن المخطط يشبه لحد كبير جدا المخطط السابق وأن اإلنتاجية لهذا الجهاز ذاتها للجهاز السابق. : Stream 16-3 الشكل 4-40 مخطط اإلنتاجية لل 16 stream تكون اإلنتاجية هنا أقل حيث تتراوح ما بين 7000 الى Byte/sec10000 في الحالة العامة Stream 18-4 الشكل : 4-41 مخطط اإلنتاجية لل 18 stream 49

50 عند عودة الجهاز ذو العنوان الى الخدمة تكون إنتاجيته مرتفعة ثم تستقر عند حوالي Byte/sec كما كان قبل أن يتوقف هنا نالحظ أن الجهاز يبقى وحده في الخدمة ومع ذلك ال ترتفع انتاجيته عن علما أنه في السيناريو السابق وصلت اإلنتاجية الي اكثر من byte/sec نستنج من ذلك أن معدل البت وتقنية التشفير المستخدمة تؤثر في اإلنتاجية حيث أنها كان لدينا في السيناريو السابق bit rate 128= bit/sec و التقنية هي Mp3 نستنتج : اإلنتاجية لجميع األجهزة الطالبة للخدمة في الحالة المستقرة تكون متقاربه لحد كبير معدل االرسال وتقنية الضغط تؤثر على اإلنتاجية حيث أنه من األفضل استخدم تقنية mp3 ومعدل ارسال 128 bit/sec تحليل مشاكل الخدمة : كما في السيناريو السابق نستطيع أن نتعرف على مشاكل الشبكة باستخدام النافذة Expert Infos الشكل : 4-42 نافذه Expert Infos كما نرى ال يوجد أخطاء او تحذيرات. : Notes nots الشكل :

51 إعادة االرسال واالشعارات المكررة. كما أصبحنا نعلم أن إعادة االرسال ناتجة عن بطئ المستقبل أو عن مشاكل في المخد م يمكننا ان نستثني هنا بطئ المستقبل ألن األجهزة المستقبلة ذات مواصفات عالية باإلضافة الى انها غير متحركة كما في السيناريو السابق. الشكل : 4-44 رسائل ال nots لدينا أربع طرود عباره عن اشعارات مكررة منها ما هو ناتج عن إعادة االرسال باإلضافة الى 12 طرود معاد ارساله ناتج عن مشاكل في المخد م حيث تم إعادة ارسال 3 طرود من stream 8 و 3 من ال stream 10 و 2 من ال stream16 وهذه الطرود تحوي بيانات فعلية ولكن هذا العدد من االشعارات المكررة والطرود المعاد إرسالها يعتبر قليل جدا حيث أننا نعمل في وسط شبكه السلكية ونستطيع أن نقول عن الخدمة أنها جيده جدا في هذه الحالة. سوف تنخفض اإلنتاجية بسبب إعادة االرسال واالشعارات المكررة ولكن هذا االنخفاض طفيف. الشكل : 4-45 مخطط I/Oتحليل اإلنتاجية 51

52 : Chats الشكل : 4-46 Chats باستثناء المحادثات التي تتم من اجل بدء ارسال البيانات وانهاء محادثات انهاء كل stream لدينا محادثات اعداد وصله جديده بين المخد م والزبون بعد حدوث اراك في الوصلة القديمة نالحظ هنا وجود طرود لم تصل الى هدفها وذلك الن الزبون انهى االتصال من طرفه ولكنه مازال قادر على استقبال بيانات ولكن ال يمكن وصول االشعارات منه الى المخد م هذا يؤثر على التأخير حيث كما وجدنا سابقا يزداد الزمن الالزم إلشعار المرسل بوصول البيانات التي قام بإرسالها الشكل : 4-47 الرسائل الخاصه بالchats 52

53 : Delay كما هو موضح في I/O لنرى مقدار التأخير الحاصل لدى كل جهاز نستخدم مخطط I/O الشكل : 4-48 تحليل التأخير نالحظ أن التأخير لدى جميع األجهزة يكاد يكون نفسه حيث يتراوح ما بين 10 الى 20 ميلي ثانية بشكل أساسي ويزداد هذا التأخير عند خروج الجهاز عن الخدمة destination unreachable سبب التأخير هو إعادة تأسيس الوصالت أو إعادة إرسال الطرود. طبيعة الشبكات الالسلكية تعطي مجال واسع لحدوث أخطاء في هذا المثال لم تعاني الشبكة من الكثير من هذه المشاكل ولكن في طبيعة الحال ال نستطيع إحصاء األخطاء والمشاكل الناتجة عن هذا النوع من الشبكات والتي تعتبر غير موثوقة بالمقارنة مع الشبكات السلكية. 53

54 الفصل الخامس : Power saving Mode 5-1 مقدمة : يعد استهالك الطاقة ضمن أجهزة الهواتف من المشاكل الهامة التي يجب معالجتها وكحد أدنى التخفيف منها. و بسبب االنتشار الكبير للهواتف الذكية واستخدامها بشكل كبير في مجاالت الحياة كافة كان البد من إيجاد وسائل تساهم في تمكين استخدام الهواتف الذكية بمرونة أكثر وتقديم حلول للمشاكل التي تقف عائقا أمام ذلك و ال سيما مشكلة االنخفاض الكبير و السريع في طاقة البطارية عند استخدام الهاتف الذكي الستعراض مكونات الوسائط المتعددة وهذا يجعل بطارية الهاتف الذكي غير قادرة على تلبية احتياجات المستخدم. إن السبب في االستهالك الكبير هو التعارض بين دعم Streaming الذكية و حاالت الطاقة المعرفة ضمن الشبكات الالسلكية. و حاالت أنظمة الهواتف هناك عامل آخر مهم يساهم في زيادة استهالك الطاقة نتيجة االزدياد الكبير في التأخير و انخفاض اإلنتاجية فالشبكات الالسلكية عرضة لضياع البيانات وذلك بسبب طبيعتها و هنا يكون التأخير الكلي لعملية النقل كبيرا ما يقابله إنتاجية منخفضة جدا. إن السلوك السابق لوضع الشبكة الالسلكية سوف يزيد من استهالك الطاقة باإلضافة إلى أن كلفة الطاقة ألي بروتوكول نقل ليست عدد الطرود المرسلة أو المستقبلة و إن ما الزمن الكلي الستكمال عملية النقل. نقوم ببث أغنية عبر Shoutcast Server و استقبالها من خالل مشغل الموسيقا VLC الموجد على الجهاز Galaxy Grand 2 ومراقبة هذا البث عن طريق Wireshark و Terpn Profiler الموجود على الجهاز المستقبل. 54

55 الشكل :1-5 التأخير باستخدام مخطط I/O من المخطط السابق نالحظ مع بداية البث عند اللحظة 8second يكون هناك تأخير كبير يصل إلى حوالي 300 ms في حين أن باقي اللحظات الزمنية ال تعاني من تأخير كبير حيث ال تتجاوز قيمة التأخير. 5ms ضمن Terpn Profiler نقيس Battery Power نالحظ االستهالك الكبير في الطاقة حتى الثانية 11 يصل إلى 2302 mw و هو نتيجة التأخير الحاصل و المبي ن ضمن مخطط 1350 mw ومن ثم هناك نوعا ما ثبات في االستهالك ال يتجاوز Wireshark (I/O graph ). الشكل: 5-2 استهالك الطاقة تعد بطاقة الشبكة الالسلكية من أكثر العتاديات استهالكا للطاقة و خالل عملها تمر ضمن أربع حاالت وكل حالة من حاالت NIC تتطلب مقدار مختلف من الطاقة أم ا هذه الحاالت فهي : 55

56 . Active Waiting Sleep-Off تعتبر Active state من أكثر الحاالت استهالكا للطاقة ضمن الحاالت السابقة وذلك يرجع لطبيعة العمل الذي يتم إنجازه ضمن هذه الحالة من إرسال و استقبال للبيانات وهذا يتطلب مقدار كبير من الطاقة. أم ا Waiting state فال يحدث إرسال أو استقبال ألي نوع من البيانات وإنما هناك مراقبة عامة للوسط و يبقى المستقبل في حالة جاهزية ) on (turned. عندما يصبح المستقبل في حالة turned off فإن NIC تنتقل إلى. sleep state الحالة الرابعة Off state فليس هناك أي استهالك للطاقة من قبل NIC لذلك فإن الحاالت التي تؤثر على استهالك الطاقة من قبل NIC هي : sleep active waiting و االنتقال من حالة إلى حالة أخرى يتطلب طاقة إضافية. االنتقال من حالة تستهلك طاقة منخفضة إلى حالة تستهلك طاقة عالية يتطلب طاقة مرتفعة من أجل االنتقال. هناك حالة ال يكون فيها إي انتقال للبيانات هي Idle state. waiting و sleep و تعرف بأنها حالة دورية بين : و كملخص عن حاالت NIC إرسال و استقبال للبيانات ليس هناك أي عملية إرسال أو استقبال للبيانات وضع المستقبل في حالة turned off ال يكون هناك أي استهالك للطاقة من قبل NIC ACTIVE WAITING SLEEP OFF : 5-2 المعيار IEEE من خالل هذا المعيار تم تعريف power saving mode ليعمل بشكل متكامل مع نقاط الوصول Access points و مستخدمي الهواتف. mobile users يقوم المستخدم بإرسال طلبه إلى نقطة الوصول وذلك للتبديل إلى PSM وطالما أن الجهاز في هذا الوضع يتم تغيير NIC إلى sleep state و بشكل دوري يكون هناك حاالت تسمى wake up يتم من خاللها استقبال إطارات (TIM) Traffic Indication Map و تسمى أيضا beacons من نقطة الوصول استجابة لهذه اإلطارات يقوم الجهاز )الموبايل ) بإرسال إطارات (PS-POLL) إلى نقطة الوصول فقط إذا كان إطار TIM السابق يحوي على إشارة تدل على أن نقطة الوصول قد قامت بتخزين مؤقت للبيانات قبل إيصالها للمستخدم. 56

57 إذا ACCESS POINT تقوم بإرسال البيانات المخزنة مؤقتا إلى الجهاز فقط في حال استقبالها إلطار (PS-POLL) من جاز المستخدم. في حاالت طرود البيانات & Multicast delivery traffic indication message تقوم بإرسال Access point فإن Broadcast متبوعة مباشرة بطرود البيانات الفعلية. في هذه الحالة ليس هناك إطار (PS-POLL) مطلوب إرساله..IEEE Power Management الشكل :5-3 أداء المعيار : PSM إن هذا المعيار يمكن Access point من تحقيق وظيفتين : 5-3 تحديد فيما إذا كانت سترسل اإلطارات إلى الشبكة الالسلكية أو أن تخزنها مؤقتا وذلك ألن جهاز المستخدم في حالة. sleep اإلعالن بشكل دوري عن مستخدمي الهاتف و الذين ينتظرون إطارات مخز نة مؤقتا. جهاز المستخدم يستطيع أن يبقى ضمن sleep state ألقصى مدة ممكنة من الوقت وذلك لتجنب استخدام NIC بتكرار كبير ولكن هذا األمر يتطلب وجود مخزن مؤقت بسعة كبيرة لدى. Access point من الواضح أن هذا المعيار يسمح لمحطات الموبايل بالقيام بحفظ الطاقة من خالل السماح لها بالتبديل بشكل متكرر إلى sleep state حيث االستهالك المنخفض للطاقة أو من خالل إطالة فترة sleep state غير أن حفظ الطاقة المتوق ع الحصول عليه يعتمد على زمن انتظار أصغري ) interval (minimal waiting time وكمثال لدينا الزمن الفاصل بين نقل طرود (PS-POLL) واستقبال طرود البيانات ويبقى أن المعيار ال يضع أي حدود لطول. waiting state است ارتيجيات تقليل استهالك الطاقة : جنبا إلى جنب مع غيرها من خدمات الهاتف األخرى هناك أنواع مختلفة من Multimedia streaming أصبحت شائعة وبسبب أهميتها و انتشارها الكبير هناك الكثير من األعمال التي تهدف إلى تقليل استهالك الطاقة ويمكن تصنيف هذه األعمال اعتمادا على نوع التطبيق إن كان Multimedia application أو. Simple web Access : Web Access )1 57

58 كما ذكرنا سابقا فإن زيادة التأخير و انخفاض اإلنتاجية يساهم بشكل كبير في زيادة استهالك الطاقة. الحل األولي الذي كان من أجل تخفيض استهالك الطاقة من قبل NIC هو تحسين اإلنتاجية ضمن طبقة النقل. من أجل تحقيق ذلك تم استخدام (I-TCP) Indirect TCP كبديل عن هيكلية TCP المعتمدة. تقوم I-TCP بتجزئة اتصال TCP واحد إلى اتصالين TCP األول يكون بين جهاز المستخدم و نقطة الوصول والثاني بين نقطة الوصول و المضيف على شبكة اإلنترنت حيث تقوم نقطة الوصول بنقل البيانات بين المضيف و جهاز المستخدم. تجنبنا I-TCP االنخفاض في االنتاجية الناتج عن الجمع بين تأثير ضياع الطرود في الشبكات الالسلكية وآلية التحكم باالزدحام و هذا الحل يخفض بشكل كبير التأخير الكلي و يخفض استهالك NIC من الطاقة. كما تم تعريف بنية شبكة جديدة Power Saving Network Architecture (PSNA) بحيث يكون االتصال بين نقطة الوصول و جهاز المستخدم يعتمد على بروتوكول نقل لحفظ الطاقة (PS-TP) في حين أن االتصال بين نقطة الوصول و المضيف هو. TCP PS-TP من النمط connection-less كما أن ه موثوق الهدف األساسي من استخدام connection-less هو تقليل العمل المنجز من قبل جهاز المستخدم و مقدار الطاقة المرافق لعمليتي إعداد و إنهاء االتصال. كنوع آخر من الحلول تعتمد نهجا مختلفا عما تم تقديمه سابقا وقادرة على حفظ الطاقة بحدود 70% من دون انخفاض كبير في جودة الخدمة (QoS). إن الطاقة المحتمل استهالكها عند انتظار NIC للطاقة بعد أن ترسل( PS-POLL ) إلى نقطة الوصول ليست بقليلة خالل هذه الفترة ليس هناك بيانات يتم نقلها أو استقبالها ومع ذلك تستنزف مقدار كبير من الطاقة. تم استخدام (STPM) Self-Tuning Power Management والذي يالحظ أنماط الوصول المختلفة للتطبيقات إلى الشبكة وذلك ليتنب أ بعمل وسلوك التطبيق. اعتمادا على هذا التنبؤ فإن STPM يقرر إن كان سيستخدم power saving mode. continuous active mode (CAM) أو (PSM) : Multimedia Streaming إن الحلول المتبعة ضمن web Access ليست مناسبة لحفظ الطاقة ضمن تطبيقات الوسائط المتعددة و يعود ذلك إلى القيود الزمنية المفروضة من قبل التطبيقات ومتطلبات الجودة العالية وعدا عن ذلك فإن تطبيقات الوسائط المتعددة تعتبر مستهلك كبير للطاقة. )2 58

59 تم تطوير عدة استراتيجيات لتقيل استهالك الطاقة من قبل NIC تعتمد على تقنيات التبديل بين حاالت NIC فمثال التبديل إلى sleep state ضمن فترات Idle حيث يتم التنبؤ بهذه الفترات من خالل أخذ متوسط فترات Idle سابقة. ضمن فترات الخمول المعتدلة ليس هناك حفظ للطاقة بينما في فترات الخمول الطويلة قد يكون هناك ضياع للطرود وبالتالي نحتاج إلى. PSM إن استخدام النموذج السابق يقود إلى حفظ الطاقة بحدود 80% من الطاقة عند معد ل 28.8kbps ومقدار الضياع 2% أما عند المعدالت األعلى يكون تقريبا 57% ومقدار الضياع يصل إلى 3%. ضمن windows media يبدو الخرج الذي نحصل عليه مقبوال وذلك ألن الوسائط المستخدمة تميل إلى إيصال الطرود ضمن فواصل زمنية منتظمة. نتيجة لعدة أبحاث تم الوصول إلى أن المعيار PSM ليس فع اال ضمن Multimedia Streaming فحركة البيانات ضمن الوسائط المتعددة تميل ألن تكون غير منتظمة كما أن خدمات الوسائط المتعددة في الزمن الحقيقي ترسل طرود صغيرة ضمن فواصل زمنية متقاربة وبالتالي فإن NIC دائما ضمن active state وتكون مدة sleep state قصيرة جدا. لذلك تم اقتراح Server-Side Proxy من أجل تطبيق مفهوم Shaping Media Stream وهذا يقود إلى حفظ الطاقة بحدود 80%. كان هناك بعض االقتراحات التي أد ت إلى تحسينات كبيرة من أهمها استخدام سياسة إحصائية حيث وجدوا أن فترات الخمول مترابطة مع فترت الخمول التي تم ت مالحظتها سابقا. لكي نضمن تفعيل (wake up) NIC قبل وصول الطرد التالي يتم إضافة تعديالت بسيطة إلى. sleep state إن الحل المقترح الذي يعتمد على استخدام Proxy له وظيفتين رئيسيتين : تقديم آلية ترميز لدفقات بيانات الوسائط المتعددة يمكن اعتبارها power. friendly آلية نقل ذكية من أجل تقليل استهالك الطاقة من قبل. NIC إن الهدف الرئيسي هو تقليل استهالك الطاقة لدى CPU و NIC حيث يقوم المستخدم بإرسال معلومات تحدد مقدار الطاقة الذي يحتاجه من أجل عملية الترميز و بناء على هذه المعلومات يقوم Proxy بعمليات الترميز. أم ا من أجل تحقيق power friendly transmission فقد تم تقديم تقنيتين : Client-side history based prediction Proxy assisted prediction 59

60 في الحالة األولى يقوم proxy باعتماد traffic shaping من أجل تحويل variable bit rate (VBR) إلى (CBR) constant bit rate وهذا يساعد جهاز المستخدم على التنبؤ بالفواصل الزمنية التي سوف تكون خاملة من أجل التبديل إلى. sleep state أما في الحالة الثانية يقوم proxy بإرسال طرد تحكم إلى جهاز المستخدم يشير من خالله إلى زمن وصول المجموعة القادمة من اإلطارات وبناء على ذلك فإن NIC توضع في sleep state حتى وقت وصول اإلطارات النموذج السابق يقد م حفظ للطاقة بحدود 98%-65%. النموذج األخير الذي سنناقشه يعتمد على بروتوكول لحفظ الطاقة يقلل الطاقة المستهلكة ضمن WI-FI interfaces ويسمى (RT-PS) Real Time Power Saving يعمل ضمن. Proxy ويتطلب هيكلية عمل تعتمد على UDP ON/OFF من إجراء عملية جدولة لنقل الطرود باالعتماد على مخطط proxy يمك ن RT-PS حيث ضمن فترات ON يقوم proxy بنقل الطرود إلى جهاز المستخدم مستخدما أعلى معد ل نقل مسموح استخدامه من قبل الشبكة كما يقوم بتحديد مدة ON اعتمادا على عرض الحزمة المستخدمة يقوم المستخدم بإيقاف NIC ضمن فترات OFF والتي تعتمد مد تها على مستوى المخزن المؤقت (Buffer) لدى المستخدم. عندما يقل مستوى البيانات ضمن المخزن المؤقت عن المستوى الديناميكي المسموح به يقوم المستخدم بتنبيه ال proxy من خطر حدوث أخطاء تتعلق بقلة البيانات وينهي حالة OFF هذا النموذج يقد م حفظ للطاقة بمقدار يتراوح بين 76% و 91% مع المحافظة على جودة الخدمة. : AAC مقارنة بين الصيغتين MP3 و و م ارقبة استهالك الطاقة 5-4 عندما نقوم ببث ( Audio أغنية مثال ) باستخدام Shoutcast هناك خيار يتضمن تحديد الصيغة التي سوف يتم استخدامها تم اختيار كل من mp3 و AAC النتشارهما الكبير ومن خالل هذه المقارنة سوف نقيس بعض البارامترات المتعلقة بالطاقة على الجهاز الذي سوف يستقبل األغنية التي يتم بث ها الجهاز المستخدم Galaxy Grand 2 و التطبيق VCL الذي يدعم بث كل من الصيغتين mp3 وAAC و التطبيق Terpn profiler لمراقبة, load CPU. 128 kbps و 64 kbps وفق معدل بث Battery power, Memory usage تصنف الصيغتين السابقتين ضمن مفهوم Lossy formats وهي األكر انتشارا بين الناس إذ توفر مساحة كبير جدا لنتمكن من إضافة عدة ملفات صوتية أخرى ونتيجة لذلك تفقد بعضا من جودتها. MPEG Audio Layer : Mp3 تعتبر األكثر انتشارا في العالم نظرا للدعم الكامل الذي تقدمه جميع برامج تشغيل الوسائط المتعددة لها كما أنها تقدم ضغط اعتمد على إزالة جميع 60

61 األصوات المكررة بدون ان يكون لها فعالية و كذلك إزالة األصوات ذات الترددات التي ال تقدر األذن البشرية على سماعها أو التعرف عليها. Advanced Audio Coding : AAC وهي صيغة توفر جودة صوت مماثلة ل mp3 ولكن بمساحة أقل. Format : mp3, bit rate : 64 kbps : Battery power تتراوح القيمة بين 1129 mw و 1300 mw مع بداية االستقبال تكون مرتفعة ثم تأخذ مسارا مستقرا يدوم حوالي 100s ويكون متوسط القيمة ضمنه mw حيث استمرت مدة المراقبة. 185 s الشكل : 5-4 استهالك الطاقة هذا االرتفاع في استهالك الطاقة ناتج عن التأخير الكبير الحاصل و الموضح في الصورة التالية في حين أنه في الحالة المستقرة لنقل البيانات يصل التأخير الى أقل من 15 ميلي ثانية تقريبا. 61

62 الشكل 5: 5 التأخير : CPU load يقدم المخطط قيم مئوية يصل أقصاها إلى 90% وأدناها % 10 و خالل 185 s تكون هذه القيم متذبذبة بين عدة قيم وال تسلك سلوك ثابت وكنسبة وسطية 53.15% الشكل :5-6 الحمل على المعالج : Memory usage يعتبر من العوامل المهمة ويحقق عامل االختالف بين mp3 و MB كما سنرى الحقا وكقيمة وسطية تكون AAC. 62

63 الشكل :5-7 استخدام الذاكرة Format : mp3, bit rate : 128 kbps : Battery power في 128kbps كما في 64 kbps نالحظ تكرار نفس السيناريو مع ازدياد في القيمة حيث يصل المتوسط إلى mw % الشكل :5-8 استهالك الطاقة : CPU load خالل 185 s يكون متوسط القيمة المئوية الشكل :5-9 الحمل على المعالج : يكون هناك فترات زمنية تكون فيها القيمة ثابتة و كقيمة Memory usage متوسطة MB 63

64 الشكل :5-10 استخدام الذاكرة Format :AAC, bit rate : 64 kbps Battery power :القيمة المتوسط تصل إلى mw والسبب في ذلك الخوارزميات المستخدمة من أجل تحقيق ضغط أكبر عما كان عليه في mp3 وتقليل مساحة التخزين. الشكل : 5-11 استهالك الطاقة نستطيع باستخدام Wireshark أن نالحظ التأخير الذي سبب االزدياد في استهالك الطاقة عن الحالة المستقرة والتي ال يتجاوز فيها التأخير. 20 ms 64

65 الشكل :5-12 التأخير : CPU load ليس هناك قيم ثابتة ضمن فواصل زمنية معينة وتكون النسبة المئوية المتوسطة % mp3 الشكل: 5-13 الحمل على المعالج : Memory usage نالحظ استخدامية الذاكر منخفضة عما كانت عليه ضمن وكقيمة متوسطة الشكل : 5-14 استخدام الذاكرة ونوعا ما قريبة من Format :AAC, bit rate : 128 kbps Battery power :القيمة المتوسطة تصل إلى (AAC,64kbbps) عند Battery power 65

66 الشكل :5-15 استهالك البطارية : CPU load كما في السيناريوهات السابقة ليس هناك سلوك ثابت ضمن استمرار زمني معين والقيمة المتوسطة للنسبة المئوية mw الشكل :5-16 الحمل على المعالج : Memory usage القيمة المتوسطة MB وتقريبا خالل 185 s تكون القيمة ثابتة بحدود mw الشكل :5-17 استخدما الذاكرة 66