এর চেয়ে ভাল কি? প্রচুর ছোট টিসিপি প্যাকেট, না একটি দীর্ঘ? [বন্ধ]

Question

আমি একটি গেম তৈরি করছি তার জন্য আমি একটি সার্ভার থেকে এবং বেশ কিছুটা ডেটা প্রেরণ করছি।

আমি বর্তমানে অবস্থানের ডেটা প্রেরণ করি:

sendToClient((("UID:" + cl.uid +";x:" + cl.x)));
sendToClient((("UID:" + cl.uid +";y:" + cl.y)));
sendToClient((("UID:" + cl.uid +";z:" + cl.z)));

স্পষ্টতই এটি প্রাসঙ্গিক এক্স, ওয়াই এবং জেড মান প্রেরণ করছে।

এভাবে ডেটা প্রেরণ করা কি আরও দক্ষ হবে?

sendToClient((("UID:" + cl.uid +"|" + cl.x + "|" + cl.y + "|" + cl.z)));

Comments

আমার সীমিত অভিজ্ঞতায় প্যাকেট হ্রাস সাধারণত 5% এর নীচে থাকে।

— মুচাহো

সেন্ডটোক্লিয়েন্ট আসলে প্যাকেট প্রেরণ করে? যদি তা হয় তবে কীভাবে আপনি এটি করতে পেরেছেন?

— ব্যবহারকারী 253751

@ মুচাহো আমি নিজেই বা কোনও কিছুই এটি পরিমাপ করিনি, তবে আমি অবাক হয়েছি টিসিপি এটি প্রান্তের চারপাশে মোটামুটি। আমি আরও 0.5% বা তারও কম এর মতো কিছু আশা করতাম।

— Panzercrisis

@ পানজারক্রিসিস আমাকে অবশ্যই আপনার সাথে একমত হতে হবে। আমি ব্যক্তিগতভাবে অনুভব করি যে 5% ক্ষতি অগ্রহণযোগ্য হবে। আপনি যদি আমার পাঠানোর মতো কিছু সম্পর্কে ভাবেন, বলুন, একটি নতুন জাহাজ গেমটিতে ছড়িয়েছে, এমনকি সেই প্যাকেটটি প্রাপ্ত না হওয়ার 1% সম্ভাবনা বিপদজনক হবে, কারণ আমি অদৃশ্য জাহাজ পাব।

— joehot200

বলছি না, আমি 5% একটি উপরের বাউন্ড হিসাবে বোঝা :) বাস্তবে এটি অনেক ভাল, অন্যান্য মন্তব্য দ্বারা উল্লিখিত হিসাবে।

— মুচাহো

Answer 1

টিসিপি বিভাগে অনেকগুলি ওভারহেড থাকে। আপনি যখন একটি টিসিপি প্যাকেট সহ 10 বাইট বার্তা প্রেরণ করেন আপনি আসলে:

• আইপিভি 4 হেডারের 16 বাইট (আইপিভি 6 সাধারণ হয়ে উঠলে 40 বাইটে বাড়বে)
• টিসিপি হেডারের 16 বাইট
• পেওলোডের 10 বাইট
• ডেটা-লিঙ্ক এবং ব্যবহৃত শারীরিক স্তর প্রোটোকলগুলির জন্য অতিরিক্ত ওভারহেড

10 বাইট ডেটা পরিবহনের জন্য 42 বাইট ট্র্যাফিকের ফলাফল। সুতরাং আপনি আপনার উপলব্ধ ব্যান্ডউইথের 25% এরও কম ব্যবহার করেন। এবং এটি এখনও ওভারহেডের জন্য অ্যাকাউন্ট করে না যা ইথারনেট বা পিপিপিওইয়ের মতো নিম্ন-স্তরের প্রোটোকলগুলি গ্রাস করে (তবে এগুলি অনুমান করা শক্ত কারণ অনেকগুলি বিকল্প রয়েছে)।

এছাড়াও, অনেকগুলি ছোট প্যাকেটগুলি রাউটার, ফায়ারওয়ালস, সুইচ এবং অন্যান্য নেটওয়ার্ক অবকাঠামোগত সরঞ্জামগুলিতে আরও চাপ সৃষ্টি করে, তাই আপনি যখন, আপনার পরিষেবা সরবরাহকারী এবং আপনার ব্যবহারকারীরা উচ্চমানের হার্ডওয়্যারে বিনিয়োগ করবেন না, তখন এটি অন্য কোনও বাধা হয়ে উঠতে পারে।

সেই কারণে আপনার একবারে একটি টিসিপি বিভাগে উপলভ্য সমস্ত ডেটা প্রেরণ করার চেষ্টা করা উচিত।

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

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

Comments

টিসিপি প্যাকেটের ক্ষয় পুনরুদ্ধার করার উপায় থেকে ওভারহেড কি প্যাকেটের আকারের উপর নির্ভর করে কোনও কিছুর জন্য পৃথক হতে পারে?

— পাঞ্জারিসিস

@ পানজারক্রিসিস কেবলমাত্র এতদূর পর্যন্ত একটি বৃহত্তর প্যাকেট রয়েছে যার জন্য রাগ করা দরকার।

— ফিলিপ

আমি লক্ষ্য করেছি যে যা OS প্রায় অবশ্যই Nagles অ্যালগরিদম প্রয়োগ করা হবে en.wikipedia.org/wiki/Nagle%27s_algorithm , বহির্গামী ডেটাতে এটি ব্যাপার যদি অ্যাপ্লিকেশানে আপনি পৃথক লিখেছেন করে না মানে বা মেশা তাদের এটা তাদের একত্রিত করা হবে আসলে টিসিপি দিয়ে তাদের পাস করার আগে।

— মান

@ ভ্যালালি বেশিরভাগ সকেট এপিআই আমি প্রতিটি সকেটের জন্য নিগল সক্রিয় বা নিষ্ক্রিয় করার অনুমতি ব্যবহার করেছি used বেশিরভাগ গেমের জন্য আমি এটিকে নিষ্ক্রিয় করার পরামর্শ দিচ্ছি, কারণ ব্যান্ডউইথ সংরক্ষণের তুলনায় স্বল্প ল্যাটেন্সিটি সাধারণত বেশি গুরুত্বপূর্ণ।

— ফিলিপ

নাগলের অ্যালগরিদম এক, তবে কেবলমাত্র প্রেরণকারী পক্ষের ডেটা বাফার হতে পারে না। নেই কোন উপায় নির্ভরযোগ্যভাবে বল ডেটা পাঠায় করতে। এছাড়াও, এনএফ, রাউটার, প্রক্সি বা এমনকি প্রাপ্তির দিক থেকে ডেটা প্রেরণের পরে যে কোনও জায়গায় বাফারিং / টুকরো টুকরোগুলি ঘটতে পারে। টিসিপি আপনি যে আকারে এবং সময় নেওয়ার সময় ডেটা পাবেন তার কোনও গ্যারান্টি দেয় না, কেবলমাত্র এটি কার্যকরভাবে এবং নির্ভরযোগ্যভাবে আসবে। আপনার যদি আকারের গ্যারান্টি দরকার হয় তবে ইউডিপি ব্যবহার করুন। টিসিপি বুঝতে সহজ বলে মনে হচ্ছে এটিকে সমস্ত সমস্যার সর্বোত্তম হাতিয়ার হিসাবে তৈরি করে না!

— পান্ডা পাইজামা

Answer 2

একটি বড় এক (কারণের মধ্যে) ভাল।

যেমনটি আপনি বলেছিলেন, প্যাকেটের ক্ষতি হওয়াই প্রধান কারণ। প্যাকেটগুলি সাধারণত একটি নির্দিষ্ট আকারের ফ্রেমে প্রেরণ করা হয়, তাই 10 টি ছোট 10 টির সাথে 10 ফ্রেমের চেয়ে একটি বড় বার্তা সহ একটি ফ্রেম নেওয়া ভাল।

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

Comments

আমি নাগলের অ্যালগরিদম শুনেছি, তবে এটি অক্ষম করা কি আসলেই ভাল ধারণা? আমি ঠিক একটি স্ট্যাকওভারফ্লো উত্তর থেকে এসেছি যেখানে কেউ বলেছে যে এটি আরও দক্ষ (এবং স্পষ্ট কারণে আমি দক্ষতা চাই)।

— joehot200

@ joehot200 এর একমাত্র সঠিক উত্তরটি "এটি নির্ভর করে"। হ্যাঁ, প্রচুর ডেটা প্রেরণের জন্য এটি আরও দক্ষ, তবে গেমগুলির যে প্রবণতা রয়েছে তা রিয়েল-টাইম স্ট্রিমিংয়ের জন্য নয়।

— ডি-সাইড

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

— সুপারক্যাট

... একটি "স্যানিটি টাইমার" লাথি মেরে পরিস্থিতি সমাধান করে (এক সেকেন্ডের আদেশে)।

— সুপারক্যাট

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

— পান্ডা পায়জামা

Answer 3

পূর্ববর্তী সমস্ত উত্তর ভুল। অনুশীলনে, আপনি একটি দীর্ঘ send()কল বা কয়েকটি ছোট send()কল ইস্যু করে তা বিবেচনা করে না ।

ফিলিপ যেমন বলেছে, টিসিপি বিভাগে কিছুটা ওভারহেড রয়েছে তবে অ্যাপ্লিকেশন প্রোগ্রামার হিসাবে, বিভাগগুলি কীভাবে উত্পন্ন হয় তার উপর আপনার কোনও নিয়ন্ত্রণ নেই। সহজ শর্তে:

একটি send()কল অগত্যা একটি টিসিপি বিভাগে অনুবাদ করে না।

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

এর বেশ কয়েকটি প্রভাব রয়েছে তবে সবচেয়ে গুরুত্বপূর্ণটি হ'ল:

একটি send()কল, বা একটি টিসিপি বিভাগ recv()অবশ্যই অপর প্রান্তে একটি সফল কলটিতে অনুবাদ করে না

এর পিছনে যুক্তিটি হ'ল টিসিপি হ'ল একটি স্ট্রিম প্রোটোকল। টিসিপি আপনার ডেটাগুলিকে বাইটের দীর্ঘ স্ট্রিম হিসাবে বিবেচনা করে এবং "প্যাকেটগুলি" সম্পর্কে কোনও ধারণা নেই। আপনার সাথে send()সেই প্রবাহে বাইট যুক্ত করুন এবং সাথেrecv() আপনি অন্য দিকে বন্ধ বাইট পেতে। টিসিপি আক্রমণাত্মকভাবে আপনার ডেটাটি অন্য দিকে যত তাড়াতাড়ি দ্রুত অন্যদিকে পৌঁছেছে তা নিশ্চিত করার জন্য আপনার ডেটাটি যথাযথ দেখায় এবং এটি বিভক্ত করবে।

আপনি যদি টিসিপি দিয়ে "প্যাকেট" প্রেরণ এবং গ্রহণ করতে চান, আপনাকে প্যাকেট শুরুর চিহ্নিতকারী, দৈর্ঘ্যের চিহ্নিতকারী এবং এগুলি প্রয়োগ করতে হবে। পরিবর্তে ইউডিপির মতো কোনও বার্তা ওরিয়েন্টেড প্রোটোকল ব্যবহার সম্পর্কে কীভাবে? ইউডিপি send()একটি প্রেরিত ডেটাগ্রামে এবং একটি কলকে একটি কল অনুবাদ করার গ্যারান্টি দেয় recv()!

আপনার সমস্ত কিছু যখন টিসিপি হয় তখন সমস্ত কিছুই স্রোতের মতো দেখায়

Comments

বার্তাটির দৈর্ঘ্যের সাথে প্রতিটি বার্তা উপসর্গ করা এত জটিল নয়।

— ysdx

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

— লার্স ভিক্লুন্ড

এটি সম্পূর্ণ ওএস বা এমনকি গ্রন্থাগার নির্দিষ্ট। এছাড়াও আপনি চান - আপনার নিয়ন্ত্রণ অনেক আছে। এটি সত্য যে আপনার সম্পূর্ণ নিয়ন্ত্রণ নেই, টিসিপিকে সর্বদা দুটি বার্তা একত্রিত করার অনুমতি দেওয়া হয় বা এটি এমটিইউয়ের সাথে মানানসই না হলে একটি বিভক্ত করতে পারে, তবে আপনি এখনও এটি সঠিক দিকে ইঙ্গিত করতে পারেন। বিভিন্ন কনফিগার সেটিংস সেট করা, ম্যানুয়াল প্রেরণে 1 সেকেন্ড বাদে বার্তা পাঠানো বা ডেটা বাফার করা এবং এটি একটি শটে প্রেরণ করুন।

— ডোরাস

@ আইএসডিএক্স: না, প্রেরণকারী দিকে নয়, তবে হ্যাঁ গ্রহণের পক্ষে। যেহেতু আপনি কোথা থেকে ডেটা পাবেন তার কোনও গ্যারান্টি নেই recv(), সুতরাং এর ক্ষতিপূরণ দেওয়ার জন্য আপনার নিজের বাফারিং করতে হবে। আমি ইউডিপিতে নির্ভরযোগ্যতা বাস্তবায়নের মতো একই অসুবিধায় এটিকে স্থান দেব।

— পান্ডা পাইজামা 10

@ পেগান্ডা পাজামা: প্রাপ্তি পক্ষের একটি নিখুঁত বাস্তবায়ন হ'ল: while(1) { uint16_t size; read(sock, &size, sizeof(size)); size = ntoh(size); char message[size]; read(sock, buffer, size); handleMessage(message); }(ত্রুটি পরিচালনা করা বাদ দেওয়া এবং আংশিকভাবে বংশবৃদ্ধির জন্য পড়ে তবে এটি খুব বেশি পরিবর্তন করে না)। এটি করা একটি selectআরও জটিলতা যুক্ত করে না এবং আপনি যদি টিসিপি ব্যবহার করেন তবে সম্ভবত আপনাকে যেভাবেই আংশিক বার্তাগুলি বাফার করতে হবে। ইউডিপির উপর দৃ reli় নির্ভরযোগ্যতা প্রয়োগ করা এর চেয়ে জটিল।

— ysdx

Answer 4

অনেক ছোট প্যাকেজ ঠিক আছে। আসলে, আপনি যদি টিসিপি ওভারহেড সম্পর্কে চিন্তিত হন তবে কেবল একটি sertোকানbufferstream এমন যা 1500 টি পর্যন্ত চর সংগ্রহ করে (বা আপনার টিসিপি এমটিইউগুলি যা-ই হোক, এটি গতিবেগের জন্য অনুরোধ করা ভাল) এবং সমস্যাটি এক জায়গায় সমাধান করুন। এটি করা আপনার অতিরিক্ত প্যাকেজটির জন্য 40 ডলার বাইটের ওভারহেডকে বাঁচায় যা আপনি অন্যথায় তৈরি করেছিলেন।

এটি বলেছে যে, কম ডেটা প্রেরণ করা আরও ভাল এবং সেখানে বৃহত্তর অবজেক্ট তৈরি করা সহায়তা করে। অবশ্যই পাঠানোর "UID:10|1|2|3চেয়ে এটি প্রেরণ করা আরও ছোট UID:10;x:1UID:10;y:2UID:10;z:3। প্রকৃতপক্ষে, এই মুহুর্তে আপনার চাকাটি পুনরায় উদ্ভাবন করা উচিত নয়, প্রোটোবুফের মতো একটি লাইব্রেরি ব্যবহার করুন যা এর ফলে ডেটা হ্রাস করতে পারে 10 বাইট স্ট্রিং বা তারও কম।

কেবল আপনার জিনিসটি ভুলে যাওয়া উচিত নয় Flushপ্রাসঙ্গিক অবস্থানগুলিতে আপনার স্ট্রিমে একটি কমান্ড সন্নিবেশ করা , কারণ আপনি আপনার স্ট্রিমে ডেটা যুক্ত করা বন্ধ করার সাথে সাথে এটি কিছু প্রেরণের আগে এটি অসীম অপেক্ষা করতে পারে। সত্যই সমস্যাযুক্ত যখন আপনার ক্লায়েন্ট সেই ডেটার জন্য অপেক্ষা করছে এবং ক্লায়েন্ট পরবর্তী আদেশটি না পাঠা পর্যন্ত আপনার বিভাজন নতুন কিছু প্রেরণ করবে না।

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

নীচের লাইন: যথাসম্ভব অল্প ডেটা প্রেরণ করুন, বড় প্যাকেজগুলি প্রেরণ করুন এবং এটি করার জন্য আপনার নিজের নিম্ন স্তরের পদ্ধতিগুলি লিখবেন না, তবে সুপরিচিত গ্রন্থাগার এবং পদ্ধতিগুলির উপর নির্ভর করুনbufferstream ভারী উত্তোলন পরিচালনা করার জন্য ।

Comments

আসলে এই জাতীয় জিনিসগুলির জন্য এটি নিজের নিজস্ব রোল করা সহজ। অন্য ব্যক্তির লাইব্রেরি ব্যবহারের জন্য 50 পৃষ্ঠার ডকুমেন্টেশনের মধ্য দিয়ে যাওয়ার চেয়ে অনেক সহজ এবং তারপরেও আপনি তাদের বাগ এবং গটচগুলি সামলাতে পারেন।

— পেসারিয়ার

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

— ডোরাস

Answer 5

যদিও নিজেকে নেটওয়ার্ক প্রোগ্রামিংয়ের নিওফাইফ হওয়া সত্ত্বেও আমি আমার কিছু সীমিত অভিজ্ঞতা শেয়ার করতে চাই:

• টিসিপি একটি ওভারহেড বোঝায় - আপনাকে অবশ্যই সম্পর্কিত পরিসংখ্যান পরিমাপ করতে হবে
• ইউডিপি হ'ল ডি ফ্যাকটোনেটওয়র্কযুক্ত গেমিং পরিস্থিতিগুলির জন্য সলিউশন, তবে প্যাকেটগুলি হারিয়ে যাওয়া বা অর্ডার থেকে বেরিয়ে যাওয়ার জন্য অ্যাকাউন্টে অ্যাকাউন্টিং করার জন্য যে সমস্ত বাস্তবায়নই এর উপর নির্ভর করে সেগুলি অতিরিক্ত, সিপিইউ-সাইড অ্যালগরিদম রয়েছে

পরিমাপ সম্পর্কিত, যে মেট্রিকগুলি বিবেচনা করা উচিত তা হ'ল:

• গড় এবং তাত্ক্ষণিক মাধ্যমে আউটপুট
• গড় , সর্বোচ্চ এবং সর্বনিম্ন শেষ থেকে শেষের বিলম্ব এই জাতীয় মেট্রিকগুলির জন্য, বিদ্যমান সরঞ্জামগুলি একটি দ্রুত সমাধান সরবরাহ করতে পারে। উদাহরণস্বরূপ: আইপিফার ( https://iperf.fr/ ), ডি-আইটিজি ( http://traffic.comics.unina.it/software/ITG/ )। টিসিপি টিউন করার ক্ষেত্রে একটি তারিখযুক্ত তবুও দরকারী ডকুমেন্টটি http://dst.lbl.gov/publications/usenix-login.pdf এ পাওয়া যাবে ।

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

• নির্ভরযোগ্য ইউডিপি http://sourceforge.net/projects/rudp/
• ENET http://enet.bespin.org/ (এটি আরও ভাল পারফরম্যান্স পাওয়া যায় এমন টিসিপি বার্তা হ্যান্ডলিং প্রতিস্থাপন করতে পারে)
• ইউডিটি (ইউডিপি-ভিত্তিক ডেটা ট্রান্সফার প্রোটোকল http://udt.sourceforge.net/ ) যা এইচপি কম্পিউটিং পরিস্থিতিতে দৃm় হয়েছে বলে মনে হয়

উপসংহার: যেহেতু একটি ইউডিপি বাস্তবায়ন টিসিপি এক (3x এর ফ্যাক্টর দ্বারা) ছাড়িয়ে যেতে পারে, আপনি একবার নিজের পরিস্থিতি ইউডিপি বান্ধব হিসাবে চিহ্নিত করে ফেললে তা বিবেচনা করা বুদ্ধিমান হতে পারে। সতর্কাবস্থা! ইউডিপির উপরে পুরো টিসিপি স্ট্যাক প্রয়োগ করা সর্বদা একটি খারাপ ধারণা।

Comments

আমি ইউডিপি ব্যবহার করছিলাম। আমি কেবল টিসিপি-তে স্যুইচ করেছি। ক্লায়েন্টের প্রয়োজনীয় ডেটাগুলির জন্য ইউডিপির প্যাকেট ক্ষয়টি কেবল অগ্রহণযোগ্য। আমি ইউডিপির মাধ্যমে মুভমেন্ট ডেটা প্রেরণ করতে পারি।

— joehot200

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

— teodron