আইওটি অ্যাপ্লিকেশনটির জন্য উপযুক্ত প্রোটোকল নির্বাচন করা


12

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

  • ব্যাটারির আয়ু সর্বাধিক করা হচ্ছে
  • ডেটা ট্রান্সফার হ্রাস করা হচ্ছে

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

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

এখন পর্যন্ত আমরা এই সম্ভাবনাগুলি সম্পর্কে চিন্তা করেছি:

  • টিসিপির মাধ্যমে কাস্টম প্রোটোকল । এটি এইচটিটিপি শিরোনাম থেকে বার্তাটি 10 ​​গুণ ছোট করে তুলবে। এটি আমাদের নির্ভরযোগ্য / রক্ষণশীল পন্থা।
  • ইউডিপির উপর কাস্টম প্রোটোকল । যেহেতু ইউডিপি-তে ছোট হেডার রয়েছে এবং নির্ভরযোগ্যতার জন্য কোনও ওভারহেড নেই, তাই আমরা আশা করি বেশ দক্ষ হয়ে উঠব। যেমনটি মন্তব্য করা হয়েছে, এখানে একটি বার্তা হারাতে বা কোনও উদ্বেগের বিষয় নেই ... তবে, অ-নির্ভরযোগ্যতা নিয়ে অন্যান্য বিষয়ও থাকতে পারে যা আমরা অবগত নই।
  • এমকিউটিটি (টিসিপি-র ওভার স্ট্যান্ডার্ড): টিসিপির তুলনায় প্রায় কোনও ওভারহেড না থাকলে এটিও একটি বিকল্প হতে পারে ... তবে, জিএসএম / সিম প্রযুক্তি নিয়ে আমাদের খুব বেশি অভিজ্ঞতা নেই, এবং কীভাবে জানেন না একটি অবিচ্ছিন্ন এমকিউটিটি সংযোগটি এইভাবে কাজ করবে এবং সংযোগ হার্টবিট ব্যান্ডউইথ যেমন কম ফ্রিকোয়েন্সি ডেটা স্থানান্তরের জন্য উপযুক্ত কিনা।
  • কোপ (ইউডিপির চেয়ে বেশি স্ট্যান্ডার্ড): আশাবাদীও বলে মনে হচ্ছে। হেডারের জন্য মাত্র 4 বাইট ওভারহেড এবং ইউডিপিতে কাজ করছে working ইউডিপির অজানা ঝুঁকিগুলি অবশ্য আছে।

কেউ কি কোনও ইঙ্গিত দিতে পারে? আগাম ধন্যবাদ.


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

1
আমি একটি কাস্টম প্রোটোকল ডিজাইন করে চাকাটিকে পুনরায় সাজিয়ে তুলব না। কোপ বনাম এমকিউটিটির একটি গুগল আপনাকে আরও বিবেচনা দেবে। আপনার সমাধানের ভবিষ্যত-প্রমাণ করার দরকার আছে, যেমন। ভবিষ্যতে কঠোর প্রয়োজনীয়তাগুলি হ্যান্ডেল করুন (ক্ষতির গ্যারান্টি, প্রতিক্রিয়ার সময়, আন্তঃঅযুক্তি ইত্যাদি)? ডিভাইসগুলি NAT'ed হয়? গেটওয়েগুলির পিছনে কি ডিভাইসগুলির গোষ্ঠীকরণ রয়েছে? অনেক অজানা ...
গ্যাম্বিট

উত্তর:


6

টিসিপি, ইউডিপি এবং এমকিউটিটির সাথে আমার অভিজ্ঞতার পাশাপাশি পর্যালোচনা করার জন্য কিছু অতিরিক্ত সংস্থান সম্পর্কে কিছু ধারণা।

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

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

দেখে মনে হচ্ছে আপনার ক্ষেত্রে কেবল একটি অ্যাক্কি প্রাপ্তি ছাড়াই টাইমআউট হওয়ার পরে retransmit সহ একটি সাধারণ অ্যাক্কই যথেষ্ট suff

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

টিসিপিতে কয়েকটি বৈশিষ্ট্য রয়েছে যেমন প্যাকেটের ক্রমিক ক্রম, কোনও পুনরাবৃত্তি করা হয়নি এবং সংযুক্ত পরিবহণ ব্যবস্থা হওয়ার অর্থ আপনি অন্য প্রান্তটি অদৃশ্য হয়ে গেছে কিনা তা জানার জন্য এটি কিছুটা সময় নিতে পারে may সংযোগ স্থাপন এবং সংযোগ বিচ্ছিন্ন হওয়া বিলম্বের পরিচয় দিতে পারে তবে সাধারণ অবস্থার অধীনে বোঝা নয় যদিও নেটওয়ার্কের অবস্থার কারণে টিসিপি থ্রুপুটটি ধীর হয়ে যেতে পারে।

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

বার্তাগুলি সংরক্ষণের জন্য সাবস্ক্রাইবারে JSON পাঠ্য এবং একটি এসকিউএল 3 ডাটাবেস ব্যবহার করে এমকিউটিটি-র আমার পরীক্ষাগুলি https://github.com/RichardChabers/raspberrypi/tree/master/mqtt এ যদিও উত্সটি সিটিতে রয়েছে এবং বেশ অগোছালো।

এখানে একটি 13 মিনিটের ভিডিও # 144 ইন্টারনেট প্রোটোকল: কোপ বনাম এমকিউটিটি, নেটওয়ার্ক স্নিফিং, এবং আইকেইএ ট্রেডফ্রি হ্যাকিংয়ের প্রস্তুতি । এটি কোপ সম্পর্কে একটি আকর্ষণীয় নিবন্ধ, নিয়ন্ত্রিত অ্যাপ্লিকেশন প্রোটোকল: কোপ আইওটির 'আধুনিক' প্রোটোকল । কোপের এই সমষ্টি রয়েছে:

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

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

আরও কয়েক জন রয়েছে যেমন AMQP, STOMP, এবং CBOR এর দিকেও আপনি তাকিয়ে থাকতে পারেন। দেখুন CBOR মান ওয়েবসাইট সেইসাথে এই থিসিস, বাস্তবায়ন এবং CBOR প্রোটোকলের মূল্যায়ন । এই নিবন্ধটি দেখুন, আপনার বার্তা প্রোটোকলটি নির্বাচন করা: এএমকিপি, এমকিউটিটি, বা স্টোমপ যা এএমকিপি, এমকিউটিটি, এবং স্টোমপের তুলনা করে এবং বিপরীত করে এবং রবিটএমকিউ ব্রোকার সম্পর্কে একটি নোট সহ শেষ করে:

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

প্রায় 60০ টি স্লাইডের এই স্লাইড শেয়ার প্যাকেজটি দুটি পৃথক আইওটি প্রোটোকলের মধ্যে তুলনামূলক এবং বৈসাদৃশ্য করে যা দুটি ভিন্ন আইওটি গ্রুপ, গ্রাহক এবং শিল্পের প্রয়োজন, যাঁদের নির্ভরযোগ্যতা এবং দৃust়তার জন্য পৃথক প্রয়োজন রয়েছে looking আইওটির সঠিক মেসেজিং স্ট্যান্ডার্ড কী?


4

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

সংযোগ স্থাপনা এবং প্যাকেট ওভারহেডে সঞ্চয় আপনার পক্ষে ভাল কাজ করবে।

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

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


4

আপনি কি বাহ্যিকভাবে জিএসএম / সিম ব্যবহারে সীমাবদ্ধ?

একটি বিকল্প একটি লোআরএ নেটওয়ার্ক ব্যবহার করা হতে পারে যা:

  • ছোট পেডগুলির জন্য অত্যন্ত অনুকূলিত
  • সর্বনিম্ন শক্তি ব্যবহারের জন্য ডিজাইন করা হয়েছে (এবং তাই সর্বোচ্চ ব্যাটারি লাইফ)
  • নকশা দ্বারা দীর্ঘ পরিসীমা হয়
  • সংযোগ ক্লাস রয়েছে (সর্বদা চালু, স্বীকৃত, অস্বীকৃত)
  • নির্ধারিত ডাউনলোড উইন্ডো রয়েছে (যেমন ফার্মওয়্যার আপডেট বা আরএক্স এসি জন্য)

আপনি বেশিরভাগ দেশে বিদ্যমান সম্প্রদায় বা বাণিজ্যিক লোআর অবকাঠামোতে প্লাগ করতে পারেন, বা যদি এটি যথাযথ হয় তবে আপনার নিজের লোআর হাব স্থাপন করতে পারেন।

বিশ্বব্যাপী সক্রিয় বিকাশ রয়েছে এবং প্রোটোটাইপিং শিল্ডগুলির সহজ প্রাপ্যতা (উদাহরণস্বরূপ আরডুইনো)।


1
প্রশ্নে উল্লিখিত এক মিনিটের মধ্যে প্রস্তাবিত লোআরএ নোড ট্রান্সমিশন ইন্টারভালগুলির সাথে ফিট করার জন্য অনেক বেশি ঘন ঘন।
ক্রিস স্ট্রাটন

1
সম্মত 1 মিনিট খুব ঘন ঘন। যদিও @bgusach অ্যাপ্লিকেশনটির উল্লেখ করে না। যদি পেলোডটি আকার হ্রাস করতে বাইনারি এনকোড করা যায় এবং যদি 3-5 মিনিট (বা এমনকি 10 মিনিট) ব্যবধান ব্যবহারযোগ্য হয় তবে এটি আদর্শ হতে পারে। যাইহোক, কেবলমাত্র একটি পরামর্শ হিসাবে আমি দ্রষ্টব্য যে এটি উত্তরগুলিতে আগে উল্লেখ করা হয়নি।
ব্রেন্ডনএমসিএল

1
হ্যাঁ, আমি যদি এটি সঠিকভাবে পড়ছি তবে চার মিনিটের বিরতিতে 50 বাইটের মতো কিছু সবেই ফিট হতে পারে; তবে এটি যাচাইকরণের প্রয়োজন, এটি কমপক্ষে দুজনের একটি কারণ দ্বারা সহজেই বন্ধ হয়ে যেতে পারে।
ক্রিস স্ট্রাটন

1
আকর্ষণীয়, তবে আমরা জিএসএম / সিম সীমাবদ্ধ (এটি ভোক্তা ভাল হওয়ার উদ্দেশ্যে করা হয়েছে, এমন কিছু যা ফোন নেটওয়ার্ক ছাড়া অন্য কোনও অবকাঠামো ছাড়াই যে কোনও জায়গায় কেনা এবং ব্যবহার করা যায়) can
বাগগাছ

3

আমি JSON ডেটা সহ ন্যূনতম HTTP প্রতিক্রিয়াটিকে পছন্দ করব ... একটি HTTP প্রতিক্রিয়া 500 বাইট HTTP স্থানান্তরের থেকে অনেক নিচে হতে পারে এবং আপনি RESTful ওয়েব অ্যাপ্লিকেশনগুলির জন্য অনেক ক্লায়েন্টের সাথে সামঞ্জস্যতা বজায় রেখেছেন।

একটি সর্বনিম্ন HTTP বার্তা (যেমন JSON ফলাফলের সাথে) এপ্রোক্স ১৩০ বাইটের HTTP ডেটার মতো দেখাচ্ছে:

HTTP/1.1 200 OK
Server: ProprietaryAndroid
Connection: close
Content-Type: application/json
{
  "lat": "42.00000",
  "long": "10.00000"
}

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

GET /?lat=42.00000&long=10.0000 HTTP/1.1
Host: 192.168.0.2 
User-Agent: Proprietary
Accept: */* 
Connection: close

7
আপনার উত্তরের জন্য ধন্যবাদ, তবে আমি HTTP প্রতিক্রিয়া সহ আপনার পয়েন্টটি দেখতে পাচ্ছি না। ডেটা স্থানান্তর সংরক্ষণ করতে আমরা পুরো এইচটিটিপি প্রোটোকল থেকে মুক্তি পেতে চাই। এবং GETWrong Thing™
তারপরে,

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

3

কোনও "সেরা" প্রোটোকল নেই। বিবেচনা করার জন্য কেবল প্রচুর বাণিজ্য-অফ:

  • আপনার ডিভাইসগুলি এলোমেলো বন্দরগুলি অবরুদ্ধ করে এলোমেলো নেটওয়ার্কগুলিতে থাকবে? যদি তা হয় তবে এইচটিটিপিএস ব্যবহার করা আরও ভাল।

  • আপনি যদি ইউডিপি প্রেরণ করেন তবে আপনি সর্বদা সর্বদা শেষ এন পরিমাপ প্রেরণ করতে পারেন, যাতে ছোট প্যাকেটের ক্ষতি এড়ানো যায়। আপনি ইউডিপিকে একটি নির্ভরযোগ্য প্রোটোকলে রূপান্তর করে একটি এসকে প্যাকেটও প্রেরণ করতে পারেন। (ইউডিপির শীর্ষে থাকা বেশিরভাগ প্রোটোকল এটি করে))

  • আপনার গ্রাহকরা যদি তাদের ডেটা এনক্রিপ্ট করা না প্রকাশ করে তবে তাদের যত্ন নেবে? হ্যাকাররা যদি সেই এনক্রিপ্ট না করা সংযোগগুলিতে খারাপ ডেটা ইনজেক্ট করতে পারে তবে আপনার গ্রাহকরা কি যত্ন নেবেন? (যদি তা হয় তবে আপনি এনক্রিপশন চাইতে পারেন))

  • কেউ যদি আপনার প্রোটোকল স্নিগ্ধ করে এবং ডেটা ম্যানিপুলেট করে তবে কি হবে? আপনি কি একটি ডিভাইস অন্যটির জন্য ওভাররাইটিং ডেটা থেকে আটকাতে পারবেন?

  • আপনার সর্বোচ্চ কত ডিভাইস থাকবে? আপনি কীভাবে এই সমস্ত ডিভাইসগুলির সাথে ডিল করতে যাচ্ছেন? আপনি কীভাবে ডেটাটি যাওয়ার দরকার সেখানে যাওয়ার পথে যাচ্ছেন? আপনি কীভাবে আপনার সার্ভারের অবকাঠামো রক্ষণাবেক্ষণ এবং আপগ্রেড করবেন? আপনার যদি অভিজ্ঞতা না থাকে তবে আপনি সম্ভবত বহু যুগপত সংযোগগুলি পরিচালনা করার দক্ষতার অতিরিক্ত মূল্যায়ন করছেন। একজন বিক্রেতার কাছে আউটসোর্স করা ভাল (এবং তাদের প্রোটোকল যেমন AWS IoT ব্যবহার করুন)।


3

আমরা HTTP- র বনাম MQTT সংক্রমণ হার তুলনা সঠিক পরীক্ষা আছে, দেখতে test2 | , আপনার বর্তমান দৃশ্যকল্প MQTT আপনি 50 বার কম ট্রাফিক (এবং ব্যাটারি) আনতে হবে তারপর HTTP- র।

মূলত এমকিউটিটি এবং প্লেইন টিসিপি (বার্তার আকারে) এর মধ্যে কোনও পার্থক্য নেই। আমি এমনকি এটিও বলতে পারি যে প্লেইন টিসিপি এবং বাইনারি বার্তা এবং এমকিটিটি পে-লোডে জেএসএনের মধ্যে কোনও পার্থক্য নেই। এমকিটিটি + জেএসওএন ব্যবহার করা এবং ডেটা বিতরণ এবং উপস্থাপনের জন্য এই প্রযুক্তির উপর নির্ভর করা আরও সহজ। আপনার চাবিগুলির নাম দিন কম বা কম দিন name

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

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


1
আমি এখানে ইউডিপির বিরুদ্ধে কয়েকটি শব্দ উল্লেখ করব। আমরা বিশ্বব্যাপী 100 টিরও বেশি দেশে গ্রাহকরা থাকা বৃহত SaaS GPS বহর পরিচালনা ব্যবস্থা (আরও 1 মিলিয়ন যানবাহন সংযুক্ত) বজায় রাখছি। এবং সম্প্রতি আমরা আবিষ্কার করেছি যে মার্কিন যুক্তরাষ্ট্র ভিত্তিক ইন্টারনেট সরবরাহকারীরা ইউডিপি প্যাকেটগুলি কোনও কারণে মার্কিন যুক্তরাষ্ট্রের বাইরে চলে যাচ্ছে, এমনকি এম 2 এম অ্যাপ্লিকেশনগুলির জন্যও। এটি কয়েক মাস আগে শুরু হয়েছিল, তবে এটি অত্যন্ত বেদনাদায়ক, তাই আমি আপনাকে টিসিপি ভিত্তিক প্রোটোকল (এমকিউটিটি) নির্বাচন করার এবং বিশ্বমানের উপর নির্ভর করার পরামর্শ দিচ্ছি। কিছু দিন এবং কিছু দেশে আপনি এমনকি সংযোগ বজায় রাখতে ওয়েবকোকেটের উপরে এমকিউটিটি ব্যবহার করতে বাধ্য হবেন। শুধু ছোট পরামর্শ।
শাল
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.