جب نقل و حمل کی پرت غلطی کو کنٹرول فراہم کرتی ہے تو ڈیٹا لنک پرت میں غلطی کو کنٹرول کرنے کی کیا ضرورت ہے؟ غلطی کے دو کنٹرول میں کیا فرق ہے؟


جواب 1:

مبارک ہو ، آپ کو ایک معماری کی خرابی کا پتہ چلا ہے! آپ بالکل درست ہیں ، غلطی کی نشاندہی اور اصلاح بے کار طریقے سے کی جاتی ہے۔

اس کی وجہ یہ ہے کہ نیٹ ورکنگ جماعتوں کے مابین ایک معاہدہ ہے ، یہ کہ مختلف تہوں پر ہمارے پاس مختلف معیاری کمیٹیاں ہیں ، اور اس لئے کہ ان کمیٹیوں کے مابین سیاست اور دشمنی ہے جو منطقی اور فائدہ مند نتائج کو روکتی ہے۔

لنک کی سطح پر غلطی کا کنٹرول ہر ایک لنک پر پیکٹ کے ذریعے پیکٹ کی بنیاد پر ہوتا ہے۔ ایتھرنیٹ کے ل، ، یہ پورے فریم میں ایک CRC-32 ہے۔ یہ ہارڈ ویئر میں نافذ کیا جاتا ہے اور بنیادی طور پر یہ ایک چھوٹی سی چھوٹی قیمت ہے۔

ٹرانسپورٹ چیکسم ٹی سی پی اور اختیاری طور پر یو ڈی پی کے اندر ہے ، اور اس میں ٹی سی پی سیڈو ہیڈر کے علاوہ منسلک ڈیٹا طبقہ بھی شامل ہے۔ یہ بہت کمزور چیکسم ہے ، لیکن یہ ایک انتہائی آخر تک چیکسم ہے۔

اختتام سے آخر میں جائیداد بہت ضروری ہے کیونکہ ذرائع اور منزل کے مابین پیکٹ کو چھونے والے بہت سارے افعال موجود ہیں ، اور ان میں سے کچھ صرف لنک سطح کے چیکسم کے احاطہ میں ہیں۔ ہر روٹر پیکٹ لے رہا ہے ، ترمیم کر رہا ہے اور پھر اسے دوبارہ منتقل کر رہا ہے۔ اگرچہ اچھے راؤٹر غلطی کی نشاندہی اور اصلاح کو اندرونی طور پر نافذ کرتے ہیں ، لیکن ان پر عمل درآمد آسانی سے ہوسکتے ہیں اور اس سے پیکیٹ کی بدعنوانی کو معمولی طور پر متعارف کرایا جاسکتا ہے۔ اس کا مقابلہ کرنے کے لئے آخری سے آخر تک کا چیکسم ہے۔

ایک مثالی دنیا میں ، اگر ہمارے پاس انٹرنیٹ کو دوبارہ شروع کرنے کی صلاحیت ہوتی تو ، ہمارے پاس ٹرانسپورٹ لیئر کا بہت مضبوط چیکس ، جیسے CRC-32 ہوتا ، اور ہمیں ہر جگہ لنک لیول چیکس ٹیکس ادا نہیں کرنا پڑے گا۔


جواب 2:

لنک لیئر پر غلطی کو کنٹرول فراہم کرنا ایک اصلاح ہے ، کبھی ضرورت نہیں۔

نقل و حمل کی پرت ہمیشہ پیغام بھیج سکتی ہے اور اس کا انتظار اس کے ہم مرتبہ کے ذریعہ ریموٹ مشین پر کر سکتی ہے۔ اگر ٹائمر ختم ہونے سے قبل اس کا اعتراف آگے نہیں آتا ہے تو مرسل صرف پیغام بھیج سکتا ہے۔

اس حکمت عملی کے ساتھ پریشانی یہ ہے کہ یہ غیر موثر ہوسکتا ہے جیسا کہ ذیل میں بیان کیا گیا ہے:

نیٹ ورک پرت میں پیکٹ کے سائز کی مقدار پر پابندی ہے۔ لہذا اگر پیغام محدود سائز سے زیادہ سائز کا ہو تو اسے متعدد پیکٹوں میں توڑنا ہوگا۔ لیکن یہاں تک کہ یہ کوئی بڑا مسئلہ نہیں ہے کیونکہ پیغام کا سائز اکثر محدود سائز سے کم ہوتا ہے۔

اصل مسئلہ ڈیٹا لنک لیئر پر موجود ہے۔

پیکٹ میں زیادہ سے زیادہ سائز 65535 بائٹ ہے۔ جبکہ فریموں کی زیادہ سے زیادہ سائز (ایتھرنیٹ کی مثال لیں) 1500 بائٹس ہے۔ نیٹ ورک کی پرت ان پیرامیٹرز کو نہیں جانتی ہے۔ یہ ایک بہت بڑا پیکٹ بھیج سکتا ہے ، جس کا کہنا ہے کہ ، 10 فریموں میں ٹوٹ جاتا ہے ، جن میں سے اوسطا میں 2 کھو جاتے ہیں۔ تب اس پیکٹ کو گزرنے میں بہت وقت لگے گا۔ اس کے بجائے ، اگر انفرادی فریموں کو تسلیم اور دوبارہ منتقل کیا جاتا ہے ، تو غلطیوں کو زیادہ براہ راست اور زیادہ تیزی سے دور کیا جاسکتا ہے۔ معتبر چینلز ، جیسے فائبر پر ، ہیوی ویٹ ڈیٹا لنک پروٹوکول کا اوور ہیڈ غیر ضروری ہوسکتا ہے ، لیکن (فطری اعتبار سے ناقابل اعتبار) وائرلیس چینلز پر یہ لاگت کے قابل ہے۔

ایک مثال سے یہ بہت واضح ہوجائے گا:

پیکٹ کا سائز 14600 بائٹ ہونے دیں۔

ڈیٹا لنک پرت اس پیکٹ کو 14600/1500 = 10 فریموں میں توڑ دے گی۔

فرض کریں کہ A (ماخذ) سے بی (منزل) تک پہنچنے میں جو وقت نکلا ہے وہ 1 سیکنڈ ہے۔ ہم ایک آسان اسٹاپ اور ویٹ پروٹوکول استعمال کریں گے۔ لنک لیئر کے لئے ریٹرانسمیشن ٹائمر 3 سیکنڈ طے کیا گیا ہے۔

10 فریم اور اعتراف = (1 + 1) * 10 = 20 سیکنڈ کے ل Total کل وقت

اب فرض کریں کہ پہلے بھیجا ہوا فریم گم ہو گیا ہے۔ اگر لنک لیئر پر غلطی سے نمٹنا نہیں کیا گیا ہے تو وصول کنندہ مشین کی ٹرانسپورٹ پرت کے ذریعہ میسج کی جانچ پڑتال کے بعد ہی غلطی پائی جاسکتی ہے۔ سارا پیغام دوبارہ بھیجنا ہے۔

وہ چیزیں جو ہم اس حکمت عملی سے کھو دیتے ہیں۔

1۔ وقت کا ضیاع - پیغام کے لئے استعمال ہونے والے 20 سیکنڈ ضائع ہوگئے تھے کیونکہ پیغام دوبارہ بھیجنا پڑا

2 بینڈوتھ کا نقصان - پورا ڈیٹا دوبارہ بھیجنا پڑتا ہے۔

اب فرض کریں کہ غلطی سے نمٹنا ڈیٹا لنک لیئر پر کیا گیا ہے۔ پھر جیسے ہی پہلا فریم گم ہوجاتا ہے اسے ماخذ کے ذریعہ دوبارہ منتقل کیا جاتا ہے۔

اس طرح وہ وقت استعمال کیا گیا جس کے بعد ماخذ = retransmit ٹائم = 3 سیکنڈ کے ذریعہ غلطی کا پتہ لگ جاتا ہے۔

اور بینڈوتھ میں خسارہ = ایک فریم کا سائز۔

اس طرح ہم دیکھ سکتے ہیں کہ دوسری حکمت عملی وقت اور بینڈوتھ کے استعمال کے لحاظ سے کہیں بہتر ہے۔

ترمیم کریں: اس طرح کی وضاحت حاصل کرنے کے ل Tan کمپیوٹر نیٹ ورک کو ٹیننبام کے ذریعہ پڑھیں۔ تاہم اگر آپ گیئٹ کی تیاری کر رہے ہیں تو پھر فرزان کے ساتھ چلے جائیں۔


جواب 3:

لنک لیئر پر غلطی کو کنٹرول فراہم کرنا ایک اصلاح ہے ، کبھی ضرورت نہیں۔

نقل و حمل کی پرت ہمیشہ پیغام بھیج سکتی ہے اور اس کا انتظار اس کے ہم مرتبہ کے ذریعہ ریموٹ مشین پر کر سکتی ہے۔ اگر ٹائمر ختم ہونے سے قبل اس کا اعتراف آگے نہیں آتا ہے تو مرسل صرف پیغام بھیج سکتا ہے۔

اس حکمت عملی کے ساتھ پریشانی یہ ہے کہ یہ غیر موثر ہوسکتا ہے جیسا کہ ذیل میں بیان کیا گیا ہے:

نیٹ ورک پرت میں پیکٹ کے سائز کی مقدار پر پابندی ہے۔ لہذا اگر پیغام محدود سائز سے زیادہ سائز کا ہو تو اسے متعدد پیکٹوں میں توڑنا ہوگا۔ لیکن یہاں تک کہ یہ کوئی بڑا مسئلہ نہیں ہے کیونکہ پیغام کا سائز اکثر محدود سائز سے کم ہوتا ہے۔

اصل مسئلہ ڈیٹا لنک لیئر پر موجود ہے۔

پیکٹ میں زیادہ سے زیادہ سائز 65535 بائٹ ہے۔ جبکہ فریموں کی زیادہ سے زیادہ سائز (ایتھرنیٹ کی مثال لیں) 1500 بائٹس ہے۔ نیٹ ورک کی پرت ان پیرامیٹرز کو نہیں جانتی ہے۔ یہ ایک بہت بڑا پیکٹ بھیج سکتا ہے ، جس کا کہنا ہے کہ ، 10 فریموں میں ٹوٹ جاتا ہے ، جن میں سے اوسطا میں 2 کھو جاتے ہیں۔ تب اس پیکٹ کو گزرنے میں بہت وقت لگے گا۔ اس کے بجائے ، اگر انفرادی فریموں کو تسلیم اور دوبارہ منتقل کیا جاتا ہے ، تو غلطیوں کو زیادہ براہ راست اور زیادہ تیزی سے دور کیا جاسکتا ہے۔ معتبر چینلز ، جیسے فائبر پر ، ہیوی ویٹ ڈیٹا لنک پروٹوکول کا اوور ہیڈ غیر ضروری ہوسکتا ہے ، لیکن (فطری اعتبار سے ناقابل اعتبار) وائرلیس چینلز پر یہ لاگت کے قابل ہے۔

ایک مثال سے یہ بہت واضح ہوجائے گا:

پیکٹ کا سائز 14600 بائٹ ہونے دیں۔

ڈیٹا لنک پرت اس پیکٹ کو 14600/1500 = 10 فریموں میں توڑ دے گی۔

فرض کریں کہ A (ماخذ) سے بی (منزل) تک پہنچنے میں جو وقت نکلا ہے وہ 1 سیکنڈ ہے۔ ہم ایک آسان اسٹاپ اور ویٹ پروٹوکول استعمال کریں گے۔ لنک لیئر کے لئے ریٹرانسمیشن ٹائمر 3 سیکنڈ طے کیا گیا ہے۔

10 فریم اور اعتراف = (1 + 1) * 10 = 20 سیکنڈ کے ل Total کل وقت

اب فرض کریں کہ پہلے بھیجا ہوا فریم گم ہو گیا ہے۔ اگر لنک لیئر پر غلطی سے نمٹنا نہیں کیا گیا ہے تو وصول کنندہ مشین کی ٹرانسپورٹ پرت کے ذریعہ میسج کی جانچ پڑتال کے بعد ہی غلطی پائی جاسکتی ہے۔ سارا پیغام دوبارہ بھیجنا ہے۔

وہ چیزیں جو ہم اس حکمت عملی سے کھو دیتے ہیں۔

1۔ وقت کا ضیاع - پیغام کے لئے استعمال ہونے والے 20 سیکنڈ ضائع ہوگئے تھے کیونکہ پیغام دوبارہ بھیجنا پڑا

2 بینڈوتھ کا نقصان - پورا ڈیٹا دوبارہ بھیجنا پڑتا ہے۔

اب فرض کریں کہ غلطی سے نمٹنا ڈیٹا لنک لیئر پر کیا گیا ہے۔ پھر جیسے ہی پہلا فریم گم ہوجاتا ہے اسے ماخذ کے ذریعہ دوبارہ منتقل کیا جاتا ہے۔

اس طرح وہ وقت استعمال کیا گیا جس کے بعد ماخذ = retransmit ٹائم = 3 سیکنڈ کے ذریعہ غلطی کا پتہ لگ جاتا ہے۔

اور بینڈوتھ میں خسارہ = ایک فریم کا سائز۔

اس طرح ہم دیکھ سکتے ہیں کہ دوسری حکمت عملی وقت اور بینڈوتھ کے استعمال کے لحاظ سے کہیں بہتر ہے۔

ترمیم کریں: اس طرح کی وضاحت حاصل کرنے کے ل Tan کمپیوٹر نیٹ ورک کو ٹیننبام کے ذریعہ پڑھیں۔ تاہم اگر آپ گیئٹ کی تیاری کر رہے ہیں تو پھر فرزان کے ساتھ چلے جائیں۔


جواب 4:

لنک لیئر پر غلطی کو کنٹرول فراہم کرنا ایک اصلاح ہے ، کبھی ضرورت نہیں۔

نقل و حمل کی پرت ہمیشہ پیغام بھیج سکتی ہے اور اس کا انتظار اس کے ہم مرتبہ کے ذریعہ ریموٹ مشین پر کر سکتی ہے۔ اگر ٹائمر ختم ہونے سے قبل اس کا اعتراف آگے نہیں آتا ہے تو مرسل صرف پیغام بھیج سکتا ہے۔

اس حکمت عملی کے ساتھ پریشانی یہ ہے کہ یہ غیر موثر ہوسکتا ہے جیسا کہ ذیل میں بیان کیا گیا ہے:

نیٹ ورک پرت میں پیکٹ کے سائز کی مقدار پر پابندی ہے۔ لہذا اگر پیغام محدود سائز سے زیادہ سائز کا ہو تو اسے متعدد پیکٹوں میں توڑنا ہوگا۔ لیکن یہاں تک کہ یہ کوئی بڑا مسئلہ نہیں ہے کیونکہ پیغام کا سائز اکثر محدود سائز سے کم ہوتا ہے۔

اصل مسئلہ ڈیٹا لنک لیئر پر موجود ہے۔

پیکٹ میں زیادہ سے زیادہ سائز 65535 بائٹ ہے۔ جبکہ فریموں کی زیادہ سے زیادہ سائز (ایتھرنیٹ کی مثال لیں) 1500 بائٹس ہے۔ نیٹ ورک کی پرت ان پیرامیٹرز کو نہیں جانتی ہے۔ یہ ایک بہت بڑا پیکٹ بھیج سکتا ہے ، جس کا کہنا ہے کہ ، 10 فریموں میں ٹوٹ جاتا ہے ، جن میں سے اوسطا میں 2 کھو جاتے ہیں۔ تب اس پیکٹ کو گزرنے میں بہت وقت لگے گا۔ اس کے بجائے ، اگر انفرادی فریموں کو تسلیم اور دوبارہ منتقل کیا جاتا ہے ، تو غلطیوں کو زیادہ براہ راست اور زیادہ تیزی سے دور کیا جاسکتا ہے۔ معتبر چینلز ، جیسے فائبر پر ، ہیوی ویٹ ڈیٹا لنک پروٹوکول کا اوور ہیڈ غیر ضروری ہوسکتا ہے ، لیکن (فطری اعتبار سے ناقابل اعتبار) وائرلیس چینلز پر یہ لاگت کے قابل ہے۔

ایک مثال سے یہ بہت واضح ہوجائے گا:

پیکٹ کا سائز 14600 بائٹ ہونے دیں۔

ڈیٹا لنک پرت اس پیکٹ کو 14600/1500 = 10 فریموں میں توڑ دے گی۔

فرض کریں کہ A (ماخذ) سے بی (منزل) تک پہنچنے میں جو وقت نکلا ہے وہ 1 سیکنڈ ہے۔ ہم ایک آسان اسٹاپ اور ویٹ پروٹوکول استعمال کریں گے۔ لنک لیئر کے لئے ریٹرانسمیشن ٹائمر 3 سیکنڈ طے کیا گیا ہے۔

10 فریم اور اعتراف = (1 + 1) * 10 = 20 سیکنڈ کے ل Total کل وقت

اب فرض کریں کہ پہلے بھیجا ہوا فریم گم ہو گیا ہے۔ اگر لنک لیئر پر غلطی سے نمٹنا نہیں کیا گیا ہے تو وصول کنندہ مشین کی ٹرانسپورٹ پرت کے ذریعہ میسج کی جانچ پڑتال کے بعد ہی غلطی پائی جاسکتی ہے۔ سارا پیغام دوبارہ بھیجنا ہے۔

وہ چیزیں جو ہم اس حکمت عملی سے کھو دیتے ہیں۔

1۔ وقت کا ضیاع - پیغام کے لئے استعمال ہونے والے 20 سیکنڈ ضائع ہوگئے تھے کیونکہ پیغام دوبارہ بھیجنا پڑا

2 بینڈوتھ کا نقصان - پورا ڈیٹا دوبارہ بھیجنا پڑتا ہے۔

اب فرض کریں کہ غلطی سے نمٹنا ڈیٹا لنک لیئر پر کیا گیا ہے۔ پھر جیسے ہی پہلا فریم گم ہوجاتا ہے اسے ماخذ کے ذریعہ دوبارہ منتقل کیا جاتا ہے۔

اس طرح وہ وقت استعمال کیا گیا جس کے بعد ماخذ = retransmit ٹائم = 3 سیکنڈ کے ذریعہ غلطی کا پتہ لگ جاتا ہے۔

اور بینڈوتھ میں خسارہ = ایک فریم کا سائز۔

اس طرح ہم دیکھ سکتے ہیں کہ دوسری حکمت عملی وقت اور بینڈوتھ کے استعمال کے لحاظ سے کہیں بہتر ہے۔

ترمیم کریں: اس طرح کی وضاحت حاصل کرنے کے ل Tan کمپیوٹر نیٹ ورک کو ٹیننبام کے ذریعہ پڑھیں۔ تاہم اگر آپ گیئٹ کی تیاری کر رہے ہیں تو پھر فرزان کے ساتھ چلے جائیں۔