উত্তর:
বুস্ট.এসিও হ'ল সি ++ গ্রন্থাগার যা নেটওয়ার্কিংয়ে ফোকাস দিয়ে শুরু হয়েছিল তবে এর অ্যাসিনক্রোনাস আই / ও ক্ষমতা অন্যান্য সংস্থানগুলিতে প্রসারিত হয়েছে। অতিরিক্তভাবে, বুস্ট.অ্যাসিও বুস্ট লাইব্রেরির অংশ হওয়ার সাথে সাথে অন্যান্য বুস্ট লাইব্রেরির সাথে সদৃশতা রোধ করতে এর সুযোগটি কিছুটা সঙ্কুচিত করা হয়েছে। উদাহরণস্বরূপ, বুস্ট.অ্যাসিও থ্রেড বিমূর্ততা সরবরাহ করবে না, যেমন বুস্ট.থ্রেড ইতিমধ্যে একটি সরবরাহ করে।
অন্যদিকে, লাইবভ হ'ল সি লাইব্রেরি যা নোড.জেএস এর প্ল্যাটফর্ম স্তর হিসাবে নকশাকৃত । এর জন্য একটি বিমূর্ততা উপলব্ধ IOCP Windows এ, kqueue MacOS, এবং epoll লিনাক্স। অতিরিক্তভাবে, দেখে মনে হচ্ছে এর বিস্তৃতি এবং কার্যকারিতা যেমন থ্রেড, থ্রেডপুল এবং আন্তঃ থ্রেড যোগাযোগ অন্তর্ভুক্ত করার জন্য এর ব্যাপ্তি কিছুটা বেড়েছে।
তাদের মূল স্থানে, প্রতিটি লাইব্রেরি ইভেন্ট ইভেন্ট লুপ এবং অ্যাসিঙ্ক্রোনাস I / O ক্ষমতা সরবরাহ করে। তাদের কয়েকটি প্রাথমিক বৈশিষ্ট্যগুলির জন্য ওভারল্যাপ রয়েছে যেমন টাইমার, সকেট এবং অ্যাসিনক্রোনাস অপারেশন। লিবুভের বিস্তৃত সুযোগ রয়েছে এবং এটি অতিরিক্ত কার্যকারিতা সরবরাহ করে যেমন থ্রেড এবং সিঙ্ক্রোনাইজেশন বিমূর্ততা, সিঙ্ক্রোনাস এবং অ্যাসিনক্রোনাস ফাইল সিস্টেম অপারেশন, প্রক্রিয়া পরিচালনা ইত্যাদি। বিপরীতে, বুস্ট.অ্যাসিওর মূল নেটওয়ার্কিং ফোকাস পৃষ্ঠসমূহ, কারণ এটি নেটওয়ার্ক সম্পর্কিত আরও সমৃদ্ধ সেট সরবরাহ করে আইসিএমপি, এসএসএল, সিঙ্ক্রোনাস ব্লকিং এবং নন-ব্লকিং অপারেশন এবং সাধারণ কাজের জন্য উচ্চ-স্তরের ক্রিয়াকলাপগুলির মতো ক্ষমতাগুলি, যেমন একটি নিউলাইন না পাওয়া পর্যন্ত একটি স্ট্রিম থেকে পড়া।
এখানে কয়েকটি প্রধান বৈশিষ্ট্যের সংক্ষিপ্ত পাশাপাশি পাশাপাশি তুলনা করা হচ্ছে। যেহেতু বুস্ট.অ্যাসিও ব্যবহারকারী বিকাশকারীদের প্রায়শই অন্যান্য বুস্ট লাইব্রেরি উপলব্ধ থাকে তাই আমি অতিরিক্ত বুস্ট গ্রন্থাগারগুলি বিবেচনা করার সিদ্ধান্ত নিয়েছি যদি সেগুলি সরাসরি সরবরাহ করা হয় বা বাস্তবায়নের জন্য তুচ্ছ হয়।
লিবুভ বুস্ট ইভেন্ট লুপ: হ্যাঁ আসিও থ্রেডপুল: হ্যাঁ Asio + থ্রেডস থ্রেডিং: থ্রেডস: হ্যাঁ থ্রেডস সিঙ্ক্রোনাইজেশন: হ্যাঁ থ্রেডস ফাইল সিস্টেম অপারেশন: সিঙ্ক্রোনাস: হ্যাঁ ফাইলসিস্টেম অ্যাসিঙ্ক্রোনাস: হ্যাঁ এসিও + ফাইল সিস্টেম m টাইমার: হ্যাঁ আসিও ছড়িয়ে ছিটিয়ে / জড়ো I / O [1] : আসিও নয় নেটওয়ার্ক ব্যবস্থা: আইসিএমপি: আসিও নেই ডিএনএস রেজোলিউশন: অ্যাসিঙ্ক-কেবল অ্যাসিও এসএসএল: কোনও অসিও নয় টিসিপি: অ্যাসিঙ্ক-কেবল অসিও ইউডিপি: অ্যাসিঙ্ক-কেবল অসিও সংকেত: হ্যান্ডলিং: হ্যাঁ আসিও প্রেরণ: হ্যাঁ না আইপিসি: ইউনিক্স ডোমেন সকেট: হ্যাঁ আসিও উইন্ডোজ নামক পাইপ: হ্যাঁ Asio প্রক্রিয়া ব্যবস্থাপনা: বিচ্ছিন্নকরণ: হ্যাঁ প্রক্রিয়া আই / ও পাইপ: হ্যাঁ প্রক্রিয়া স্প্যানিং: হ্যাঁ প্রক্রিয়া সিস্টেম ক্যোয়ারী: সিপিইউ: হ্যাঁ না নেটওয়ার্ক ইন্টারফেস: হ্যাঁ না সিরিয়াল পোর্ট: না হ্যাঁ টিটিওয়াই: হ্যাঁ না ভাগ করা লাইব্রেরি লোড হচ্ছে: হ্যাঁ এক্সটেনশন [2]
1. বিক্ষিপ্ত / জড়ো ইনপুট / আউটপুট ।
2. বুস্ট. এক্সটেনশনটি বুস্টে পর্যালোচনার জন্য কখনই জমা দেওয়া হয়নি। এখানে যেমন উল্লেখ করা হয়েছে , লেখক এটিকে সম্পূর্ণ বলে মনে করেন।
লিবুভ এবং বুস্ট উভয়ই ইভেন্ট লুপ সরবরাহ করার সময়, উভয়ের মধ্যে কিছু সূক্ষ্ম পার্থক্য রয়েছে:
uv_default_loop()নতুন লুপ ( uv_loop_new()) তৈরি করার পরিবর্তে ডিফল্ট লুপ ( ) ব্যবহার করার সময় যত্ন নেওয়া দরকার , কারণ অন্য কোনও উপাদান ডিফল্ট লুপটি চালাচ্ছে।io_serviceতাদের নিজস্ব লুপ যে run একাধিক থ্রেড জন্য অনুমতি আছে। এই বুস্টকে সমর্থন করার জন্য.অ্যাসিও কিছু পারফরম্যান্সের ব্যয়ে অভ্যন্তরীণ লকিং সম্পাদন করে । বুস্ট.এসিওর পুনর্বিবেচনার ইতিহাস নির্দেশ করে যে লকিং কমাতে বেশ কয়েকটি কার্যকারিতা উন্নতি হয়েছে।uv_queue_work। থ্রেডপুলের আকার পরিবেশ পরিবর্তনশীলের মাধ্যমে কনফিগারযোগ্য UV_THREADPOOL_SIZE। কাজটি ইভেন্ট লুপের বাইরে এবং থ্রেডপুলের মধ্যেই কার্যকর করা হবে। কাজটি শেষ হয়ে গেলে, ইভেন্ট লুপের মধ্যে চালানোর জন্য সমাপ্তি হ্যান্ডলারটি সারিবদ্ধ করা হবে।io_serviceফলে সহজেই এটি হিসাবে কাজ করতে পারে । এটি থ্রেড পরিচালনা এবং ব্যবহারকারীর প্রতি আচরণের দায়িত্ব রাখে, যেমন এই উদাহরণটিতে দেখা যায় ।io_servicerunEAGAINবা EWOULDBLOCK।killতার uv_signal_tপ্রকার এবং uv_signal_*ক্রিয়াকলাপগুলির সাথে বিমূর্ততা এবং সংকেত হ্যান্ডলিং সরবরাহ করে।kill, তবে এটি signal_setসংকেত হ্যান্ডলিং সরবরাহ করে।uv_pipe_t।local::stream_protocol::socketবা local::datagram_protocol::socket, এবং windows::stream_handle।একা ভাষার উপর ভিত্তি করে এপিআইগুলি পৃথক হলেও এখানে কয়েকটি মূল পার্থক্য রয়েছে:
বুস্ট.অ্যাসিওর মধ্যে একটি অপারেশন এবং হ্যান্ডলারের মধ্যে একের পর এক ম্যাপিং রয়েছে। উদাহরণস্বরূপ, প্রতিটি async_writeঅপারেশন একবার WritHandler শুরু করবে । এটি অনেকগুলি লাইবভ অপারেশন এবং হ্যান্ডলারের ক্ষেত্রে সত্য। তবে লিবুভস uv_async_sendএকাধিক টু ওয়ান ম্যাপিং সমর্থন করে। একাধিক uv_async_sendকলগুলির ফলে uv_async_cb একবার কল করা হতে পারে ।
কোনও কাজের সাথে যখন যেমন কোনও স্ট্রিম / ইউডিপি থেকে পড়া, সংকেতগুলি পরিচালনা করা বা টাইমারগুলির জন্য অপেক্ষা করা হয় তখন বুস্ট.আসিয়োর অ্যাসিঙ্ক্রোনাস কল চেইনগুলি আরও কিছুটা স্পষ্ট। লিবুভের সাহায্যে কোনও নির্দিষ্ট ইভেন্টে আগ্রহী হিসাবে মনোনীত করার জন্য একজন প্রহরী তৈরি করা হয়। তারপরে পর্যবেক্ষকদের জন্য একটি লুপ শুরু করা হয়, যেখানে কলব্যাক সরবরাহ করা হয়। আগ্রহের ইভেন্টটি পাওয়ার পরে, কলব্যাকটি শুরু করা হবে। অন্যদিকে, বুস্ট.অ্যাসিও প্রত্যেকবার অ্যাপ্লিকেশনটি ইভেন্টটি পরিচালনা করতে আগ্রহী হয়ে অপারেশন জারি করা দরকার।
এই পার্থক্যটি চিত্রিত করতে সহায়তার জন্য, এখানে বুস্ট.এসিওর সাথে একটি অ্যাসিনক্রোনাস রিড লুপ রয়েছে, যেখানে async_receiveকলটি একাধিকবার জারি করা হবে:
void start()
{
socket.async_receive( buffer, handle_read ); ----.
} |
.----------------------------------------------'
| .---------------------------------------.
V V |
void handle_read( ... ) |
{ |
std::cout << "got data" << std::endl; |
socket.async_receive( buffer, handle_read ); --'
} এবং এখানে লিবুভের সাথে একই উদাহরণ রয়েছে, যেখানে handle_readপ্রতিবার পর্যবেক্ষক সকেটের ডেটা রয়েছে তা লক্ষ্য করা যায়:
uv_read_start( socket, alloc_buffer, handle_read ); --.
|
.-------------------------------------------------'
|
V
void handle_read( ... )
{
fprintf( stdout, "got data\n" );
}বুস্ট.এসিওতে অ্যাসিক্রোনাস কল চেইনের ফলস্বরূপ এবং লিবুভের প্রহরীগণের জন্য মেমরির বরাদ্দ প্রায়শই বিভিন্ন সময়ে ঘটে। দর্শকদের সাথে, Libuv বরাদ্দ স্থগিত করে যতক্ষণ না এটি ইভেন্টটি গ্রহণ করার জন্য মেমরির প্রয়োজন হয়। বরাদ্দটি কোনও ব্যবহারকারী কলব্যাকের মাধ্যমে করা হয়, অভ্যন্তরীণভাবে লিবুভকে আহ্বান জানানো হয় এবং অ্যাপ্লিকেশনটির নির্গমন দায়কে পিছিয়ে দেয়। অন্যদিকে, Boost.Asio অপারেশন অনেক প্রয়োজন যে মেমরি যেমন ক্ষেত্রে হিসাবে, অ্যাসিঙ্ক্রোনাস অপারেশন জারি আগে বরাদ্দ করা bufferজন্য async_read। বুস্ট.এসিও সরবরাহ করে null_buffers, এটি কোনও ইভেন্ট শোনার জন্য ব্যবহার করা যেতে পারে, মেমরির প্রয়োজন না হওয়া পর্যন্ত অ্যাপ্লিকেশনগুলিকে মেমরির বরাদ্দ স্থগিত করতে দেয়, যদিও এটি হ্রাস করা হয়।
এই মেমরি বরাদ্দ পার্থক্য এছাড়াও bind->listen->acceptলুপ মধ্যে নিজেকে উপস্থাপন করে । লাইবভের সাহায্যে uv_listenএকটি ইভেন্ট লুপ তৈরি হয় যা যখন কোনও সংযোগ গ্রহণের জন্য প্রস্তুত হয় তখন ব্যবহারকারী কলব্যাকের ডাক দেয়। এটি অ্যাপ্লিকেশনটিকে কোনও সংযোগ দেওয়ার চেষ্টা না করা অবধি ক্লায়েন্টের বরাদ্দের পিছনে পিছনে দেয়। অন্যদিকে, বুস্ট.অ্যাসিওর listenকেবলমাত্র রাজ্যের অবস্থা পরিবর্তন করে acceptor। async_acceptসংযোগ ইভেন্টের জন্য শোনেন এবং পিয়ার প্রয়োজন প্রার্থনা হচ্ছে আগে বরাদ্দ করা হবে।
দুর্ভাগ্যক্রমে, লাইবভ এবং বুস্ট.এসিওর তুলনা করার জন্য আমার কাছে কোনও কংক্রিট বেনমার্ক নম্বর নেই। তবে, আমি রিয়েল-টাইম এবং নিকট-রিয়েল-টাইম অ্যাপ্লিকেশনগুলিতে লাইব্রেরিগুলি ব্যবহার করে অনুরূপ কর্মক্ষমতা পর্যবেক্ষণ করেছি। যদি হার্ড সংখ্যাগুলি কাঙ্ক্ষিত হয় তবে লাইবভের বেঞ্চমার্ক পরীক্ষাটি একটি সূচনা পয়েন্ট হিসাবে কাজ করতে পারে।
অতিরিক্তভাবে, প্রকৃত বাধা চিহ্নিত করার জন্য প্রোফাইলিং করা উচিত, মেমরির বরাদ্দ সম্পর্কে সচেতন হন be লিবুভের জন্য, মেমরি বরাদ্দ কৌশলটি প্রাথমিকভাবে বরাদ্দকারী কলব্যাকের মধ্যে সীমাবদ্ধ। অন্যদিকে, বুস্ট.অ্যাসিওর এপিআই একটি বরাদ্দকারী কলব্যাকের অনুমতি দেয় না এবং পরিবর্তে অ্যাপ্লিকেশনটিতে বরাদ্দ কৌশলটি পুশ করে। তবে বুস্ট.অ্যাসিওর হ্যান্ডলার / কলব্যাকগুলি অনুলিপি করা, বরাদ্দ করা এবং বিলোপযুক্ত হতে পারে। বুস্ট.এসিও হ্যান্ডলারের জন্য একটি মেমরি বরাদ্দ কৌশল বাস্তবায়নের জন্য অ্যাপ্লিকেশনগুলিকে কাস্টম মেমরি বরাদ্দকরণের ক্রিয়া সরবরাহ করার অনুমতি দেয় allows
আসিওর বিকাশ কমপক্ষে ওসিটি -৪০০-এর সাথে সম্পর্কিত এবং 20-দিনের পিয়ার পর্যালোচনা করার পরে 22-মার্চ 2006-এ এটি বুস্ট 1.35 এ গৃহীত হয়েছিল। এটি টিআর 2 এর জন্য নেটওয়ার্কিং লাইব্রেরি প্রস্তাবের জন্য রেফারেন্স বাস্তবায়ন এবং এপিআই হিসাবে কাজ করেছে । বুস্ট.এসিওর ডকুমেন্টেশনগুলির পরিমাণ মোটামুটি রয়েছে , যদিও এর ব্যবহারিকতা ব্যবহারকারীর মধ্যে পরিবর্তিত হয়।
এপিআইতেও মোটামুটি ধারাবাহিক অনুভূতি থাকে। অতিরিক্তভাবে, অ্যাসিক্রোনাস অপারেশনগুলি অপারেশনের নামে সুস্পষ্ট। উদাহরণস্বরূপ, acceptসিঙ্ক্রোনাস ব্লকিং এবং async_acceptঅ্যাসিনক্রোনাস। এআইপিআই সাধারণ I / O কার্যের জন্য ফ্রি ফাংশন সরবরাহ করে, উদাহরণস্বরূপ, স্ট্রিম থেকে পড়া না হওয়া পর্যন্ত \r\nপড়া। কিছু নেটওয়ার্ক নির্দিষ্ট বিবরণ যেমন ip::address_v4::any()"" সমস্ত ইন্টারফেস "এর ঠিকানা উপস্থাপন করে তা গোপন করার দিকেও মনোযোগ দেওয়া হয়েছে 0.0.0.0।
শেষ অবধি, বুস্ট ১.47 hand++ হ্যান্ডলার ট্র্যাকিং সরবরাহ করে যা ডিবাগ করার সময় সি ++ 11 সমর্থন হিসাবে কার্যকর হিসাবে প্রমাণিত হতে পারে।
তাদের GitHub গ্রাফ উপর ভিত্তি করে, Node.js উন্নয়ন তারিখ অন্তত ফিরে ফেব্রুয়ারি 2009 , এবং libuv উন্নয়ন তারিখ Mar-2011 । Uvbook একটি libuv পরিচয়ের জন্য একটি দারুন জায়গা। এপিআই ডকুমেন্টেশন এখানে ।
সামগ্রিকভাবে, API মোটামুটি সুসংগত এবং সহজেই ব্যবহারযোগ্য। বিভ্রান্তির উত্স হতে পারে uv_tcp_listenএমন একটি ব্যঙ্গতা হ'ল এটি একজন প্রহরী লুপ তৈরি করে। এটি অন্যান্য পর্যবেক্ষকদের তুলনায় আলাদা যা সাধারণভাবে পর্যবেক্ষক লুপটির জীবন নিয়ন্ত্রণ করতে এক uv_*_startএবং uv_*_stopজোড়া ফাংশন রাখে। এছাড়াও, কিছু uv_fs_*অপারেশনে একটি বিতর্কিত পরিমাণ রয়েছে (7 অবধি)। একটি কলব্যাকের উপস্থিতি (শেষ যুক্তি) -এ সিঙ্ক্রোনাস এবং অ্যাসিঙ্ক্রোনাস আচরণ নির্ধারিত হওয়ার সাথে সিঙ্ক্রোনাস আচরণের দৃশ্যমানতা হ্রাস করা যেতে পারে।
অবশেষে, লিবুভ কমিটের ইতিহাসের তাত্ক্ষণিক নজরে দেখা যায় যে বিকাশকারীরা খুব সক্রিয়।
uv_async_sendকল সংগ্রহ করতে পারে এবং একক কলব্যাকের সাহায্যে সেগুলি হ্যান্ডেল করতে পারে । এটি এখানে নথিভুক্ত করা হয় । এছাড়াও, সবাইকে ধন্যবাদ।
ঠিক আছে. উভয় গ্রন্থাগার ব্যবহারের আমার কিছু অভিজ্ঞতা আছে এবং আমি কিছু জিনিস পরিষ্কার করতে পারি।
প্রথমত, একটি ধারণামূলক ভিউ-পয়েন্ট থেকে এই গ্রন্থাগারগুলি ডিজাইনের ক্ষেত্রে একেবারেই আলাদা। তাদের বিভিন্ন আর্কিটেকচার রয়েছে, কারণ এগুলি বিভিন্ন স্কেলের। বুস্ট.এইসিও একটি বৃহত নেটওয়ার্কিং লাইব্রেরি যার লক্ষ্য টিসিপি / ইউডিপি / আইসিএমপি প্রোটোকল, পসিক্স, এসএসএল এবং আরও কিছু ব্যবহার করা যেতে পারে। মূলত নোড.জেএস -এর জন্য আইওসিপি -র ক্রস-প্ল্যাটফর্ম বিমোচনার জন্য লিবভ কেবল একটি স্তর । সুতরাং Libuv কার্যকরীভাবে Boost.Asio এর একটি উপসেট (সাধারণ বৈশিষ্ট্যগুলি কেবলমাত্র TCP / UDP সকেট থ্রেড, টাইমার)। সেক্ষেত্রে, আমরা কেবলমাত্র কয়েকটি মানদণ্ড ব্যবহার করে এই লাইব্রেরিগুলি তুলনা করতে পারি:
নতুন সি ++ বৈশিষ্ট্যের সাথে সংহতকরণ: অ্যাসিও আরও ভাল (অসিও 1.51 ব্যাপকভাবে সি ++ 11 অ্যাসিনক্রোনাস মডেল ব্যবহার করে শব্দার্থক, বিভিন্ন ধরণের টেমপ্লেট ব্যবহার করে) matপরিচিততার বিষয়ে, অসিও ভাল ডকুমেন্টেশন সহ একটি আরও স্থিতিশীল এবং পরিপক্ক প্রকল্প (যদি এটি লিবুভের সাথে তুলনা করে) শিরোনামের বিবরণ), ইন্টারনেট জুড়ে প্রচুর তথ্য (ভিডিও আলোচনা, ব্লগ: http://www.gamedev.net/blog/950/entry-2249317-a-guide-to-getting-st সূত্র- with- boostasio ?pg = 1 , ইত্যাদি) এবং এমনকি বই (পেশাদারদের জন্য নয় তবে তবুও: http://en.highscore.de/cpp/boost/index.html )। লিবিভের একটি মাত্র অনলাইন বই রয়েছে (তবে ভাল) http://nikhilm.github.com/uvbook/index.htmlএবং বেশ কয়েকটি ভিডিও কথাবার্তা, সুতরাং সমস্ত গোপনীয় বিষয়গুলি জানার জন্য এটি কঠিন হবে (এই লাইব্রেরিতে তাদের অনেকগুলি রয়েছে)। ফাংশনগুলির আরও নির্দিষ্ট আলোচনার জন্য নীচে আমার মন্তব্যগুলি দেখুন।
উপসংহার হিসাবে, আমার বলা উচিত যে এটি সব আপনার উদ্দেশ্য, আপনার প্রকল্প এবং আপনি কী দৃ concrete়তার সাথে করতে চান তার উপর নির্ভর করে।
এর মধ্যে একটি বিশাল পার্থক্য হলেন আসিওর লেখক (ক্রিস্টোফার কোহলহফ) তাঁর লাইব্রেরিটি সি ++ স্ট্যান্ডার্ড লাইব্রেরিতে অন্তর্ভুক্ত করার জন্য তৈরি করছেন, দেখুন http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2175 .pdf এবং http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4370.html
বহনযোগ্যতার স্থিতি যুক্ত করা: এই উত্তরটি পোস্ট করা এবং আমার নিজের প্রচেষ্টা অনুসারে: