Napster و Gnutella

با توجه به اينكه Napster يك برنامه متن باز ^[1]نيست، تنها مي‌توانديك برنامه مشابه را براي آشكار كردن اين پروتكل به روش مهندسي معكوس ساخت. به زبان ديگر، هيچ‌كس تا به حال بجز سازندگان خود اين پروتكل كاملاً مطمئن نيست كه مشخصه‌هاي پروتكل چيست؟

Napster با يك سرور مركزي كه انديس فايلهاي MP3 نظيرها را در خود نگهداري مي‌كند كار مي‌كند. براي به دست آوردن فايل، بايد يك پيغام درخواست براي سرور فرستاده شود و او شماره پورت و IP آدرس آن مشتري كه فايل را به اشتراك گذاشته است براي درخواست كننده مي‌فرستد. با برنامه Napster اكنون مي‌توانديك ارتباط مستقيم را با ميزبان ايجاد و فايل را دانلود كرد.

پروتكل Napster از تمام انواع پيام‌ها استفاده مي‌كند. تمام ميزبان‌ها با سرور مركزي ارتباط دارند. (در واقع نظيرها مانند يك مشتري در برابر سرور مركزي عمل مي‌كنند). بنابراين اين پروتكل گمنامي را ممكن نمي‌سازد. در ابتدا شايد به نظر آيد كه مشكلي به وجود خواهد آمد اما اين پروتكل پيچيده امكان بسياري از سرويسها را فراهم مي‌سازد. بعضي از اين سرويسها عبارتند از:

1)ايجاد ليست ويژه:^[2]مطلع ساختن كاربر هنگامي كه كاربران ليست ويژه او به سرور مي‌پيوندند يا از آن خارج مي‌شوند.

2) ليست كاربران حذف شده

3) پيامهاي فوري: ارسال پيامهاي فوري خصوصي يا عمومي به كاربران ديگر و پيوستن به كانالهاي علايق اشتراكي.

ساختار پيام داده Napster

ساختار هر پيام كه از سرور مركزي فرستاده و دريافت مي‌شود به صورت زير است:

شكل 1

كه در آن

• Length طول c مي‌آيند ^[3]را مشخص مي‌كند.
• Function حاوي نوع پيام بسته است.
• Payload يك رشته اسكي مشخص و واضح است.

هر بلوك سرآيند^[4]و پي‌آيند با جاي خالي ^[5]جدا مي شوند كه همگامي پيامهاي دريافتي را فراهم مي‌آورد. بسياري از بلوكها طول ثابتي ندارند بنابراين جاهاي خالي جداسازي داده را در جريان بيتهاي دريافتي را ممكن مي‌سازد.

مقاله درباره Napster و Gnutella

قالب‌بندي

يك ميزبان Napster مشخص كه همانند يك مشتري عمل مي‌كند، يك پيام login به شكل ساختار زير براي سرور ارسال مي‌كند:

شكل 2

كه در آن

• Nick نام و رمز كاربر را مشخص مي‌سازد.
• Port پورتي را كه مشتري آن را براي انتقال داده شنود مي‌كند را تعيين مي‌كند.
• Client- info رشته‌اي شامل اطلاعات مشتري است. link-type يك عدد صحيح (integer) است كه پهناي باند مشتري را معين مي‌كند. جدول يك

اينكه اعداد در فيلد link- type چه چيزي را مشخص مي‌كنند در جدول 1 آمده است. نيازي نيست كه IP آدرس مشتري به پيام افزوده شود. به هر حال سرور مي‌تواند به طور اتوماتيك آن را از طريق بسته TCP ارسالي استخراج ‌كند.

ميزبان تعيين نشده، يك login كاربر جديد را كه ساختار آن مشابه ساختار است به همراه يك آدرس پست الكترونيكي در انتهاي پيام ارسال مي‌كند. سرور يك تصديق login ^[6] را پس از انجام موفقيت‌آميز اتصال براي مشتري مربوطه مي‌فرستد. اگر Nick تعيين شده بود، آدرس پست الكترونيكي در پيام بازگشتي قرار خواهد گرفت در غير اين صورت مقداري مجازي و ساختگي برگشت داده مي‌شود.

ابلاغ فايل اشتراكي ميزبان

با پيام ابلاغ فايل اشتراكي، مشتري متوالياً تمام فايلهايي را كه مي‌خواهد به اشتراك بگذارد اعلام مي‌كند. ساختار اين پيام به صورت زير است:

شكل 3

كه در آن

• filename نام فايلي است كه به اشتراك گذاشته شده است.
• MD5 ^[7]مقدار hash شده فايل اشتراكي است. در واقع الگوريتم MD5 يك اثر انگشت 128 بيتي را براي هر فايل توليد مي‌كند. تقريباً هيچ دو عدد مشابهي براي دو پيام توليد نمي‌شود. الگوريتم MD5 براي فراهم كردن امنيت فايلهاي اشتراكي هر كاربر مورد استفاده قرار مي‌گيرد.
• Size اندازه فايل بر حسب بايت است.
• Bitrate نرخ ارسال MP3 بر حسب kbps است.
• فركانسfrequency)) يك نرخ مشابه براي MP3 بر حسب هر تز است.
• Time مدت زمان فايل بر حسب ثانيه است.

درخواست فايل:

مشتريان متقاضي ابتدا توسط يك جستجو تعيين مي‌شوند. ساختار اولين پيام جستجو به صورت زير است.

شكل 4

• Artistname نام خواننده فايل MP3 است.
• Title نام فايلل MP3 است.
• Bitrate طيف نرخ بيت مورد استفاده را نمايش مي‌دهد.
• Maxresults حداكثر تعداد نتايج است.
• Link- type طيف انواع لينكها را نشان مي‌دهد.
• Frequency هم فركانس بر حسب هرتز است.

پي‌آيند پيام تنها شامل نام (Nick) ميزبان است.

پاسخ و پاسخ‌جستجو:

سرور به يك جستجو با پيامي با ساختار زير پاسخ مي‌دهد.

شكل 5

• filename نام فايلي است كه در رابطه با جستجو يافت شده است.
• MD5 مقدار hash فايل درخواستي است.
• Nick نام كاربري است كه فايل را به اشتراك گذاشته است.
• Link- type به پيام login اشاره دارد.
• IP يك عدد صحيح چهار بايتي است كه IP آدرس كاربري كه فايل را به اشتراك گذاشته است را نمايش مي‌دهد.

درخواست دانلود

براي انجام دانلود پيامي با ساختار زير براي سرور ارسال مي‌شود:

شكل 6

• Nick نام كاربري است كه فايل را به اشتراك گذاشته است.
• Filename نام فايلي است كه براي دانلود درخواست شده است.

پاسخ درخواست

سرور در پاسخ خود براي يك درخواست اطلاعات بيشتري را در مورد فايل به صورت زير ارسال مي‌كند. شكل 7

درخواست دانلود متناوب

اين پيام مشابه پيام درخواست دانلود است اما هنگامي مورد استفاده قرار مي‌گيرد كه فردي كه فايل را به اشتراك گذاشته است تنها مي‌تواند ارتباط TCP بيرون رونده را ايجاد كند. (ديوار آتش اين نظير پيامهاي ورودي را بلوكه مي‌كند). پيام درخواست دانلود متناوب براي درخواست فايلهاي كاربراني كه پورت مخصوصي به عنوان پورت صفر در پيام login خود دارند مورد استفاده قرار مي‌گيرد.

تصديق دانلود متناوب

اين پيام براي بارگذار ^[8]هنگامي كه پورت داده او با عدد صفر مشخص شده است اين مطلب را اعلام مي‌كند كه در پشت ديوار آتش قرار دارد و بايد تمام داده‌هاي خود را ارسال كند. بارگذار مسئول ايجاد ارتباط با دانلود كننده براي انتقال فايل است.

انتقال فايل

از اين نقطه به بعد، ميزبانها پيامي را براي سرور ارسال نمي‌دارند. ميزبان درخواست كننده فايل، يك ارتباط TCP براي پورت داده مشخص شده در پيام 0xcc از سرور را ايجاد مي‌كند. براي دريافت فايل يك رشته GET و يك پيام به صورت زير جداگانه به شكل ساختار HTTP ارسال مي‌شود:

شكل 8

Offset عددي است بر حسب بايت كه مكاني در فايل را كه انتقال از آن نقطه بايد آغاز شود را نشان مي‌دهد. اين فيلد قبل از انجام انتقال بايد مشخص شود.

سپس در مقابل ميزبان اندازه فايل را برمي‌گرداند و فوراً پس از آن رشته داده‌ها را ارسال مي‌كند. انتقال مستقيم فايل بين ميزبانهاي Napster از معماري نظير به نظير استفاده مي‌كنند. وقتي يكبار فايل انتقال يافت، دانلود كننده سرور را با ارسال پيام دانلود فايل از كار خود آگاه مي‌سازد. زماني كه انتقال كامل شد پيام كامل شدن فايل ارسال مي‌شود.

دانلود با ديوار آتش

Napster روشي را نيز براي كاربراني در پشت ديوار آتش قرار دارند فراهم مي‌آورد تا بتوانند فايلهاي خود را در اختيار ديگران قرار دهند. همانطور كه توضيح داده شد، وقتي يك فايل از يك مشتري در پشت ديوار آتش به بيرون فرستاده مي‌شود، دانلود كننده يك پيام درخواست دانلود متناوب را ارسال مي كند. اين مسئله سبب مي‌شود كه تصديق دانلود متناوب به بارگذار فرستاده شود. اين پيام مشابه پيام درخواست دانلود عادي است.

وقتي بارگذار پيام را از سرور دريافت كرد يك ارتباط TCP را با پورت داده دانلود كننده (كه در پيام ذكر شده است ) ايجاد مي‌كند. در ادامه ارتباط دانلود كننده يك بايت را كه كاراكتر اسكي “1” است ارسال مي‌كند. سپس بارگذار مي‌تواند رشته “send ” را در يك بسته جداگانه بفرستد و بعد از آن پيام اصلي را ارسال كند.

در هنگام دريافت مشتري دانلود كننده بايت آفست يا يك پيام خطا با عنوان invalid request را مي‌فرستد. بايت آفست به عنوان بسته‌اي جداگانه به صورت اعداد اسكي ارسال خواهد شد. يك بايت آفست صفر نشان دهنده انتقال از ابتداي فايل است.

پياده‌سازي

پروتكل Napster بسيار مخفي است در واقع هيچ كس به طور كلي نمي‌داند كه فايلها چگونه جستجو و انتقال چگونه انجام مي‌شود. Napsterبه طور مشخص روي فايلهاي صوتي MP3 متمركز شده است اگر چه كه انواع ديگر فايل نيز پشتيباني مي‌شدند انگيزه بزرگتري در توسعه كنترل كاربر وجود دارد. براي مثال يك نوع از پياده‌سازي MP3 توسط ابزارهايي مانند Wrapster انجام مي‌گرفت كه مي‌توانست يك فايل اختياري با نوعي از پوشش ضميمه كند تا آن را شبيه فايل MP3 كند و سپس در پايگاه داده‌هاي سرور ظاهر مي‌شدند و توسط ساير مشتريان كه مي‌خواهند آن را دانلود كنند قابل جستجو مي‌شود.

اشكال اين روش اين بود كه فيلد توضيحي “نام- خواننده “اطلاعات كمي را درباره فايلهاي غير صوتي ارائه مي‌دهد و در نتيجه خطري را براي توزيع تصادفي نرمال را ايجاد مي‌كرد بنابراين محدوده جستجوي Napster را براي يافتن يك فايل خاص بسيار نامشابه مي‌كند. توسعه ابزارهايي مانند Napigator به كاربران اجازه داد كه بارگذار از داوري متاسرور به سرورهاي خاص متصل شوند. در اين مسير، سرورهاي معين به عنوان ميعادگاه اصلي اطلاعات غير صوتي Wrapster شناخته مي‌شدند.

انتقالهاي غيرصوتي در Napster هيچ گاه مسئله حاشيه‌اي نبوده است حداقل در مقايسه باسيستم‌هاي مانند Gnutella .بعضي از سرورهاي Napster مانند Open Nap كه به عنوان جايگاه امن براي كاربران خود شروع به كار كردند هنگامي كه اين نرم‌افزار شروع به فيلتر اطلاعات كرد براي پر كردن جاي خالي كارهاي قبلي Napster به كار گرفته شد.

اتصال مشتريان به شكل Napster، كپي‌ها و دگرگوني‌هاي جديدي را در پروتكل اصلي اين نرم‌افزاربراي انواع فايلها ايجاد كرده است. به هر حال نيازهاي اصلي يك سرور مركزي سازگار با Napster فشار جدي را بر روي شبكه‌اي بر پايه اين تكنولوژي يا هر نوع نسخه ديگر آن باقي مي‌گذارد. براي رهايي از اين محدوديت، پروتكلهاي و مدلهاي ساختاري ديگر مانند شبكه‌هاي بدون سرور به روش Gnutella نياز هستند.

Gnutella

در اوايل مارس 2000، Gnutella توسط جاستين فرانكل ^[9]و تام پپر ^[10]كه هر دو در Gnutella soft مشغول به كار بودند ايجاد گرديد. (اين شركت يكي از زير شاخه‌هاي AOL است). توسعه اين نرم‌افزار كمي بعد از ايجاد آن توسط AOL متوقف شد اما در مدت كوتاهي كه Gnutella مورد استفاده قرار مي‌گرفت برنامه‌نويسان زيادي مهندسي معكوسي رابر روي آن آغاز كردند. بر اين اساس تعدادي از نسخه‌هاي Gnutella با اصلاحات جديد به وجود آمد (مانند (Shareaza , Xolox , Gnucleus, Bearshear , Limewire )

ساختار Gnutella

در اين نرم‌افزار بجاي استفاده از يك دايركتوري انديس مركزي مانند Napster، يك شبكه از نظيرها كه خدمتكاران ناميده مي‌شوند براي نگهداري از دايركتوري انديس تمام اطلاعات سيستم به كار مي‌روند.

در يك شبكه Gnutella خدمتكاران ^[11]در يك زمينه توپولوژي adhoc به يكديگر متصل هستند. يك خدمتكار هم به صورت مشتري و هم به صورت يك سرور كار مي‌كند. به عنوان يك سرور او به درخواستها از طرف ساير نظيرها پاسخ مي‌دهد. به عنوان يك مشتري درخواستها را براي ساير نظيرهاي خدمتكار ارسال مي‌كند.

يك خدمتكار در هنگام پيوستن به شبكه Gnutella ، ابتدا بايد آدرس يك خدمتكار ديگر را كه هم‌اكنون به شبكه متصل است بيابد. اين كار مي‌تواند با استفاده از حافظه‌هاي نهان ميزبان انجام شود مانند Guncache كه ليست خدمتكاران Gnutella را كه همواره به شبكه متصل هستند نگهداري مي‌كند. پس از آنكه يك آدرس يافت شد يك پيام درخواست” connect Gnutella ” براي خدمتكار متصل به شبكه فرستاده مي‌شود. خدمتكار متصل نيز با فرستادن يك پيام پاسخ “OK Gnutella” او را مي‌پذيرد و يا پيام درخواست را با ارسال هر پاسخ ديگري به خدمتكار تقاضاكننده رد مي‌كند. يك پيام رد مي‌تواند به دلايل مختلفي اتفاق بيفتد مثلاً فرسودگي اسلاتهاي ارتباط، داشتن نسخه‌هاي متفاوت پروتكل و …. هنگامي كه خدمتكار به شبكه متصل شد متوالياً همسايه‌هايش را براي كشف خدمتكاران ديگر بررسي مي‌كند. نوعاً هر خدمتكار زماني كه شبكه در حال فعاليت است به بيش از يك خدمتكار متصل است. اين به آن معني است كه هر خدمتكار مي‌تواند offline يا در هر زماني اتصالش قطع شود.

بنابراين باقي‌ماندن در ارتباط با چندين خدمتكار در يك لحظه براي جلوگيري از قطع اتصال از شبكه بسيار مهم است. هنگامي كه يك سرور پيام Ping را دريافت كرد، يك پيام Pong را به سروري كه پيام Ping را ايجاد كرده است باز مي‌گرداند. براي بازگشت پيام از همان مسيركه پيام اول دريافت شده است استفاده مي‌شود. يك پيام Pong شامل مشخصات خدمتكار مانند شماره پورت، IP آدرس، تعدادفايلهاي اشتراكي و مقدار كيلو بايتهاي اشتراكي است. Gnutella از هيچ سرور دايركتوري استفاده نمي‌كند در واقع هر سرور دايركتوري انديس محلي خود را نگهداري مي‌كند. براي جستجوي يك فايل، نود يك درخواست را براي تمام همسايه‌هايش كه به طور مستقيم كه به او متصلند مي‌فرستد. هنگامي كه پيام توسط يكي از همسايه دريافت شد ضابطه درخواست ^[12]دايركتوري انديس محلي را جستجو مي‌كند و پيام را براي ساير همسايه‌هاي خود ارسال مي‌دارد و بدين ترتيب اين ارسال ادامه پيدا مي‌كند. اگر در جستجو تطابقي در داده‌هاي محلي يك خدمتكار يافت اين خدمتكار يك پيام برد درخواست ^[13]را براي درخواست كننده در همان مسير بازمي‌گرداند. به هر حال،زماني كه يك توليد كننده پيام‌برد درخواست، يك خدمتكار در پشت ديوار آتش است، نمي‌تواند يك ارتباط با او برقرار كرد. در اين مورد پيام به وسيله خدمتكار درخواست كننده به خدمتكاري كه پيام‌برد درخواست را توليد مي‌كند فرستاده شده و در پشت ديوار آتش براي آغاز ارتباط باقي مي‌ماند. توجه كنيد كه انتقال فايل با استفاده از پروتكل HTTP و نه توسط پروتكل Gnutella انجام مي‌شود.

پس از آنكه Gnutella پيامهايش را منتشر كرد براي جلوگيري از تكرار و گسترش بي‌حد پيامها در شبكه، فيلد TTL ^[14]در سرآيند تمام پيامها قرار خواهد گرفت. اين فيلد هر زمان كه پيام از يك خدمتكار عبور مي‌كند كاهش داده مي‌شود. هر خدمتكاري كه اين فيلد را كاهش داده و مقدار آن را برابر صفر يافت پيام را از بين خواهد برد. هر خدمتكار همچنين نياز دارد كه ليستي از پيامهايي را كه اخيراً ديده است را با ذخيره‌ توصيفگر ID ^[15]و توصيفگر پي‌آيند هر پيام ورودي براي جلوگيري از ارسال همان پيام به صورت تكراري نگهداري كند. جزئيات توصيفي پيامها و پروتكل در قسمت بعدي شرح داده شده است. شكل 9 تصوير كلي پروتكل را توضيح مي‌دهد.

همانطور كه در اين شكل نشان داده شده است فرض شده است كه كاربر A كه به شبكه متصل بوده است مي‌خواهد بعضي از فايلها را مورد جستجو قرار دهد. او يك پيام درخواست را براي همسايه خود (كاربر B) مي‌فرستد. كاربر B ابتدا بررسي مي‌كند كه پيام دريافتي جز پيامهايي كه قبلاً دريافت كرده نباشد. سپس داده‌هاي محلي خود را براي تطابق جستجو كرده و اگر تطابقي را دريافت يك پيام‌برد درخواست را براي كاربر A بازمي‌گرداند. سپس كاربر B فيلد TTL را يك واحد كاهش مي‌دهد و پيام درخواست را براي كاربر D,E,C مي‌فرستد. كاربران E,D,C گامهاي مشابهاي را مانند كاربر B انجام مي‌دهند و آن را براي كاربران I,H,G,F مي‌فرستند و اين پروسس ادامه مي‌يابد.

فرض كنيد كه كاربر H اولين كسي باشد كه پيام درخواست را براي كاربر J مي‌فرستد. پس بنابراين پيامهاي درخواست بعدي ارسالي توسط كاربر I,G براي كاربر J وقتي جدول محلي نشان مي‌دهد كه كاربر J قبلاً پيام را دريافت كرده است دور انداخته مي‌شوند. اين حذف براي كاربر G مانند كاربر J وقتي پيام H به او مي‌رسد انجام مي‌شود. حالا فرض كنيد كاربر J يك تطابق را در داده‌هاي محلي خود بيابد. او باارسال يك پيام‌برد درخواست به كاربر A پاسخ مي‌دهد (از طريق مسير J به H به E به B به A )حال كاربر A مي‌تواند دانلود مستقيم فايل را با كاربر J با استفاده از پروتكل HTTP آغاز كند.

پروتكل Gnutella

در اين بخش جزئيات پيامهاي مورد استفاده در اين پروتكل با استفاده مرجع Kan (2001) توضيح داده مي‌شود. پيام مورد استفاده براي ايجاد ارتباط بين خدمتكاران توصيفگر Gnutella ^[16]ناميده مي‌شود. اين توصيفگرها شامل سرآيند و پي‌آيند توصيفگر هستند. پنج نوع توصيفگر Gnutella وجود دارد. Pong ,Ping درخواست^[17]، برد درخواست ^[18]و فشار ^[19]كه در جدول 2 توضيح داده شده‌اند.

سرآيند توصيفگر

سرآيند توصيفگر شامل پنج قسمت است. ID توصيفگر،پي‌آيند، TTL، گامها ^[20]و طول پي‌آيند.

شكل ص 66 25 m

• ID توصيفگر يك شناسه يكتا براي توصيفگر در شبكه است.
• پي‌آيند توصيفگر نوع هر توصيفگر را مشخص مي‌كند: 0XOO براي Ping،0X01 براي Pong ،0x40 براي فشار، 0x80 براي درخواست و 0x81 براي برد درخواست.
• TTL تعداد دفعاتي كه توصيفگر توسط خدمتكاران فرستاده شده قبل از آنكه از شبكه حذف شود را نشان مي‌دهد.
• گامها تعداد دفعاتي را كه توصيفگر ارسال شده است را نمايش مي‌دهد. در نتيجه در هر لحظه مجموع مقدار گامها و ارزش TTL همواره برابر ارزش اوليه TTL خواهد بود.
• طول پي‌آيند براي تعيين محل توصيفگر بعدي مورد استفاده قرار مي‌گيرد. سرآيند توصيفگر بعدي دقيقاً به اندازه طول پي‌آيند از انتهاي اين سرآيند قرار گرفته است.

پي‌آيند توصيفگر

پنج نوع نيز پي‌آيند توصيفگر وجود دارد: Ping ، Pong درخواست، برد درخواست و فشار.

1. Ping: در اين توصيفگر هيچ پي‌آيند وابسته‌اي وجود ندارد (طول آن برابر صفر است). يك خدمتكار اين توصيفگر را براي خدمتكاران ديگر به كار مي‌برد.

شكل ص 67 ،26 m

1. Pong:پي‌آيند اين توصيفگر چهار بخش دارد: پورت، IP آدرس، تعداد فايلهاي اشتراكي و حجم فايلهاي اشتراكي بر حسب كيلوبايت. توصيفگرهاي Pong تنها براي توصيفگرهاي Ping ورودي ارسال مي‌گردند (يك توصيفگر Ping مي‌تواند توسط توصيفگرهاي Pong زيادي پاسخ داده شود).

پورت مربوط به شماره پورتي است كه ارتباطات ورودي را تصديق مي‌كند. IP آدرس مربوط به ميزبان پاسخ دهنده است.#فايلهاي اشتراكي تعداد فايلهايي است كه خدمتكار با دادن IP آدرس و پورت آنها را بر روي شبكه مي‌گذارد. # كيلوبايتهاي اشتراكي نيز تعداد كيلوبايتهاي داده است كه مربوط به فايلهاي اشتراكي است.

3) درخواست: توصيفگر درخواست (شكل ص 67 ،26 m) كه به صورت ساختار پيام جستجوي Gnutella است شامل دو بخش مي‌باشد: سرعت حداقل و ضوابط جستجو.

سرعت حداقل سرعتي بر حسب KByte/sec در خدمتكار است كه با آن بايد به پيامها پاسخ داده شود. ضوابط جستجو شامل ضوابط جستجوي خدمتكار درخواست كننده است. حداكثر طول ضوابط جستجوباطول فيلد پي آيند سرآيند توصيفگر محدود مي‌شود.

1. برد درخواست: شكل ص 68 ،26 m اين توصيفگرها پاسخ توصيفگرهاي جستجو مي‌باشند كه در بالا به آن اشاره شد. اين توصيفگرها هنگامي كه تطابقي را ميان داده‌هاي محلي خود يافتند فرستاده مي‌شوند. فيلد ID توصيفگر در سرآيند توصيفگر برد درخواست بايد مشابه آنچه در توصيفگر درخواست تعيين شده است باشد. اين موضوع به خدمتكار درخواست كننده توصيفگر برد درخواست اجازه مي‌دهد كه توصيفگر جستجويي را كه آن را به وجود آورده بشناسد.

تعداد بردها برابر تعداد برد درخواستها در مجموعه نتايج است.

• IP آدرس مربوط به ميزبان پاسخ دهنده مي‌باشد.
• سرعت بر حسب KByte/ sec ميزبان پاسخ‌دهنده است.
• مجموعه جواب مجموعه‌اي از پاسخهاي جستجوهاي متناظر است. اين مجموعه شامل تعداد عناصر برنده است كه هر كدام شامل ساختاري به صورت انديس، اندازه و نام فايل است.
• شناسه خدمتكار يك رشته 16 بايتي است كه به صورت يكتا خدمتكار پاسخ دهنده در شبكه را نشان مي‌دهد.

1. فشار : توصيفگر فشار توسط خدمتكار درخواست‌كننده براي پاسخ دادن به يك خدمتكار پاسخ دهنده در پشت ديوار آتش جهت آغاز ارتباط ارسال مي‌شود.

• شناسه خدمتكار يك رشته 16 بايتي است كه به صورت يكتا خدمتكاري كه خواستار هل دادن فايل با انديس File- index است را مشخص مي‌كند. اين شناسه با شناسه خدمتكاري كه در توصيفگر برد درخواست متناظر توسط خدمتكار پشت ديوار آتش فرستاده شده مقدارگذاري مي‌شود.
• انديس فايل به صورت يكتا فايلي را كه بايد از خدمتكار درخواست شده استخراج شود مشخص مي‌كند.

قوانين

پنج قانون كلي پروتكل Gnutella جهت ايجاد و نگهداري ترافيك مطلوب در شبكه براي خدمتكاران وجود دارد:

قانون 1) تمام خدمتكاران بايد ID يكتاي 128 بيتي توصيفگر را در هر لحظه كه يك پيام دريافت و يا توليد شود به خاطر بسپارند. اگر اين پيامهاي حفظ شده دوباره دريافت شوند ديگر فرستاده نخواهند شد. اين مسئله به كشف ايجاد حلقه در شبكه كمك مي‌كند بنابراين ترافيك غير ضروري كاهش خواهد يافت.

قانون 2) توصيفگرهاي فشار، برد درخواست و Pong تنها بايد در مسيري كه وروديهاي Ping ، درخواست و برد درخواست از آن دريافت شده‌اند ارسال گردند. اين موضوع اطمينان مي‌دهد كه تنها خدمتكاراني كه توصيفگر Ping (درخواست و برد درخواست ) را مسيريابي مي‌كنند مي‌توانند توصيفگر Pong (برد درخواست و فشار) را در پاسخ مشاهده كنند. يك خدمتكار كه يك توصيفگر Pong با شماره توصيفگر n دريافت مي‌كند يك توصيفگر Pong با شماره توصيفگر n نمي‌بيند و توصيفگر Pong بايداز شبكه حذف شود.

قانون 3) يك خدمتكار توصيفگر درخواست و Ping را براي تمام خدمتكاراني كه مستقيماًٌ به آن متصل شده‌اند ارسال مي‌كند (به جز براي خدمتكاري كه آن رافرستاده است)

قانون 4) يك خدمتكار پيش از آنكه توصيفگر را به خدمتكار ديگري ارسال كند فيلد TTL را كاهش و فيلد گامها را افزايش مي‌دهد. اگر پس از كاهش فيلد TTL سرآيند، اين فيلد برابر صفر شود توصيفگر حذف خواهد شد.

قانون 5) اگر يك خدمتكار، يك توصيفگر را با پي‌آيند توصيفگر مشابه و شماره توصيفگر همانند آنچه قبلاً دريافت كرده است دريافت كند (با بررسي جداول محلي خود) اين توصيفگر را حذف مي‌كند.

تحليل پروتكل Gnutella و روشهاي بهبود آن :

به عنوان يكي از پروتكلهاي اشتراك فايل نظير به نظير، Gnutella عمداً براي حصول چهار هدف اصلي طراحي شده بود:

• انعطاف‌پذيري: با آنكه اين شبكه از نوع adhoc است، هر خدمتكار مي‌تواند در هر لحظه به آن وصل يا ارتباطش راقطع كند. بنابراين اين پروتكل بايد به قدر كافي انعطاف‌پذير طراحي مي‌شود. تا بدون تغيير در عمليات خود بتواند به راحتي اعضاي خود راجا به جا كند.
• كارايي و مقياس‌پذيري: كارايي به معناي توان عملياتي در نظر گرفته مي‌شود كه هر خدمتكار آغاز كننده پيامهاي درخواست پيامهاي برد درخواست را درخواست زمان تصديق پيام دريافت خواهد كرد. مقياس‌پذيري نشان مي‌دهد كه اين پروتكل مي‌تواند تعداد زيادي از خدمتكاران را بدون تنزل كارايي به كار ببرد.
• قابليت اعتماد: اين جنبه بر روي مسائل امنيتي متمركز است كه حملات خارجي نبايد بتوانند داده پرمعني و مهم و يا نتيجه و يا حتي كارايي را كاهش دهد.
• گمنامي: اين موضوع اساساً مربوط به حمايت از پوشش شركت كنندگان و شناسايي افرادي است كه در شبكه به جستجو مي‌پردازد و يا اطلاعاتي را در آن فراهم مي‌كنند.

انعطاف‌پذيري:

با توجه به مسئله محيطهاي پويا درخواست Gnutella ، زماني كه يك خدمتكار به طور متناوب ساير خدمتكاران راا مورد بررسي قرار مي‌دهد بايد از جداشدن او از شبكه و در حال فعاليت نگه داشتن شبكه تا زمان ايجاد ارتباط حفاظت مي‌شود. اگر چه قدرت Gnutella از اين حقيقت ناشي ‌شود كه همزمان تعداد بسيار زيادي از كاربران فعال هستند و بسياري از آنها اطلاعات خود را به اشتراك مي‌گذارند.

كارايي و مقياس‌پذيري :

اين دو مقوله مي‌توانند به عنوان يكي از بزرگترين مسائل مهم در ارتباط با پروتكل Gnutella مطرح شوند. مشكلات وابسته به مسئله كارايي از خدمتكاراني كه با مدهاي سرعت پايين به شبكه متصل شده‌اند ناشي مي‌شود. اين خدمتكاران معمولاً در تمام شبكه پراكنده هستند و به صورت سيل‌آسا پيامها را دريافت مي‌كنند تا زماني كه بي‌علاقه و بي‌مسئوليت شوند كه در آن صورت با Offline بودن آنها هيچ تفاوتي ندارد. اين موضوع سبب مي‌شود كه شبكه چند پاره شده ( نظيرها در دسته‌هاي جدا از هم ديده شوند) و بنابراين پيامهاي درخواست محدود و به سوي دسته‌ها جدا روانه نشوند. پس نتايج جستجو كاهش پيدا خواهد كرد.

دومين مشكل مربوط به پيامهاي Ping و Pong است كه ميان خدمتكاران درخواست شبكه ارسال مي‌شود. زماني كه هر خدمتكار بايد دائماً ساير خدمتكاران را جهت به دست آوردن آدرسشان مورد بررسي قرار دهد (پيام Ping ارسال كند) تعداد زيادي از اين پيامها در شبكه رد و بدل مي‌شوند.. و در نتيجه پيامهاي Ping و Pong بزرگ و حجيم خواهند شد. يك تحقيق و بررسي انجام شده توسط ديمتيري^[21]، آنتونيو ^[22]وبيل^[23](2002) نشان مي‌دهد كه تعداد پيامهاي Pong مي‌تواند تا پنجاه درصد از ترافيك شبكه را مصرف كند. نتيجه اين است كه سرانجام كارايي شبكه به دليل استفاده شدن پهناي باند توسط پيامهاي Pong و Ping تنزل خواهد يافت. (توجه داشته باشيد كه پيامهاي Ping به تمام اتصالات مستقيم نظير ارسال مي‌شود. )

سومين مشكل كارايي از اين حقيقت ناشي مي‌شود كه Gnutella كاربران خود را براي اشتراك فايل آزاد مي‌گذارد. اين مسئله بسياري از كاربران را براي اينكه تنها دريافت كننده اطلاعات باشند تشويق مي‌كند. در واقع بسياري از آنها فقط به شبكه متصل مي‌شوند بدون آنكه هيچ فايلي را به اشتراك بگذارند. فرض كنيد كه TTL پيام درخواست برابر هفت باشد و هر خدمتكار به چهار خدمتكار ديگر متصل باشد. از لحاظ تئوري، يك جستجو از ميان 16384 خدمتكار عبور خواهد كرد اما تنها ده درصد از اين خدمتكاران فايلهاي خود را به اشتراك گذاشته‌اند، پس يك جستجو تنها 1600 خدمتكار را جستجو مي‌كند. اين موضوع احتمال يافتن فايل دلخواه را به طور قابل ملاحظه‌ كاهش خواهد داد.

مشكل چهارم شكست دانلودها است كه اكثراً مسبب آن اشتراك فايلهاي نيمه كامل يا محدوديت سرعت بارگذاري توسط كاربراني است كه اين فايل را به اشتراك گذاشته‌اند. رجوع به مسئله مقياس‌پذيري استدلال مي‌شود كه شبكه Gnutella نمي‌تواند به اندازه ادعاهاي خود قابل قياس باشد. اين موضوع به گسترش طبيعت پروتكل كه بسياري از پهناي باند را مصرف مي‌كند منجر مي‌شود. بنابراين تعدادي از كاربران توسط پهناي باند محدود خواهند شد. (تراكم شبكه ناشي از تراكم پيامهاي ارسالي است. ). اين وضع با طرح اصلي ايجاد پروتكل كه پشتيباني از تعداد نامحدودي كاربر است مغايرت دارد. فيلد TTL در سرآيند توصيفگر، كه پيش از اين توسط هر خدمتكار مشاهده كننده پيام ذخيره شده است و قوانين تحميلي توسط پروتكل براي ياري به كاهش اين مشكلات طراحي شده‌اند اما تكنيكهاي قدرتمند بسياري براي اطمينان از مقياس‌پذيري درست لازم است.

شيوه‌هاي مختلفي براي به دست آوردن كارايي و مقياس‌پذيري بالا وجود دارند: تشويق به اشتراك اطلاعات، نااميدي از بارگذاري رايگان، كاهش ترافيك غير ضروري شبكه، ايجاد و نگهداري يك ساختار شبكه سالم و … .تشويق به اشتراك اطلاعات مي‌تواند توسط ايجاد يك ويژگي پيش‌فرض براي اشتراك خودكار دانلودهاي كامل انجام شود. به اين معني كه هنگامي كه يك دانلود كامل شد، فايلهاي دانلودي جديد بطور خود‌كار توسط كاربران به اشتراك گذاشته شود شكستهاي دانلود مي‌تواند با ايجاد يك دايركتوري دانلود ناتمام براي جلوگيري از اشتراك فايلهاي نيمه تمام حل شوند.

دو نوع بارگذار آزاد^[24]وجود دارد:

1)كاربراني كه تنها فايلها را براي خود دانلود مي‌كنند بدون آنكه فايلي را براي دانلود ديگران فراهم كنند.

2) كاربراني كه اطلاعاتي با كيفيت پايين را براي دانلود فراهم مي‌آورند. مشكل بارگزاران آزاد مي‌تواند توسط بلوكه كردن دانلودهاي بر پايه وب يا بلوكه كردن درخواستها يا توسط متدهاي پاداش و تنبيه حل شود. (اين مسئله منجر به تغييراتي در پروتكل خواهد شد.)

براي كاهش ترافيك غيرضروري شبكه بايد تعداد پيامهاي Ping و Pong كاهش يابد. يك روش براي انجام اين كار اين است كه به طور متناوب شبكه را با دسته‌اي از قوانين بررسي كنيم كه به موجب آن يك نود تنها زماني مي‌تواند ارسال پيامهاي Ping را آغاز كند كه تشخيص دهد نظيرهايي كه مستقيماً به او متصل شده‌اند دو يا كمتر هستند. كار ايجادو نگهداري شبكه سالم مي‌تواند توسط قطع ارتباطي كه پتانسيل زيادي براي انسداد دارد به دست آيد. (اين مسئله مي‌تواند كاربراني با مودهاي كند در نقاط دور از مركز شبكه را جدا كند ) و يا به وسيله استفاده از يك برنامه اولويتي براي حذف پيامهاي غير ضروري در صورت انجام شود.

قانون قطع ارتباط مي‌تواندبه شكل زير انجام شود : ارتباط يك نود در صورتيكه نتواند پيامهاي خود رادر طول مدت ده ثانيه دريافت و يا ارسال كند و به يك Ping با فيلد TTL برابر با يك پاسخ نداده است قطع مي‌شود. برنامه اولويتي مي‌تواند براي قطع انتخابي پيامهاي ناكارآمد به كار رود. اولويت پيامها از زياد به كم به صورت زير است:

Ping > Pong > درخواست > برد درخواست > فشار

روش ديگري براي بهبود كارايي، به كارگيري سوپرنودها (كه درخواست ساختارهاي جديد نظيربه نظير مانند Fast Track و OpenFT مورد استفاده قرار مي‌گيرد) و نگهداري نتايج است. يكي از دلايل اصلي تنزل كارايي از اين فرض ناشي مي‌شود كه تمام خدمتكاران ازظرفيت يكسان برخوردارند. در واقع حقيقت اين است كه بسياري از خدمتكاران ارتباطات ضعيفي دارند(مودهايي باسرعت پايين) و شركت آنها در شبكه براي مدت كوتاهي است. اين مسئله سبب مي‌شود كه اين خدمتكاران كند براي اتخاذ و اجراي قوانين فعال شبكه نامناسب باشند. سوپرنودها مي‌توانند به عنوان وكيلي براي خدمتكاران ضعيف مورد استفاده قرار گيرند. سوپرنودها كه نوعاً پهناي باند زيادي دارند به عنوان يك مركز جستجوي محلي از طرف نظيرهاي كند و ضعيف متصل به آنها عمل كرده و به طور هميشگي و ثابتOnline بمانند. آنها مي‌توانند درخواست كاهش ترافيك شبكه با حفظ اطلاعات منتشر شده موثر باشند. استفاده از سوپرنودها توپولوژي شبكه Gnutella به صورت يك شبكه تركيبي مركزي و غيرمركزي در شكل 10 توضيح داده شده است.

براي كاهش زمان لازم جهت يافتن يك تطابق براي يك درخواست، هر خدمتكار مي‌تواند پيام‌برد درخواستي كه به او بازگردانده شده است را نگهداري كند. (همان پاسخي كه قبلاً توسط او يا به واسطه او فرستاده شده است.) در اين مورد هنگامي كه يك درخواست مشابه وابسته به برد درخواستي كه به او ارسال شده است وجود دارد، اين خدمتكار مي‌تواند برد درخواست مربوطه را به آن درخواست فوراً بازگرداند. اين روش زماني به خوبي انجام مي‌شود كه درخواستهاي تكراري زياد و عادي باشند. توجه داشته باشيد كه پيامهاي Pong نيز مي‌توانند به همين صورت ذخيره شوند. زمانيكه يك پيام Ping دريافت مي‌شود خدمتكار مي‌تواند پيام Pong ذخيره شده را فوراً برگرداند وبدين ترتيب ارسال پيامهاي Ping بيشتر را حذف كند. بنابراين بهتر است كه هر خدمتكار تمام پيامهاي Pong دريافتي را به خاطر بسپارد. وقتي همسايه‌هاي او يك پيام Ping با TTL برابر n ارسال مي‌كنند، خدمتكار با يك پيام Pong پاسخ خواهد داد و تمام Pong هاي ذخيره‌اي با گام كمتر از n محاسبه مي‌شوند. در نتيجه هر پيام Ping تنها در ارتباطات مستقيم همسايه‌ها منتشر مي‌شود و خدمتكاران نياز نيست كه پيهامهاي Pong مشابهي رابه صورت تكراري ارسال كنند.

قابليت اعتماد:

اين جنبه بر روي مسئله امنيت متمركز شده است. بسياري از كاربران بدانديش مي‌توانند شبكه را به سوء عمل كشانده و قابليت اعتماد را به خطر اندازند زماني كه شبكه Gnutella به طور كامل توزيع شد، اطلاعات بسياري از نودها توسط ماشينها مورد حمله قرار گرفت و سبب شد كه شبكه به طور كامل نتواند به وظايف خود عمل كند. به هر حال با ابداع و معرفي سوپرنودها، قابليت اعتماد اين شبكه با اين مسئله روبه رو است كه مهاجمان مي‌توانند به اين سوپرنودها حمله كرده و آنها را مورد هدف قرار دهند. حتي اگر تمام شبكه از كار نيفتد بخشهايي از شبكه مي‌تواند دچار زيان شديد شود. جدا از اين مسئله، سه نوع حمله وجود دارد كه مي‌تواند به آساني در ساختارهاي ضعيف رخنه كنند: طوفان سيل‌آسا، بدانديشي يا جعل اطلاعات و دزديدن درخواستها .

طوفان در شبكه به وسيله تعداد زيادي پيام درخواست يا تهيه پاسخهاي اشتباه براي تمام جستجوها ايجاد مي‌شود. توجه داشته باشيد طوفان Pong يا پيامهاي برد درخواست غيرقابل استفاده خواهد بود اگر هيچ پيام درخواستي يا Ping قبلاً ازهمان شبكه ارسال نشده باشد. همچنين طوفان پيامهاي Ping بيهوده خواهد بود چون پيامهاي Pong ذخيره مي‌شوند. مشكل طوفان مي‌تواند توسط تعادل بار در شبكه به حداقل برسد.

ايجاد بدانديشي يا اطلاعات جعلي مانند فايلهاي حاوي ويروس، فايلهايي با اطلاعات خراب يا تغيير داده شده و يا تبليغ گمراه كردن ديگران براي ايجاد تصور نادرست نسبت به يك فايل مشكلي واقعي را مي‌تواند به وجود آورد. چه چيزي بدتر ازاين خواهد بود كه فايلهاي ويروس تمايل به گسترش در شبكه دارند. بنابراين لازم است كه يك راه براي تصديق اطلاعات فايل قبل از دريافت آن داشته باشيم. يكي از راه حلهاي پيشنهاد شده كه توسط ديمتيري، آنتونيو و بيل در سال 2002 ارائه شد استفاده از تكنيك تبديل فوريه جهت اندازه‌گيري اطلاعات موجود در فايل از نظر بيتي بود.

درخواستهاي دزديدن hijacking مي‌توانند به آساني در شبكه Gnutella انجام شوند. اين موضوع از اعتماد سه بخش در شبكه منشا مي‌گيرد. استفاده از سوپرنودها دزدين درخواستها را بسيار آسان مي‌كند زيرا آنها مي‌توانند بخش بزرگي از درخواستها را مشاهده كنند. رمزنگاري نقطه به نقطه، جداول hash توزيع شده و مكانيسمهاي انتخابي تمام تكنيكهايي هستند كه براي كمك به پايداري در مقابل طوفان و جلوگيري از درخواستهاي حملات ارائه شده است. متأسفانه توپولوژي شبكه Gnutella به آساني با استفاده از يك جستجوگر و تحليل تجمع داده‌ها تعيين مي‌شود. بدين ترتيب راه موثري براي آموزش سرويس حملات به حمله كننده داده مي‌شود.

گمنامي

اين موضوع به طور طبيعي در شبكه Gnutella حاصل مي‌شود. خدمتكاران درخواست شده نمي‌دانند كه درخواست كنندگان چه كساني هستند چون آنها هر نظيري در طول مسير پيام مي‌توانند باشند. به طور مشابه به خدمتكاران درخواست كننده نمي‌دانند كه درخواست شوندگان چه كساني هستند. اين مي‌تواند يك مشكل به عنوان گمنامي باشدكه قادر مي‌سازد تهديدهاي امنيتي بسياري به آساني انجام شود.

از طرف ديگر اگر يك نفر فكر كند كه پروتكل Gnutella گمنامي نهايي را در شبكه فراهم مي‌كند متأسفانه يك هكر هم مي‌تواندحريم نفر ديگري را مورد حمله قرار دهد.(با اسكن شماره توصيفگر در سرآيند توصيفگر )بنابراين هيچ خدمتكاري در كل گمنام نيست.

Fast Track

يكي از جديدترين و نوظهورترين ساختارهاي نظير به نظير شبكه Fast Track است. اين شبكه به عنوان راه حل مشكلات موجود در Napster و Gnutella به وجود آمده است. اين شبكه در اصل يك شبكه پيوندي بر پايه دو يا چند توپولوژي اصلي شبكه است كه در مورد Fast Track اين تركيب شامل توپولوژي غيرمركزي و مركزي است.

پروتكل Fast Track

اين پروتكل يك ساختار اختصاصي است كه قوانين شبكه آن متعلق به شركت sherman networks است بنابراين تعداد افراد كمي از ساختارهاي آن آگاهي دارند. تلاشهاي زيادي بر پايه مهندسي معكوس براي كشف ساختار اين پروتكل انجام شده است. (يكي از پروژه‌ها giFT است)

اين تكنولوژي از دو ‘گره كنترلي در شبكه استفاده مي‌كند كه در شكل 11 نشان داده شده است. ‘گره اول دسته‌اي از نودهاي معمولي است كه به يك سوپرنود متصل شده‌اند. (ماشينهاي عادي با ارتباطات سرعت بالا )همان‌طور كه قبلاً گفته شد اين نوع ارتباطات از توپولوژي مركزي تقليد مي‌كند. ‘گره دوم تنها شامل سوپرنودها است كه به يكديگر به صورت توپولوژي مركزي متصل شده‌اند. تعداد نظيرهايي كه مي‌توانند به صورت سوپرنود طراحي شوند از ده تا چندين هزار تغيير مي‌كند. چون اين سوپرنودها خود نودهاي معمولي هستند و بدين ترتيب مي‌توانند به شبكه متصل و يا از آن جدا شوند بنابراين شبكه پويا خواهد بود وهمواره در حال تغيير است. براي اطمينان از ثبات دسترسي به شبكه، نياز به يك نظير اختصاصي وجود خواهد داشت (و يا چندين نظير)كه تسلسل شبكه را حفظ كنند.

بنابراين يك نود به عنوان نود boot خوانده مي‌شود. اين نود بايد هميشه در دسترس و online باشد. هنگامي كه يك مشتري Fast Track براي مثال Kazaa بر روي يك نظير انجام مي‌شود ابتدا بايد يك نود boot ارتباط برقرار كند. سپس نود boot تعيين مي‌كند كه اين نظير معمولي و يا يك سوپرنود باشد.در ادامه IP آدرسهاي ساير نودها (نه همه آنها) را خواهد داشت اگر يك سوپر نود شود و در غير اينصورت IP آدرس يكي از سوپرنودها براي اوتوسط نود boot معرفي مي‌شود.

مشتريان معين Fast Track مانند kazaa يك روش شناخته شده به نام سيستم اعتبار را براي آشكار سازي اعتبار يك كاربر معين تا توسط سطح مشاركت او به كار مي‌برند. اين اعتبار يك عدد بين صفر تا هزار است. هر چه يك كاربر بيشتر در شبكه بماندو فايلهاي بيشتري را به اشتراك بگذارد سطح مشاركت او بيشتر مي‌شود يعني بيشتر مورد توجه صفهاي سياستي قرار مي‌گيرد. و بنابراين سرويس بهتري را دريافت خواهدكرد. اين مسئله اساساً سبب تشويق كاربران براي اشتراك فايل مي‌شود و بدين ترتيب به صورت موثري تعداد مشتريان مسافر ^[25]را در شبكه كاهش مي‌دهد.

كشف منابع ^[26]مانند عمل انتشار در ميان سوپرنودها انجام مي‌شود. هنگامي كه يك نود از گره دوم درخواستي را ايجاد مي‌كند، ابتدا اين درخواست به سوي سوپرنود مربوطه آن نود هدايت مي‌شود. سپس درخواست براي تمام سوپرنودهاي متصل به شبكه منتشر مي‌شود. اينكار تا زماني كه فيلد TTL درخواست صفر شود ادامه مي‌يابد.بنابراين اگر براي مثال TTL درخواست برابر هفت باشد و ميانگين نودها براي يك سوپرنود ده باشد، مشتري Fast Track يازده برابر نودهايي را كه در شبكه Gnutella جستجو مي‌كند را بررسي خواهد كرد. اين موضوع براي مشتريان Fast Track پوشش بزرگتر و نتايج جستجوي بهتري را فراهم مي‌كند. اما مشكلي به وجود مي‌آيد و آن اين است كه مقدار داده‌اي كه از يك سوپرنود به سوپرنود ديگر فرستاده مي‌شود بايد كنترل شود. اين مشكل مشابه مشكلي است كه در شبكه Gnutella رخ مي‌داد. هر يك از سوپرنودها كه درخواستي را دريافت كرد يك جستجو را در پايگاه داده‌ انديس محلي خود كه شامل جستجو اطلاعاتي در مورد تمام فايلهاي اشتراكي نودهاي متصل است انجام مي‌دهد. هنگامي كه يك تطابق يافت شود، يك پاسخ در همان مسير براي نودي كه آن را ايجاد كرده است فرستاده خواهد شد. اين روش مسيريابي مانند آنچه در Gnutella بودانجام مي‌شود بنابراين خطر مواجه شدن با مشكل گم شدن پاسخها در مسير بازگشت به وجود مي‌آيد. اين مسئله ناشي از آن است كه ستون فقرات شبكه Gnutella از نظيرهايي تشكيل شده است كه به صورت گاه بگاه به شبكه متصل هستند. اين موضوع شايد به اين معني است كه بسته‌هاي پاسخ كه در مسير بازگشت گم شده‌اند به مدت طولاني در مسير نبوده‌اند زيرا در مسير يك يا چند نود لينك اتصالي خود راقطع كرده‌اند. مشكل مذكور، براي كاربران Kazaa چندان جدي نيست چون ستون فقرات شبكه Fast Track نظيرهايي با ارتباطات سرعت بالا (سوپرنودها) ساخته شده است و بدين ترتيب مسيرهاي بازگشت با اعتماد بيشتري مطرح و استفاده مي‌شوند.

OpeNFT

همانطور كه در بخش قبل اشاره شد، پروتكل شبكه Fast Track اختصاصي است و بنابراين اطلاعات در مورد آن بسيار كم است. اين مسئله منبع محركي براي افراد علاقه‌مند جهت تلاش براي شكستن اين پروتكل را فراهم كرد. يكي از اين پروژه‌ها، پروژه giFT است. بر اساس مقاله برگنر ^[27](2003) معناي ابتدايي كلمه giFT رابط عمومي ^[28]براي Fast Track يا giFT، Fast Track نيست بود.^[29]پروژه giFT در جهت شكستن پروتكل Fast Track انجام شد اما بعد از آن اين پروتكل توسط تغيير رمزنگاري خود دوباره شروع به كار كرد و تقريباً فعاليت را جهت انجام مهندسي معكوس بر روي خود غير ممكن ساخت.

وقتي امكان بيشتري براي شكستن اين پروتكل وجود نداشت هدف پروژه giFT به توسعه يك سيستم كه بتواند شبكه‌هاي ناهمگن متفاوت را متصل كند (و فايلها را بتوان در آن به اشتراك گذاشت) تغيير يافت. بدين ترتيب معناي كلمه اختصاصي giFT به انتقال فايل اينترنتي giFT ^[30]تغيير پيدا كرد. پروژه به توسعه يك پروتكل شبكه جديد وبهبود يافته كه شبيه Fast Track بود هدايت شد كهopenFT ناميده شد.

ساختار OpenFT

مشابه Fast Track ، اين پروتكل نيز نودهاي شبكه خود را توسط قوانين مختلف دسته‌بندي مي‌كند اما بجاي يك ساختار كنترلي دو قسمتي (گره‌اي)، OpenFT يك گره ديگر را نيز مي‌افزايد و به يك ساختار كنترلي سه‌ گره‌اي تبديل مي‌شود. همان طور كه در شكل 12، ديده مي‌شود، دسته‌بندي نودها بر پايه سرعت ارتباطات شبكه‌اي آنها، توان پردازش، مصرف حافظه و ميزان دسترسي و قابليت استفاده آنها انجام مي‌گيرد. گره اول از دسته‌هاي ماشينهاي معمولي كه به نودهاي كاربران ارجاع داده مي‌شود ساخته شده است. اين نودها ارتباطات با مجموعه‌اي بزرگ از نودهاي جستجو را نگهداري مي‌كنند. سپس نودهاي كاربران يك زيرمجموعه از نودهاي جستجو را كه به همراه اطلاعات فايلهاي اشتراكي به اشتراك گذاشته شده‌اند بروز مي‌كنند.

دومين گره از ماشينهايي تشكيل شده است كه به نودهاي جستجو اشاره دارند، اين نودها سرورهاي فعالي در شبكهOprnFT مي‌باشند. اين سرورها مسئول نگهداري شاخصهاي فايلهايي كه توسط نودهاي كاربر تحت امر آنها به اشتراك گذاشته شده‌اند هستند. به عنوان پيش‌فرض يك نود جستجو مي‌تواند اطلاعات ذخيره شده مربوط به پانصد نود كاربر را مديريت كند.

سومين گره شامل ‘گره كوچكي است زيرا نيازهاي محدوديتي و تعيين ‘گره آن بسيار سخت و دقيق است. شرايط اين ‘گره به اين گونه است كه تمام ميزبانان بايد قابليت اعتماد بالايي داشته باشند و همواره دردسترس باشند. اين نودهابه نودهاي انديسي مشهورند كه در هدف اصلي خود بايد شاخصهاي نودهاي جستجو موجودرا نگهداري كنند آنها همچنين كارهايي مانند جمع‌آوري آمار و كنترل ساختار شبكه را انجام مي‌‌دهند. به طور اساسي، اين گروه به عنوان اداره كننده ‘گره ديده مي‌شوند كه اطمينان مي‌دهند كه تمام نودهاي شركت كننده به خوبي كار مي‌كنند. توجه داشته باشيد كه ‘گره‌هاي دوم و سوم كنترلي مي‌توانند همزمان توسط يك نود انجام شوند. به عبارت ديگر، يك نود مي‌تواند هم به صورت يك نود جستجو و هم به صورت يك نود انديسي به طور همزمان عمل كند.

به طور پيش‌فرض هر نود كاربر بايد سه نود جستجو را براي نگهداي اطلاعات فايلهاي اشتراكي آنها نگهداري كند. اگر پذيرفته شد نودهاي جستجوي انتخاب شده يك والد^[31] براي اين نود كاربر مي‌شوند كه بايد اطلاعات فايلهاي اشتراكي را براي او بفرستند. علاوه بر اين تمام نودها بايد يك ليست از نودهاي جستجو در دسترس را نگهداري كنند. هنگامي كه يك درخواست فرستاده شد اين جستجو براي تمام نودهايي كه در ليست قرار دارند فرستاده خواهد شد.

پروتكل OpenFT

اين پروتكل از يك ساختار بسته ساده استفاده مي‌كند در نتيجه تجزيه آن بسيار آسان خواهد بود. در كل بيست و هشت بسته وجود دارد و در تمام آنها سرآيند بسته به صورت شكل زير است. شكل ص 78، 34m . length طول بسته به استثنايي سرآيند را نشان مي‌دهد. پياده‌سازي كنوني بيتهاي شانزده تا سي و يك را براي نگهداري پرچمها و هم اطلاعات نوع بسته مورد استفاده قرار مي‌دهند.

همان‌طور كه در بخش قبل توضيح داده شد هر نود با نقشي خاص در شبكه تعيين مي‌شود. امروزه كاربران خود نقشي را كه مي‌خواهند در شبكه ايفا كنند انتخاب مي‌كنند. جدول 3 ، 35 m خلاصه‌اي از بسته‌هاي به كار رفته در پروتكل شبكه OpenFT را نمايش مي‌دهد.

تمام بسته‌هاي اشاره شده به چندين دسته تقسيم مي‌شوند كه كاربرد و فعاليت آنها را به صورت واضح‌تري نشان مي‌دهد:

1)بسته‌هاي تاسيس جلسه ^[32]مانند version, nodeinfo,nodelist ,nodecap ,session

2) نگهداري ارتباط مانند ping

3)مديريت اشتراك فايل مانند , modshore, remshare , child addshare,

4) جستجوي فايل مانند browse , search

5) Misc (فراخواني به صورت اشتباه ) مانند Push , status

مقايسه

سيستهاي نظير به نظير روشهاي ساختاري و تكنيكهاي مختلفي را براي كشف منابع و بررسي و كارايي و مسائل امنيتي به كار مي‌برند. اين سيستمها در جدول 4 نشان داده شده‌اند.

1. Open source ↑
2. Hot lists ↑
3. Payload ↑
4. Header ↑
5. Blank ↑
6. Login acknowlement acknowlegment ↑
7. Message Digest 5 ↑
8. Uploaser ↑
9. Justin Frankel ↑
10. Tom Pepper ↑
11. Servents ↑
12. Query Criterion ↑
13. Quer hit message ↑
14. Time – To – Live ↑
15. Descriptor ID ↑
16. Gnutella descriptor ↑
17. Guery ↑
18. query hit ↑
19. Push ↑
20. hops ↑
21. Dimitri ↑
22. Antonio ↑
23. Bill ↑
24. Freeloader ↑
25. Passenger Clients ↑
26. Resource discovery ↑
27. Bergner ↑
28. Generic Interface ↑
29. GiFT isn’t Fast Track ↑
30. GiFT Internet File Transfer ↑
31. Parent ↑
32. Session establishment ↑