টিসিপি বিকল্পটি কখন SO_LINGER (0) প্রয়োজন?

Question

আমি মনে করি আমি বিকল্পটির আনুষ্ঠানিক অর্থ বুঝতে পারি। কিছু লিগ্যাসি কোডে আমি এখন পরিচালনা করছি, বিকল্পটি ব্যবহৃত হয়েছে। আরএসটি সম্পর্কে গ্রাহক তার পক্ষ থেকে কাছাকাছি সংযোগের দিক থেকে এফআইএন এর প্রতিক্রিয়া হিসাবে অভিযোগ করেন।

আমি নিশ্চিত নই যে আমি এটি নিরাপদে সরিয়ে ফেলতে পারি, কারণ এটি কখন ব্যবহার করা উচিত তা আমি বুঝতে পারি না।

বিকল্পটি কখন প্রয়োজন হবে তার একটি উদাহরণ দিতে পারেন?

Comments

আপনার এটি অপসারণ করা উচিত। এটি প্রোডাকশন কোডে ব্যবহার করা উচিত নয়। আমি কখনই এটি ব্যবহার করতে দেখেছি তা অবৈধ মানদণ্ডের ফলাফল হিসাবে।

— লার্নের মারকুইস

Answer 1

SO_LINGERশূন্যের সময়সীমা নির্ধারণের সাধারণ কারণটি হ'ল TIME_WAITরাজ্যে বসে প্রচুর সংযোগ এড়ানো , সার্ভারে সমস্ত উপলব্ধ সংস্থানগুলি বেঁধে রাখা।

যখন কোনও টিসিপি সংযোগ পরিষ্কারভাবে বন্ধ হয়ে যায়, তখন ক্লোজটি ("অ্যাক্টিভ ক্লোজ") শুরু করা শেষটি TIME_WAITকয়েক মিনিটের জন্য বসে সংযোগের সাথে শেষ হয় । সুতরাং যদি আপনার প্রোটোকলটি এমন এক যেখানে সার্ভারটি সংযোগটি খুব কাছাকাছিভাবে সূচনা করে এবং খুব বড় সংখ্যক স্বল্প-জীবন সংযোগের সাথে জড়িত থাকে, তবে এটি এই সমস্যার জন্য সংবেদনশীল হতে পারে।

এটি কোনও ভাল ধারণা নয়, যদিও - TIME_WAITকোনও কারণে উপস্থিত রয়েছে (পুরানো সংযোগগুলি থেকে বিপথগামী প্যাকেটগুলি নতুন সংযোগে হস্তক্ষেপ করবে না তা নিশ্চিত করার জন্য)। আপনার প্রোটোকলটি এমন একটিতে নতুন করে ডিজাইন করা আরও ভাল ধারণা যেখানে ক্লায়েন্ট যদি সম্ভব হয় তবে সংযোগটি বন্ধের সূচনা করে।

Comments

আমি সম্পূর্ণভাবে রাজী. আমি একটি মনিটরিং অ্যাপ্লিকেশন দেখেছি যা অনেকগুলি (প্রতি হাজার সেকেন্ডে কয়েক হাজার স্বল্প জীবিত সংযোগগুলি) চালু করছিল এবং এতে আরও বড় (এক হাজার সংযোগ) স্কেল করার প্রব্লেম রয়েছে। কেন জানি না, তবে অ্যাপ্লিকেশনটি কোনও প্রতিক্রিয়াশীল ছিল না। কেউ OSO রিসোর্সগুলি দ্রুত মুক্ত করতে SO_LINGER = সত্য, TIME_WAIT = 0 এর পরামর্শ দিয়েছিল এবং সংক্ষিপ্ত তদন্তের পরে আমরা খুব ভাল ফলাফল দিয়ে এই সমাধানটি চেষ্টা করেছি। TIME_WAIT আর এই অ্যাপ্লিকেশনটির জন্য সমস্যা নয়।

— bartosz.r

আমি একমত নই টিসিপির শীর্ষে বসে একটি অ্যাপ্লিকেশন স্তরের প্রোটোকলটি এমনভাবে ডিজাইন করা উচিত যাতে ক্লায়েন্ট সর্বদা সংযোগটি শুরু করে। এইভাবে, TIME_WAITক্লায়েন্ট কোনও ক্ষতি না করে বসে থাকবে। "ইউএনআইএক্স নেটওয়ার্ক প্রোগ্রামিং" তৃতীয় সংস্করণ (স্টিভেনস এট আল) পৃষ্ঠা 203 তে যেমন বলেছে তা মনে রাখবেন: "টিআইএম-ওআইএইটি রাষ্ট্রটি আপনার বন্ধু এবং সেখানে আমাদের সহায়তা করার জন্য রয়েছে the "

— এমজিডি

যদি কোনও ক্লায়েন্ট প্রতি 30 সেকেন্ডে 4000 সংযোগ খুলতে চায় (এই মনিটরিং অ্যাপ্লিকেশনটি ক্লায়েন্ট! কারণ এটি সংযোগের সূচনা করে)? হ্যাঁ আমরা অ্যাপ্লিকেশনটিকে নতুনভাবে ডিজাইজ করতে পারি, অবকাঠামোতে কিছু স্থানীয় এজেন্ট যুক্ত করতে পারি, মডেলটিকে ধাক্কা দিতে পারি। তবে যদি ইতিমধ্যে আমাদের কাছে এমন অ্যাপ্লিকেশন রয়েছে এবং এটি বাড়তে থাকে তবে আমরা টুইটারটি আরও দীর্ঘায়িত করে এটিকে কাজ করতে পারি। আপনি একটি প্যারাম পরিবর্তন করেছেন এবং নতুন আর্কিটেকচার বাস্তবায়নের জন্য কোনও বাজেট বিনিয়োগ না করে আপনার হঠাৎ কার্যকরী অ্যাপ্লিকেশন রয়েছে।

— bartosz.r

@ বার্টোস.আর: আমি কেবল বলছি যে টাইমআউট 0 সহ SO_LINGER ব্যবহার করা সত্যিই একটি শেষ অবলম্বন হওয়া উচিত। আবার, "ইউনিক্স নেটওয়ার্ক প্রোগ্রামিং" তৃতীয় সংস্করণ (স্টিভেনস এট আল) পৃষ্ঠা ২০৩ এও বলা হয়েছে যে আপনি ডেটা দুর্নীতির ঝুঁকি নিয়েছেন। আরএফসি 1337 পড়ার বিষয়ে বিবেচনা করুন যেখানে আপনি দেখতে পাচ্ছেন কেন TIME_WAIT আপনার বন্ধু।

— এমজিডি

@ কেএফ নং, ক্লাসিক সমাধানটি একটি সংযোগ পুল হবে, যেমন প্রতিটি ভারী-ডিউটি ​​টিসিপি এপিআইতে দেখা যায়, উদাহরণস্বরূপ HTTP 1.1।

— লার্নের মারকুইস

Answer 2

আমার পরামর্শের জন্য, দয়া করে শেষ বিভাগটি পড়ুন: "কখন টাইমআউট 0 এর সাথে SO_LINGER ব্যবহার করবেন" ।

আমরা এই সম্পর্কে একটি সামান্য বক্তৃতা আসার আগে:

• সাধারণ টিসিপি সমাপ্তি
• TIME_WAIT
• FIN, ACKএবংRST

সাধারণ টিসিপি সমাপ্তি

সাধারণ টিসিপি সমাপ্তির ক্রমটি এর মতো দেখায় (সরলীকৃত):

আমাদের দুটি সমকক্ষ রয়েছে: এ এবং বি

1. একটি কল close()
   • এ FINবি কে প্রেরণ করে
   • ক FIN_WAIT_1রাজ্যে যায়
2. বি পায় FIN
   • বি পাঠায় ACKক তে
   • বি CLOSE_WAITরাজ্যে যায়
3. এ গ্রহণ করে ACK
   • ক FIN_WAIT_2রাজ্যে যায়
4. বি কল close()
   • বি পাঠায় FINক তে
   • বি LAST_ACKরাজ্যে যায়
5. এ গ্রহণ করে FIN
   • এ ACKবি কে প্রেরণ করে
   • ক TIME_WAITরাজ্যে যায়
6. বি পায় ACK
   • বি CLOSEDস্টেটে যায় - অর্থাৎ সকেট টেবিল থেকে সরানো হয়

চভভ

সুতরাং সমাপ্তি - অর্থাত close()প্রথম কল - - সমাপ্তির সূচনা করে এমন পিয়ারটি TIME_WAITরাজ্যে শেষ হবে ।

TIME_WAITরাষ্ট্রটি কেন আমাদের বন্ধু তা বুঝতে , দয়া করে স্টিভেনস এট আল (পৃষ্ঠা 43) র তৃতীয় সংস্করণ "ইউনিক্স নেটওয়ার্ক প্রোগ্রামিং" এর ২.7 অংশটি পড়ুন।

তবে TIME_WAITকোনও সার্ভারে প্রচুর সকেট থাকা অবস্থায় এটি সমস্যা হতে পারে কারণ এটি শেষ পর্যন্ত নতুন সংযোগগুলি গ্রহণযোগ্যতা থেকে রোধ করতে পারে।

এই সমস্যাটি সমাধান করার জন্য, আমি অনেককে কল করার আগে টাইমআউট 0 এর সাথে SO_LINGER সকেট বিকল্প সেট করার পরামর্শ দিয়েছি close()। যাইহোক, এটি একটি খারাপ সমাধান কারণ এটি টিসিপি সংযোগটি ত্রুটির সাথে বন্ধ করে দেয়।

পরিবর্তে, আপনার অ্যাপ্লিকেশন প্রোটোকলটি ডিজাইন করুন যাতে সংযোগ সমাপ্তকরণ সর্বদা ক্লায়েন্টের পক্ষ থেকে শুরু করা হয়। যদি ক্লায়েন্ট সর্বদা জানে যে এটি কখন বাকী সমস্ত ডেটা পড়েছে তবে এটি সমাপ্তির ক্রমটি শুরু করতে পারে। উদাহরণস্বরূপ, কোনও ব্রাউজার Content-Lengthএইচটিটিপি শিরোনামের কাছ থেকে জানে যখন এটি সমস্ত ডেটা পড়ে এবং বন্ধটি শুরু করতে পারে। (আমি জানি যে HTTP 1.1 এ এটি সম্ভাব্য পুনঃব্যবহারের জন্য এটি কিছু সময়ের জন্য উন্মুক্ত রাখবে এবং তারপরে এটি বন্ধ করে দেবে))

সার্ভারটির যদি সংযোগটি বন্ধ করার দরকার হয় তবে অ্যাপ্লিকেশন প্রোটোকলটি ডিজাইন করুন যাতে সার্ভার ক্লায়েন্টকে কল করতে বলে close()।

সময়সীমা 0 সহ কখন SO_LINGER ব্যবহার করবেন

আবার, "ইউনিক্স নেটওয়ার্ক প্রোগ্রামিং" তৃতীয় সংস্করণ পৃষ্ঠা 202-203 অনুসারে, SO_LINGERকল করার আগে টাইমআউট 0 এর সাথে সেট করার close()ফলে স্বাভাবিক সমাপ্তির ক্রমটি শুরু না হওয়ার কারণ হবে ।

পরিবর্তে, পিয়ার এই বিকল্পটি সেট করে এবং কলিং close()একটি RST(সংযোগ পুনরায় সেট) প্রেরণ করবে যা একটি ত্রুটির অবস্থার ইঙ্গিত দেয় এবং অন্য প্রান্তে এটি কীভাবে উপলব্ধি করা হবে। আপনি সাধারণত "পিয়ারের মাধ্যমে সংযোগ পুনরায় সেট করার" মতো ত্রুটি দেখতে পাবেন।

সুতরাং, সাধারণ পরিস্থিতিতে SO_LINGERকল করার আগে টাইমআউট 0 দিয়ে সেট করা সত্যিই খারাপ ধারণা close()- এখন থেকে গর্ভপাত বন্ধ বলা - একটি সার্ভার অ্যাপ্লিকেশনটিতে।

যাইহোক, নির্দিষ্ট পরিস্থিতিতে পরোয়ানা যাইহোক এটি করে:

• যদি আপনার সার্ভার অ্যাপ্লিকেশনটির কোনও ক্লায়েন্ট খারাপ আচরণ করে (সময় শেষ হয়ে যায়, অবৈধ ডেটা ফেরত দেয়, ইত্যাদি) যদি কোনও গর্ভপাত বন্ধ হয়ে যায় CLOSE_WAITতবে TIME_WAITরাষ্ট্রটিতে আটকা পড়া বা শেষ হওয়া এড়াতে হবে ।
• যদি আপনাকে অবশ্যই আপনার সার্ভার অ্যাপ্লিকেশনটি পুনরায় চালু করতে হবে যার বর্তমানে হাজার হাজার ক্লায়েন্ট সংযোগ রয়েছে আপনি হাজার হাজার সার্ভার সকেটগুলিতে এড়াতে এই সকেট বিকল্পটি সেট করার কথা বিবেচনা করতে পারেন TIME_WAIT( close()সার্ভার শেষ থেকে কল করার সময় ) কারণ এটি সার্ভারকে নতুন ক্লায়েন্ট সংযোগের জন্য উপলব্ধ পোর্টগুলি পেতে বাধা দিতে পারে পুনরায় চালু হওয়ার পরে।
• উপরোক্ত গ্রন্থে পৃষ্ঠা 202 এটা বিশেষভাবে বলছে: "কিছু পরিস্থিতিতে এক ব্যর্থ ঘনিষ্ঠ পাঠাতে এই বৈশিষ্ট্য ব্যবহার পরোয়ানা আছে একটা উদাহরণ একটি RS-- 232 টার্মিনাল সার্ভার, যা চিরকাল স্তব্ধ পারে। CLOSE_WAITএকটি আটকে টার্মিনালে তথ্য প্রদান করা চেষ্টা পোর্ট, তবে আটকে থাকা পোর্টটি সঠিকভাবে পুনরায় সেট করতে হবে যদি এটি RSTমুলতুবি থাকা ডেটা বাতিল করতে পারে "

আমি এই দীর্ঘ নিবন্ধটি সুপারিশ করব যা আমার বিশ্বাস আপনার প্রশ্নের একটি খুব ভাল উত্তর দেয়।

Comments

TIME_WAITবন্ধু শুধুমাত্র যখন এটি কারণ সমস্যার শুরু হয় না: stackoverflow.com/questions/1803566/...

— Pacerier

সুতরাং আপনি যদি একটি ওয়েব সার্ভার লিখতে হয়? আপনি কীভাবে "ক্লায়েন্টকে একটি নিকটস্থার সূচনা করতে" বলতে পারেন?

— শান নীল

পছন্দ করেছেন তবে একটি ভাল লিখিত ক্লায়েন্ট / ব্রাউজার বন্ধ শুরু করবে। যদি ক্লায়েন্টটি ভাল আচরণ না করে তবে সৌভাগ্যক্রমে আমাদের সোনার বর্ণনাকারী এবং ক্ষুদ্র ক্ষুদ্র বন্দরগুলি বন্ধ হয়ে যায় না তা নিশ্চিত করার জন্য TIME_WAIT হত্যাকাণ্ড রয়েছে।

— এমজিডি

এটি একটি দুর্দান্ত উত্তর। ধন্যবাদ!

— জুরাজ মার্টিনকা

Answer 3

যখন অলসতা চালু থাকে তবে সময়সীমা শূন্য হয় টিসিপি স্ট্যাক সংযোগ বন্ধ করার আগে মুলতুবি থাকা ডেটা প্রেরণের জন্য অপেক্ষা করে না। এর কারণে ডেটাগুলি হারাতে পারে তবে এভাবে দীর্ঘায়িত করে আপনি এটিকে গ্রহণ করছেন এবং কৃপণভাবে বন্ধ হওয়ার পরিবর্তে সরাসরি সংযোগটি পুনরায় সেট করার অনুরোধ করছেন। এটি একটি সাধারণ আর এফআইএনের চেয়ে আরএসটি প্রেরণ করে।

EJP তার মন্তব্যের জন্য ধন্যবাদ, বিশদ জন্য এখানে দেখুন।

Comments

আমি এটা বুঝতে পেরেছি. যখন আমরা হার্ড রিসেট ব্যবহার করতে চাই তখন "বাস্তববাদী" উদাহরণের জন্য যা আমি জিজ্ঞাসা করি।

— ডিম্বা

আপনি যখনই কোনও সংযোগ বাতিল করতে চান; সুতরাং যদি আপনার প্রোটোকলটি বৈধতা ব্যর্থ হয় এবং হঠাৎ করে আপনি যদি কোনও ক্লায়েন্টের কাছে আবর্জনার কথা বলছেন তবে আপনি কোনও আরএসটি ইত্যাদির সাথে সংযোগটি বাতিল করে দিতে পারেন

— লেন হোলগেট

আপনি দীর্ঘমেয়াদির সাথে শূন্যের দীর্ঘ সময়সীমা বিভ্রান্ত করছেন। লম্বা বন্ধ মানে বন্ধ () অবরুদ্ধ হয় না। ইতিবাচক সময়সীমা নিয়ে দীর্ঘসূত্রতা মানে সময়সীমা অবধি বন্ধ () ব্লক। একটি শূন্য সময়সীমা নিয়ে দীর্ঘসূত্রতা আরএসটি সৃষ্টি করে এবং এটিই প্রশ্নটি।

— লার্নের মারকুইস

হ্যাঁ, আপনি ঠিক বলেছেন। আমি আমার পরিভাষা সংশোধন করার জন্য উত্তরটি সামঞ্জস্য করব।

— লেন হলগেট

Answer 4

আপনি আপনার কোডটিতে থাকা লম্বা সুরক্ষিতভাবে মুছে ফেলতে পারেন বা আপনার অ্যাপ্লিকেশনটির ধরণের উপর নির্ভর করে না: এটি কি একজন "ক্লায়েন্ট" (টিসিপি সংযোগগুলি খোলার এবং প্রথমে সক্রিয়ভাবে এটি বন্ধ করে দেওয়া) বা এটি একটি "সার্ভার" (কোনও টিসিপি খোলা শুনে এবং অন্য পক্ষটি বন্ধ করার পরে এটি বন্ধ করা)?

যদি আপনার অ্যাপ্লিকেশনটিতে "ক্লায়েন্ট" এর স্বাদ থাকে (প্রথমে বন্ধ হচ্ছে) এবং আপনি বিভিন্ন সার্ভারের সাথে প্রচুর সংযোগ শুরু করেন এবং বন্ধ করেন (যেমন আপনার অ্যাপ্লিকেশনটি যখন একটি বিশাল সংখ্যক সার্ভারের পুনঃব্যবহারের তদারকি করে এমন একটি মনিটরিং অ্যাপ হয়) আপনার অ্যাপ্লিকেশনটি আপনার সমস্ত ক্লায়েন্ট সংযোগগুলি TIME_WAIT রাজ্যে আটকে থাকার সমস্যা রয়েছে। তারপরে, আমি সময়সীমাটি ডিফল্টের চেয়ে কম মানকে ছোট করার জন্য সুপারিশ করব তবুও নিখরচায়ভাবে শাটডাউন করতে তবে ক্লায়েন্ট সংযোগের সংস্থানগুলি পূর্বে মুক্ত করে। আমি টাইমআউট 0 তে সেট করবো না, কারণ 0 টি FIN- র সাথে দুর্দান্তভাবে শাটডাউন করে না তবে আরএসটি দিয়ে গর্ভবতী হয়।

যদি আপনার অ্যাপ্লিকেশনটিতে একটি "ক্লায়েন্ট" এর স্বাদ থাকে এবং একই সার্ভার থেকে প্রচুর পরিমাণে ছোট ছোট ফাইল আনতে হয় তবে আপনার ফাইলের জন্য একটি নতুন টিসিপি সংযোগ শুরু করা উচিত নয় এবং TIME_WAIT- এ প্রচুর পরিমাণে ক্লায়েন্ট সংযোগ স্থাপন করা উচিত, তবে সংযোগটি উন্মুক্ত রাখুন এবং একই সংযোগে সমস্ত ডেটা আনুন। দীর্ঘতর বিকল্প অপসারণ করতে হবে এবং অপসারণ করা উচিত।

যদি আপনার অ্যাপ্লিকেশনটি কোনও "সার্ভার" হয় (পিয়ারের ঘনিষ্ঠ হিসাবে প্রতিক্রিয়া হিসাবে দ্বিতীয়টি বন্ধ হয়), নিকটে () আপনার সংযোগটি কর্কশভাবে বন্ধ হয়ে যায় এবং আপনি TIME_WAIT অবস্থায় প্রবেশ না করায় সংস্থানগুলি মুক্ত হয়ে যায়। লম্বা ব্যবহার করা উচিত নয়। তবে যদি আপনার সেভার অ্যাপ্লিকেশনটিতে একটি দীর্ঘকাল ধরে নিষ্ক্রিয় খোলা সংযোগগুলি সনাক্তকরণের জন্য একটি তদারকি প্রক্রিয়া থাকে ("দীর্ঘ" সংজ্ঞায়িত করতে হয়) আপনি এই পক্ষ থেকে এই নিষ্ক্রিয় সংযোগটি বন্ধ করতে পারেন - এটিকে ত্রুটি হ্যান্ডলিং হিসাবে দেখুন - একটি গর্ভপাতের শাটডাউন দিয়ে। এটি দীর্ঘায়িত সময়সীমা ০. এ সেট করে সম্পন্ন করা হয় (বন্ধ করুন) তারপরে ক্লায়েন্টকে একটি আরএসটি প্রেরণ করবে, তাকে বলবে যে আপনি রাগান :-)

Answer 5

সার্ভারগুলিতে, খারাপ আচরণের ক্লায়েন্টদের সংযোগ বিচ্ছিন্ন করার RSTপরিবর্তে আপনি প্রেরণ করতে পছন্দ করতে পারেন FIN। সার্ভারে সকেট অনুযায়ী এই স্কিপগুলি FIN-WAITঅনুসরণ করে TIME-WAIT, যা সার্ভারের সংস্থানগুলি হ্রাস করা থেকে রক্ষা করে এবং তাই এই ধরণের অস্বীকৃত-পরিষেবা আক্রমণ থেকে রক্ষা করে।

Answer 6

আমি ম্যাক্সিমের পর্যবেক্ষণ পছন্দ করি যে ডস আক্রমণগুলি সার্ভারের সংস্থানগুলি নিঃশেষ করতে পারে। এটি আসলে দূষিত বিরোধী ছাড়াও ঘটে।

কিছু সার্ভারকে 'অজান্তেই ডস আক্রমণ' মোকাবেলা করতে হয় যা ক্লায়েন্ট অ্যাপ্লিকেশনটিতে সংযোগ ফাঁসের সাথে একটি বাগ থাকে, যেখানে তারা আপনার সার্ভারে প্রেরিত প্রতিটি নতুন কমান্ডের জন্য একটি নতুন সংযোগ তৈরি করে রাখে। এবং তারপরে সম্ভবত তারা সংযোগগুলি বন্ধ করে যদি তারা জিসি চাপে চাপ দেয়, অথবা সম্ভবত সংযোগগুলি শেষ হয়ে যায়।

আর একটি দৃশ্যটি হ'ল যখন 'সমস্ত ক্লায়েন্টের একই টিসিপি ঠিকানা থাকে' পরিস্থিতি। তারপরে ক্লায়েন্ট সংযোগগুলি কেবল বন্দর সংখ্যা দ্বারা পৃথকযোগ্য (যদি তারা কোনও একক সার্ভারের সাথে সংযুক্ত থাকে)। এবং যদি ক্লায়েন্টরা কোনও কারণে দ্রুত সাইক্লিং ওপেনিং / ক্লোজিং সংযোগগুলি শুরু করে তবে তারা (ক্লায়েন্ট অ্যাডার + পোর্ট, সার্ভার আইপি + পোর্ট) টিউপল স্পেসটি নিঃশেষ করতে পারে।

সুতরাং আমি মনে করি যে সার্ভারগুলি TIME_WAIT রাজ্যে একটি উচ্চ সংখ্যক সকেট দেখলে লিনজার-জিরো কৌশলটিতে স্যুইচ করার পরামর্শ দেওয়া যেতে পারে - যদিও এটি ক্লায়েন্টের আচরণটি স্থির করে না, এটি প্রভাবকে হ্রাস করতে পারে।

Answer 7

সার্ভারে শোনার সকেট অবিলম্বে সকেটে আবার বাঁধাইয়ের অ্যাক্সেস পেতে এবং যে কোনও ক্লায়েন্টের সংযোগ এখনও শেষ হয়ে যায়নি তা পুনরায় সেট করতে সময় 0 সহ অলস ব্যবহার করতে পারে। TIME_WAIT এমন এক জিনিস যা কেবল তখনই আকর্ষণীয় যখন আপনার একটি মাল্টি-পাথ নেটওয়ার্ক থাকে এবং মিস-অর্ডারযুক্ত প্যাকেটগুলি শেষ করতে পারে বা অন্যথায় বিজোড় নেটওয়ার্ক প্যাকেটের অর্ডার / আগমনের সময় নির্ধারণের সাথে কাজ করে।