ما ذا تحوي عبارة الرد للping
اقتباساقتباسSome higher level reliable connection protocols are based onassumptions that old duplicate datagrams will not arrive after a
certain time elapses. The TTL is a way for such protocols to have
an assurance that their assumption is met.
أوف هذا كلام قوي بصراحة ... يعني لازالت هناك بروتوكلات تستخدم حقل ال TTL في الباكت من خلال قيم زمنية حقيقة تخمينية ... إذا هناك استخدام فعلي للزمن في التطبيقات .
لو نظرت حولك لن تجد بروتوكول يستخدم الـTTL كمقياس للزمن وهذا الكلام الذي تنقله في RFC791 خطأ ويناقض نفسه بنفسه. إما أن تقول أنه عبارة عن seconds ويكون _حقا_ ثواني، أو أن تقر أنه ليس ثواني بل hop count. لا يجوز أن نسمي البرتقال تفاحا.
هذا ما تم ذكره في RFC2460
اقتباسUnlike IPv4, IPv6 nodes are not required to enforce maximum packet lifetime. That is the reason the IPv4 "Time to Live" field was renamed "Hop Limit" in IPv6. In practice, very few, if any, IPv4 implementations conform to the requirement that they limit packet lifetime, so this is not a change in practice. Any upper-layer protocol that relies on the internet layer (whether IPv4 or IPv6) to limit packet lifetime ought to be upgraded to provide its own mechanisms for detecting and discarding obsolete packets.
فكما ترى لا يوجد تطبيق عملي للـTTL كأداة للزمن. فهذا خطأ في RFC791 وتم تصحيحه في RFC2460 بإعادة تسمية الحقل إلى hop limit من باب وضع الإسم على مسماه.
وبناءا على هذا فالـIPv4 أو IPv6 على حد سواء، أي بروتوكول يريد الزمن عليه استخدام آليات بديلة كوضع epoch time في الـpayload. ومثال تطبيقي لهذه الآلية هو بروتوكول الـRTP حيث أنه يضع الـtimestamp في حق خاص في الـRTP نفسه ولا يستخدم الـTTL أبدا. لماذا؟ لأن الـTTL لا يعبر عن الزمن.
الخلاصة أن هذا النقاش قديم وأكل عليه الزمن وشرب وألفت عليه الكتب. لا أقول حتى انقصم ظهر البعير 
، بل أقول حتى انقصم ظهر الفيل 
.
وهذا نص مقتبس من كتاب Routing TCP/IP من Cisco Press
http://books.google.ae/books?id=JjdF2yWqJA...result#PPA12,M1
الكمال لله، لكن أول مرة حد يقول لي "كن دقيقا في كلامك". ربما تقصد بالدقيق القمح :) هذا ممكن. لا أفهم عم تتحدث وماهو التناقض في كلامي الذي جعله خال من الدقة. لايوجد حقل اسمه Hop of Count فياليت توضح.اقتباسمرة اخرى اطالبك ان تكون دقيقا ... هو ليس حقل TTL بل هو حقل Hop of Count ... هذا هو البديل لل TTL الذي صنع هذه الإشكالية ... لو كانت الأمور كما تقول ببساطة " لاعلاقة للزمن بال TTL " لما تم تغيير هذا الحقل ولكن لأن الأمر هو كما ذكرنا اختلاف بين النظرية والتطبيق خلق هذه الإشكالية لدى البعض ..
إذا نفعتك أحد مشاركاتي فأدع بظهر الغيب لوالداي بالصحة والسلامة والسعادة وطول العمر وأن يكون هذا زيادة لهما في كل خير.
before asking: smart questions how-to
حياك الله
اقتباسلو نظرت حولك لن تجد بروتوكول يستخدم الـTTL كمقياس للزمن وهذا الكلام الذي تنقله في RFC791 خطأ ويناقض نفسه بنفسه. إما أن تقول أنه عبارة عن seconds ويكون _حقا_ ثواني، أو أن تقر أنه ليس ثواني بل hop count. لا يجوز أن نسمي البرتقال تفاحا.
اقتباسفكما ترى لا يوجد تطبيق عملي للـTTL كأداة للزمن. فهذا خطأ في RFC791 وتم تصحيحه في RFC2460 بإعادة تسمية الحقل إلى hop limit من باب وضع الإسم على مسماه.
هذنا تطبيق عملي جيد وواضح بما فيه الكفاية لإثبات صحة النظرية
اقتباسIn this assignment, you will implement a simplified version of the Routing Information Protocol (RIP); a simple intra-domain routing protocol used in some Internet networks. You will implement and test your routing protocol within a virtual network environment called Clack. Clack lets you build a (or in our case, part of a) fully-functional router in Java and has a graphical interface that enables you to visualize the flow of packets both between and within each router.
اقتباسTimers
RIP has several types of timers for sending periodic updates, timing out routes and actually removing routes from the routing table, see RFC 2453 for details. However, you will implement the following simpler timers.
Periodic updates: Every 10 seconds, the RIP process sends an unsolicited Response message containing the complete routing table to every neighboring router.
Route timeout: RIP maintains a TTL (time to live) field for each dynamic route (i.e., a route learned from a neighboring router. Local routes, which are directly connected networks, have an invalid TTL of -1). When a router announces a local route to a neighbor, it sets the TTL to 20 seconds in the update. When a router places a new route in its routing table, it uses the TTL value from the routing update. If a router sees an update containing a destination/next-hop pair that it is already using, it updates the TTL for that entry in its local routing table. Every 1 second, RIP decrements the TTL of all dynamic routes. If a TTL of a route reaches 0, the route is removed from the routing table.
For more information http://www.clackrouter.net/rip/
http://nsl.cs.surrey.sfu.ca/teaching/06/371/rfc2453.txt
اقتباسUnlike IPv4, IPv6 nodes are not required to enforce maximum packet lifetime. That is the reason the IPv4 "Time to Live" field was renamed "Hop Limit" in IPv6. In practice, very few, if any, IPv4 implementations conform to the requirement that they limit packet lifetime, so this is not a change in practice. Any upper-layer protocol that relies on the internet layer (whether IPv4 or IPv6) to limit packet lifetime ought to be upgraded to provide its own mechanisms for detecting and discarding obsolete packets
هذا الكلام يدعم فكرتي أكثر وأشكرك على وضعه فقد بين المقال اولا ان المشكلة في التطبيق in practice ولم يقل ان النظرية خطأ وربما ان احدا لم يقل ذلك من قبل كما بين إحتمال وجود تطبيقات تستعمل ال TTL كقيمة زمنية فعلية وربما خفي عن الكاتب انه توجد بعض التطبيقات وإن كانت نادرة جدا السبب الذي استدعى استحداث مفهوم جديد يعبر عن العملية بشكل افضل .
اقتباسوبناءا على هذا فالـIPv4 أو IPv6 على حد سواء، أي بروتوكول يريد الزمن عليه استخدام آليات بديلة كوضع epoch time في الـpayload. ومثال تطبيقي لهذه الآلية هو بروتوكول الـRTP حيث أنه يضع الـtimestamp في حق خاص في الـRTP نفسه ولا يستخدم الـTTL أبدا. لماذا؟ لأن الـTTL لا يعبر عن الزمن.
هذا الكلام غير صحيح فال IPV4 وال IPV6 يستخدمان مفهوم ال TTL في التعبير عن ال packet lifetime وليس ادل على ذلك من بروتوكول ال RIP ، اما ما تتحدث عنه هو فقط لتحديد ال Real Time .
هذه الكلام أيضا لايخدم فكرتك فهو ليس رفض للنظرية من الأساس انما كما قلنا لتعبير ادق للعملية .
اقتباسالكمال لله، لكن أول مرة حد يقول لي "كن دقيقا في كلامك". ربما تقصد بالدقيق القمح :) هذا ممكن. لا أفهم عم تتحدث وماهو التناقض في كلامي الذي جعله خال من الدقة. لايوجد حقل اسمه Hop of Count فياليت توضح.
:lol: لا دقيق ولاقمح ، أقصد hop limit
والمعنى أن ال hop limit شيء آخر يختلف عن ال TTL .
صفوة القول :
ان ال TTL يعبر عن عمر الباكت ووحدة قياسه الثانية ، وال Hop limit عبارة عن عدد النقاط التي تمر بها الباكت بحسب الآلية المذكورة .
كما ان الاختلاف في مجمله اصطلاحي .
والسلام عليكم :) .
تم تعديل هذه المشاركة بواسطة بوحضرم في 10 نوفمبر 2008 في 16:45
اقتباسTimersRIP has several types of timers for sending periodic updates, timing out routes and actually removing routes from the routing table, see RFC 2453 for details. However, you will implement the following simpler timers.
Periodic updates: Every 10 seconds, the RIP process sends an unsolicited Response message containing the complete routing table to every neighboring router.
Route timeout: RIP maintains a TTL (time to live) field for each dynamic route (i.e., a route learned from a neighboring router. Local routes, which are directly connected networks, have an invalid TTL of -1). When a Router announces a local route to a neighbor, it sets the TTL to 20 seconds in the update. When a Router places a new route in its routing table, it uses the TTL value from the routing update. If a Router sees an update containing a destination/next-hop pair that it is already using, it updates the TTL for that entry in its local routing table. Every 1 second, RIP decrements the TTL of all dynamic routes. If a TTL of a route reaches 0, the route is removed from the routing table.
أولا هذا ليس متوافق بروتوكول الـRIP لا 1 ولا 2، والنص يذكر أن الـtimers مختلفة للتبسيط. ولوقرأنا باقي النص سنجد ان الهدف منه تدريب على البروتوكولات وليس التطبيق الواقعي.
ثانيا، الRIP لا يعتمد على الـroute expiry بالـTTL في الـ IP header كما جاء في التدريب في الأعلى، إنما يعتمد على عداد timer يعمل locally ولا ينتشر بالـTTL.
لو نقوم بـsniffing للـRIP، سنجد أن الـRIP update يكون كل 30 ثانية بالـDefault والـIP Header TTL يكون 2. والذي يحدث في الواقع هو أن الـRoute يكون Valid حتى 120 ثانية بالـDefault حيث أن الـtimer locally. وهذا يناقض ماجاء في النص بالأعلى والذي معناه أن على الـroute ان يختفي من الـRouting table بعد ثانيتين حيث أن الراوتر (كما يزعم) ينشر هذا الـtimer من خلال الـTTL وأن الراوتر يقوم بإنقاصه أيضا locally كل ثانية.
سواءا الـRIP ولا RIPv2 فإنه لا يوجد أي استخدام لحقل الـTTL في الـIP header فيما يتعلق بالزمن. وأصلا لفظة TTL أو Time to Live ليست مذكورة في الـRFC لكل منهما. وكما قلت لك لا يوجد بروتوكول يستخدم الـTTL كمقياس للوقت.
هل يجوز أن أحضر مسطرة وأقيس بها الزمن؟ والرقم الناتج من خلال المسطرة ادونه واقول أن هذا عدد الثواني. وثم أقول أن هذا الفرق بين النظري والعملي؟ :)
بالنسبة لباقي الكلام عن الـTTL فهو إعادة لما قيل سابقا لذا لن أعيد كلامي مرة أخرى حفاظا على الحبر :). وأهم من هذا كله أني كتبت ما أعلم والقارئ يستطيع يختار مايريد.
إذا نفعتك أحد مشاركاتي فأدع بظهر الغيب لوالداي بالصحة والسلامة والسعادة وطول العمر وأن يكون هذا زيادة لهما في كل خير.
before asking: smart questions how-to
أردت أن أشكر الأخ eech55 والأخ بوحضرم على هذا النقاش الذي وضح لي هذه المعلومة الغامضة.
ولا داعي للشجار :) فكلاكما على صواب والمشكلة كما هو واضح من نقاشكما قائمة بسبب النظرية ... وتطور تطبيقها عمليا.
المهم إن إحنا عرفنا ما هي TTL وكفى الله المؤمنين شر القتال ... وإحنا نروح القسم وكل واحد ياخد حقة :)
تحياتي للجميع
حيا الله الشباب
بالنسبة لل RIP لم يقل احد انه يحتوي على حقل TTL حتى المقال السابق لم يصرح بهذا ولكن مايجري هو ان ال RIP يقوم بقراءة حقل ال TTL في الباكت ثم يقوم بمعالجته وتحويله الى قيم زمنية حقيقة يقوم بحفظها في حقل ال lifetime في ال ROUTING TABLE ومن ثم تحديثها لحين انتهاء صلاحيتها ..
واذا سلمنا جدلا ان ماذكر هو على سبيل التدريب ألا يعني ذلك انه قائم على أساس نظرية علمية أم انه كلام عبثي !
كل المقالات حين تتحدث عن ال TTL تذكر النظرية ثم توضح ال Mechanism ..
هذا ما لدي أخي العزيز وأشكرك على هذا النقاش الراقي :) .
الله يخليكم.. كفى الله المؤمنين شر القتال؟ :blink: لا أدري لماذا النقاشات المطولة _دائما_ يُنظر إليها على أنها شجار وقتال..
اسمحولي استغل هذه الفرصة واطلب منكم عدم النظر إلى الحوارات المطولة بهكذا نظرة.. ليس في هذا الموضوع، بل في أي موضوع آخر.
أخي TopSec أعلم أن قصدك خير، لكن أنا استغربت عندما قرأت هذا الرد وكأنه إقرار على المشاجرة.
أما بعد،،،
نعم وهذا الذي أقول أنه غير صحيح. حقل الـTTL لا يتحول إلى lifetime في الـROUTING TABLE. الـLifetime منفصل تماما وlocally ولا ينتقل بالـTTL بتاتا البتة.اقتباسبالنسبة لل RIP لم يقل احد انه يحتوي على حقل TTL حتى المقال السابق لم يصرح بهذا ولكن مايجري هو ان ال RIP يقوم بقراءة حقل ال TTL في الباكت ثم يقوم بمعالجته وتحويله الى قيم زمنية حقيقة يقوم بحفظها في حقل ال lifetime في ال ROUTING TABLE ومن ثم تحديثها لحين انتهاء صلاحيتها ..
القضية أنه لا يوجد بروتوكول يستخدم TTL للزمن. وإذا نظرنا جدلا إلى التطبيق التدريبي الذي يذكره الموقع فهو يحول الـhop count إلى زمن وهذا أشبه مايكون بتحويل الجرام إلى متر.. فالـTTL اسم على غير ذي مسمى وهذا ما هو مذكور في الكتب ومنه Routing TCP/IP والـRFC.اقتباسواذا سلمنا جدلا ان ماذكر هو على سبيل التدريب ألا يعني ذلك انه قائم على أساس نظرية علمية أم انه كلام عبثي !
ق
إذا نفعتك أحد مشاركاتي فأدع بظهر الغيب لوالداي بالصحة والسلامة والسعادة وطول العمر وأن يكون هذا زيادة لهما في كل خير.
before asking: smart questions how-to
حياك الله
أخي العزيز انت تارة تستدل بال RFC971 وحين تجد انها تخالف قولك تتهمها بانها ارتكبت خطأ في تعريف ال TTL ...
بالإضافة الى انني لم اجد احد انكر هذه النظرية من قبل ... وكل المراجع دائما ماتشير الى تعريف ال TTL وعلاقته بالزمن وتشير الى وحدة قياسه الثانية ثم بعد ذلك تعرج الى ذكر الاختلاف الحاصل في آالية التطبيق والتي ذكرت كثير من المراجع انه كان يستخدم فيه الزمن كقيم عشوائية قبل ان يتطور الأمر الى ما وصل اليه الحال الان وهذا هو مايعرف ب Conceptual Development ..
أضف الى هذا أن بروتوكول ال RIP يعمل وفق آاليات مختلفة تماما بعضها يختلف تماما عن الآخر وبعضها يتعارض مع غيره وهذا الكلام مذكور في ال RFC أيضا ..
وعليك ان تعترف ان رأيك هذا انت تتفرد به ولم يسبقك اليه احد " في انكار علاقة الزمن بال TTL نظريا وعمليا "
مع تقديري لرأيك :) .
استدلالي بالـRFC791 هو لذكر أن الـTTL لا يعبر عن ثانية، فهو ينقص بغض النظر عن الوقت المنقضي:
هذا الإقتباس الوحيد لي في RFC791 والهدف منه أن الـRFC791 تقر أنها في الحقيقة ليست ثواني. أو كما تسميها أنت "تطبيق عملي". لكنها لاتزال تطلق لفظة seconds و إسم TTL وهذا هو الخطأ الذي تم تصحيحه في IPv6 والذي أتكلم عنه. فقضية هل هذا المصطلح سليم أم خطأ، طبعا هو خطأ وتم تغيير إسمه إلى hop limit في RFC2460اقتباسThe time is measured in units of seconds, but since every module that processes a datagram must decrease the TTL by at least one even if it process the datagram in less than a second, the TTL must be thought of only as an upper bound on the time a datagram may exist
وجهة نظرك هي أن TTL تقاس بالثانية "نظريا" لكن "عمليا" تقاس بالـhop count. وجهة النظر هذه واضحة بالنسبة لي وأحترمها أيضا، ولكني لا أتفق معها لأنها وصف غير دقيق لهذه العملية.
لماذا تمت اعادة صياغة الإسم من TTL إلى Hop Limit إذا كان كل شيء منطقيا وجميلا؟ اذا كنت منفردا بهذا الكلام لما تم تغيير الإسم في IPv6 إلا برشوة مني :)اقتباسوعليك ان تعترف ان رأيك هذا انت تتفرد به ولم يسبقك اليه احد " في انكار علاقة الزمن بال TTL نظريا وعمليا "
الإختلاف في استخدام الـTTL غير مذكور، فلا يوجد من يستخدم حقل الـTTL لنقل الـtimer بالنسبة لـRIP. وهذا هو الموضوع.اقتباسأضف الى هذا أن بروتوكول ال RIP يعمل وفق آاليات مختلفة تماما بعضها يختلف تماما عن الآخر وبعضها يتعارض مع غيره وهذا الكلام مذكور في ال RFC أيضا ..
الـRFCs ليست منزلة من السماء :) وهناك أخطاء أخرى في IPv4 وبروتوكولات أخرى.. ولا يجب تعقيد ما هو سهل في سبيل الدفاع عن أخطاء سابقة.
إذا نفعتك أحد مشاركاتي فأدع بظهر الغيب لوالداي بالصحة والسلامة والسعادة وطول العمر وأن يكون هذا زيادة لهما في كل خير.
before asking: smart questions how-to
حياك الله
اقتباسأن الـRFC791 تقر أنها في الحقيقة ليست ثواني. أو كما تسميها أنت "تطبيق عملي". لكنها لاتزال تطلق لفظة seconds و إسم TTL وهذا هو الخطأ الذي تم تصحيحه في IPv6 والذي أتكلم عنه
دائما حينما نتحدث عن ال TTL سنجد انفسنا ملزمين بالقول ان وحدة قياسها الثانية فهما مرتبطين بحبل وثيق ، ولو كان من الممكن الفصل بينهما او وجود خطأ في العلاقة بين ال TTL والثانية لكان الأمر أسهل فلاحاجة لخلق مصطلح Hop limit يكفي ال RFC ان تبقي مصطلح ال TTL مع القول ان وحدة قياسه هي ال Hop count وانتهى الأمر ولكن هم يعلمون ان هذا القول سيدخلهم في متاهات وتناقضات اكبر ... أو ربما ان الأمر متعلق بالرشوة التي قدمتها لهم :wink: .
اقتباسوجهة نظرك هي أن TTL تقاس بالثانية "نظريا" لكن "عمليا" تقاس بالـhop count. وجهة النظر هذه واضحة بالنسبة لي وأحترمها أيضا، ولكني لا أتفق معها لأنها وصف غير دقيق لهذه العملية.
ربما كان الأجدر بنا القول انها وصف غير دقيق للعملية بدلا من نفيها تماما .
اقتباسالـRFCs ليست منزلة من السماء :) وهناك أخطاء أخرى في IPv4 وبروتوكولات أخرى
عادة ما يطلق عليها updates
تحياتي :)
اقتباسدائما حينما نتحدث عن ال TTL سنجد انفسنا ملزمين بالقول ان وحدة قياسها الثانية
يجب أن ننفي تماما ما هو ليس دقيق (ماعدى دقيق القمح) :wink: فالـRFC791 تقر _بعدم_ النظر إليها كـsecond، وتعلم جيدا أنه hop limit في الواقع. _لكن_ تطلق عليه إسم "ثانية".اقتباسربما كان الأجدر بنا القول انها وصف غير دقيق للعملية بدلا من نفيها تماما .
الإشكالية في RFC791 أكبر من هذا ويمتد إلى إسم الحقل نفسه. فإذا كان إسم الحقل Time-to-Live حينها _يجب_ أن يكون مابداخله عبارة عن Time ايضا. ولهذا السبب ليس بالإمكان تغيير الوحدة إلى hop count (فهو ليس Time unit) لأنه سيؤدي إلى تناقض مع إسم الحقل ذاته، وكأنك يا بوزيد ماغزيت :) فأفضل حل هو تغيير إسم الحقل إلى hop limit ووحدة القياس إلى الـhops معا في آن واحد. وهذا ما تم فعله فعلا في IPv6.اقتباسولو كان من الممكن الفصل بينهما او وجود خطأ في العلاقة بين ال TTL والثانية لكان الأمر أسهل فلاحاجة لخلق مصطلح Hop limit يكفي ال RFC ان تبقي مصطلح ال TTL مع القول ان وحدة قياسه هي ال Hop count وانتهى الأمر ولكن هم يعلمون ان هذا القول سيدخلهم في متاهات وتناقضات اكبر ... أو ربما ان الأمر متعلق بالرشوة التي قدمتها لهم.
الـUpdate الوحيد الذي صدر على RFC791 هو فيما يتعلق بتعريف حقل ToS. بتلخيص شديد هو IPP ثم DSCP ثم استخدام الـ2bits for future use للـECN (يعني الحين مافي future bits - الـIPv4 برمته سيكون جزء من الماضي بعد سنوات :)).اقتباسعادة ما يطلق عليها updates
لاحظ، "تعريف" وليس إعادة تسمية. و أيضا إعادة التعريف هذه لا تتعارض مع إسم الحقل نفسه. تغيير اسم الحقل أمر صعب ويتم تجنبه قدر الإمكان نظرا للإرتباك الذي يحدثه بين المبرمجين والكتب والشروحات. لذا أنا سعيد أنهم أبقوا على اسم الحقل كما هو (TTL) في IPv4 لأنهم إذا غيروها ستكون الكتب القديمة غير مفيدة وتؤدي إلى لخبطة :) سعيد أنهم انتظروا وأصلحوا هذا في IPv6.
تم تعديل هذه المشاركة بواسطة eech55 في 12 نوفمبر 2008 في 21:55
إذا نفعتك أحد مشاركاتي فأدع بظهر الغيب لوالداي بالصحة والسلامة والسعادة وطول العمر وأن يكون هذا زيادة لهما في كل خير.
before asking: smart questions how-to
السلام عليكم
اقتباسالإشكالية في RFC791 أكبر من هذا ويمتد إلى إسم الحقل نفسه. فإذا كان إسم الحقل Time-to-Live حينها _يجب_ أن يكون مابداخله عبارة عن Time ايضا. ولهذا السبب ليس بالإمكان تغيير الوحدة إلى hop count (فهو ليس Time unit) لأنه سيؤدي إلى تناقض مع إسم الحقل ذاته، وكأنك يا بوزيد ماغزيت فأفضل حل هو تغيير إسم الحقل إلى hop limit ووحدة القياس إلى الـhops معا في آن واحد. وهذا ما تم فعله فعلا في IPv6.
وهذا هو ماسعيت جاهدا لتوضيحه وهو اننا لايمكن ان نتحدث عن TTL ونقول ان وحدة قياسها ال Hop count فهذا هو عين التناقض .
اقتباسالـUpdate الوحيد الذي صدر على RFC791 هو فيما يتعلق بتعريف حقل ToS. بتلخيص شديد هو IPP ثم DSCP ثم استخدام الـ2bits for future use للـECN (يعني الحين مافي future bits - الـIPv4 برمته سيكون جزء من الماضي بعد سنوات ).
تاريخ ال RFC791 مليء بالتحديثات والتعديلات ومنها ال RFC919 وال RFC922 وال RFC950 وجميعها متعلقة بال Broadcasting internet datagrams and subnetting
اقتباسلاحظ، "تعريف" وليس إعادة تسمية. و أيضا إعادة التعريف هذه لا تتعارض مع إسم الحقل نفسه. تغيير اسم الحقل أمر صعب ويتم تجنبه قدر الإمكان نظرا للإرتباك الذي يحدثه بين المبرمجين والكتب والشروحات. لذا أنا سعيد أنهم أبقوا على اسم الحقل كما هو (TTL) في IPv4 لأنهم إذا غيروها ستكون الكتب القديمة غير مفيدة وتؤدي إلى لخبطة سعيد أنهم انتظروا وأصلحوا هذا في IPv6.
وبذا يظل تعريف ال TTL في IPV4 مختلف تماما عن ال Hop limit في IPV6 وان اتفقوا في ال Mechanism ، وانا سعيد بهذا أيضا :) .
Nice weekend
ولا واحدة من هذه الـRFC عبارة عن update. فهي عبارة عن RFC مكملة للـRFC791 ولم يتم ذكرها في RFC791 أساسا حتى نقول أنه update عليها. و لفظة update فيما يتعلق بالـRFCs لا يستخدم للمكملات، بل فقط للمغيرات.اقتباستاريخ ال RFC791 مليء بالتحديثات والتعديلات ومنها ال RFC919 وال RFC922 وال RFC950 وجميعها متعلقة بال Broadcasting internet datagrams and subnetting
التحديث الوحيد الذي طرأ على ما تم ذكره في RFC791 فهو _فقط_ فيما يتعلق بالـToS byte. وهما DSCP و ECN. وللعلم حتى هذه الـRFCs لا تزال proposed RFC وليست Approved إلى الآن. لكنها عمليا مستخدمة وواسعة الإنتشار.
بل يمكننا فنحن لسنا مجبرين بإتباع الأخطاء (وخاصة اذا كانت معلومة وتم تصحيحها). وسبب التناقض هو خطأ في الـRFC791 الذي تم اصلاحه في IPv6. وهذا الذي أقوله منذ أول رد لي في هذا الموضوع وهو توضيح الغموض حول الـTTL والإشكالات المترتبة عليه.اقتباسوهذا هو ماسعيت جاهدا لتوضيحه وهو اننا لايمكن ان نتحدث عن TTL ونقول ان وحدة قياسها ال Hop count فهذا هو عين التناقض .
لا أحد ينكر أنهم مختلفون. فدائما يوجد فرق بين الخطأ والصواب :) وأنا لست سعيدا لوجود الخطأ. لكني سعيد لتدارك الخطأ بالشكل السليم.اقتباسوبذا يظل تعريف ال TTL في IPV4 مختلف تماما عن ال Hop limit في IPV6 وان اتفقوا في ال Mechanism ، وانا سعيد بهذا أيضا regular_smile.gif .
إذا نفعتك أحد مشاركاتي فأدع بظهر الغيب لوالداي بالصحة والسلامة والسعادة وطول العمر وأن يكون هذا زيادة لهما في كل خير.
before asking: smart questions how-to
السلا م عليكم
أخي الفاضل لم يعد هناك الكثير ليقال حول هذا الموضوع غير انني أحب ان اؤكد وجهة نظري في هذا الموضوع وهو ان الTTL مصطلح يعبر عن الزمن المنقضي ووحدة قياسه الثانية بالقياس النظري وإن لم تكن تعبر عن الزمن الفعلي وهذا هو الذي تؤيده كل الكتب والمراجع وأما القول بغير ذلك فيحتاج الى مرجع معتمد ... ومابقي هو تكرار لماسبق ... ولك كل الشكر على إثراء الموضوع .
تحياتي :) .
تم تعديل هذه المشاركة بواسطة بوحضرم في 16 نوفمبر 2008 في 15:45
وعليكم السلام. اشكرك أخي على حوارك وسعة صدرك :)
وجهة نظرك واضحة وهي متقفة مع RFC791 ولها مني كل الإحترام. والفرق بيننا أنك متفق مع تعريف RFC791 وتجده صحيحا، بينما قولي هو أن هذه الوجهة خاطئة وتم تصحيحها RFC2460. ومرجعي بصفة عامة هو عدم وجود تطبيق عملي يستخدم الحقل كمقياس للزمن بالإضافة إلى المراجع الحديثة التي تطرقت لشرح سبب تغيير إسم الحقل لاحقا من TTL إلى hop limit. ومنها RFC2460 و Routing TCP/IP.
وماعدى ذلك فأنا متفق معك، وكلامك أحب إلي من لحم دجاج أو شواء يتقطر عرقا :P
إذا نفعتك أحد مشاركاتي فأدع بظهر الغيب لوالداي بالصحة والسلامة والسعادة وطول العمر وأن يكون هذا زيادة لهما في كل خير.
before asking: smart questions how-to
كالعاده ...
حسنا ... ان لست متفرغا لأخوض من جديد في مهاترات eech55 ... ولست متفرغا لأتتبع الأخطاء الإملائية كالفرق بين "و" و "أو"
كل ما ذكرته في كلامي على ذمتي ... وتغليقات بسيطه ...
أول من ذكر ان ال TTL متعلق بال HOP Count هو أنا ... ولا أريد تجيير الأمور ليبرز one hero في الموضوع كعاداتك ...
والكتابه بخط كبير يعد صراخا ...
سأعطيك معلومه جديده ...
ال TTL له وضعيتان مختلفتان للقياس ...
الأولى والتي يعرفها الجميع هي ال HOP COUNT ... والانرنت معبأ بتفاصيله فلا يحتاج الموضوع لكل هذه الفلسفه.
الثانيه هي TIME COUNT !!!
هذه الحاله تتم في حال أن الراوتر او ال HOP احتفظ بالباكيت لأكثر من ثانيه واحده سيقوم بزياده بمقدار 1 على ال TTL لكل ثانيه تمر على الباكت في ال HOP ... في هذه الحاله تصبح ال TTL شيئ مختلف عن ال HOP COUNT لتصبح TIME COUNT ...
الشيء الاخر الذي أريد التأكيد عليه هو ان ال TTL متعلق بال QoS بشكل مباشر ... لأن ال QoS من احد اهم تطبيقاته هو ال Life Time للباكيت ... وبما ان ال Life Time للباكت مرتبط بال TTL يبقى ال QoS أحد أهم ال Best Practise لل TTL.
الى هنا أكتفي ...
It's hard to stay in such ridiculous situation
لا ترجم بالغيب.. أما بعد، الأهم:
هذا الكلام زيادة وغير مذكور في RFC791 ولا يوجد تطبيق عملي يقوم بهذا. وطبعا لو نظر أحد إلى شفرة المصدر إلى شفرة المصدر الخاصة بالـFreeBSD TCP/IP Stack فلن يجد شيئا.اقتباسالثانيه هي TIME COUNT !!!هذه الحاله تتم في حال أن الراوتر او ال HOP احتفظ بالباكيت لأكثر من ثانيه واحده سيقوم بزياده بمقدار 1 على ال TTL لكل ثانيه تمر على الباكت في ال HOP ... في هذه الحاله تصبح ال TTL شيئ مختلف عن ال HOP COUNT لتصبح TIME COUNT ...
الـtimers المستخدمة هي عبارة عن Internal timers ولا علاقة لها بالـTTL. على سبيل المثال:اقتباسالشيء الاخر الذي أريد التأكيد عليه هو ان ال TTL متعلق بال QoS بشكل مباشر ... لأن ال QoS من احد اهم تطبيقاته هو ال Life Time للباكيت ... وبما ان ال Life Time للباكت مرتبط بال TTL يبقى ال QoS أحد أهم ال Best Practise لل TTL.
WFQ
CBWFQ
PQ
CQ
WRR
SRR
RSVP
.. الخ - ولا واحدة تعتمد على الـTTL.
إذا نفعتك أحد مشاركاتي فأدع بظهر الغيب لوالداي بالصحة والسلامة والسعادة وطول العمر وأن يكون هذا زيادة لهما في كل خير.
before asking: smart questions how-to