সিরিয়াল প্রোটোকল সীমানা / সিঙ্ক্রোনাইজেশন কৌশল


24

যেহেতু আজকাল অ্যাসিঙ্ক্রোনাস সিরিয়াল যোগাযোগ ব্যাপকভাবে বৈদ্যুতিন ডিভাইসের মধ্যে ছড়িয়ে পড়েছে, আমি বিশ্বাস করি আমাদের মধ্যে অনেকে সময়ে সময়ে এই জাতীয় প্রশ্নের মুখোমুখি হয়েছিল। একটি ইলেকট্রনিক ডিভাইস Dএবং PCসিরিয়াল লাইনের সাথে সংযুক্ত কম্পিউটার (আরএস -232 বা অনুরূপ) বিবেচনা করুন এবং অবিচ্ছিন্নভাবে তথ্য আদান প্রদানের প্রয়োজন । অর্থাৎ PCপ্রত্যেকটি কমান্ড ফ্রেম প্রেরণ করছে X msএবং প্রতিটি Dস্থিতি প্রতিবেদন / টেলিমেট্রি ফ্রেমের Y msসাথে জবাব দিচ্ছে (প্রতিবেদনটি অনুরোধের প্রতিক্রিয়া হিসাবে বা স্বাধীনভাবে পাঠানো যেতে পারে - এখানে আসলে কিছু আসে যায় না)। যোগাযোগের ফ্রেমগুলিতে যেকোন স্বেচ্ছাসেবী বাইনারি ডেটা থাকতে পারে । ধরে নিচ্ছি যোগাযোগের ফ্রেমগুলি নির্দিষ্ট দৈর্ঘ্যের প্যাকেটগুলি।

সমস্যাটি:

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

প্রয়োজনীয় সমাধান

স্বল্প পুনরুদ্ধারের সময়ের সাথে এসওএফ সনাক্তকরণের জন্য নির্ভরযোগ্য সীমিতকরণ / সিঙ্ক্রোনাইজেশন স্কিম (যেমন এটি পুনরায় সংশ্লেষ করতে 1 ফ্রেমের চেয়ে বেশি লাগবে না)।

বিদ্যমান কৌশলগুলি সম্পর্কে আমি সচেতন (এবং কিছু ব্যবহার করে):

1) শিরোনাম / চেকসাম - পূর্বনির্ধারিত বাইট মান হিসাবে এসওএফ। ফ্রেমের শেষে চেকসাম।

  • পেশাদাররা: সরল।
  • কনস: নির্ভরযোগ্য নয়। অজানা পুনরুদ্ধারের সময়।

2) বাইট স্টাফিং:

  • পেশাদাররা: নির্ভরযোগ্য, দ্রুত পুনরুদ্ধার, যে কোনও হার্ডওয়ারের সাথে ব্যবহার করা যেতে পারে
  • কনস: স্থির আকারের ফ্রেম-ভিত্তিক যোগাযোগের জন্য এটি উপযুক্ত নয়

3) 9 ম বিট চিহ্নিতকরণ - প্রতিটি বিট অতিরিক্ত বিট সহ প্রিপেন্ড করুন, এসওএফ দ্বারা চিহ্নিত করা হয়েছে 1এবং ডেটা বাইটগুলি চিহ্নিত রয়েছে 0:

  • পেশাদাররা: নির্ভরযোগ্য, দ্রুত পুনরুদ্ধার
  • কনস: হার্ডওয়্যার সমর্থন প্রয়োজন। বেশিরভাগ PCহার্ডওয়্যার এবং সফ্টওয়্যার দ্বারা সরাসরি সমর্থিত নয় ।

4) 8 ম বিট চিহ্নিতকরণ - উপরের অনুকরণের ধরণ, 9 তম পরিবর্তে 8 তম বিট ব্যবহার করার সময়, যা প্রতিটি ডেটা শব্দের জন্য কেবল 7 বিট রেখে চলেছে।

  • পেশাদাররা: নির্ভরযোগ্য, দ্রুত পুনরুদ্ধার, যে কোনও হার্ডওয়ারের সাথে ব্যবহার করা যেতে পারে।
  • কনস: 7-বিট উপস্থাপনের / থেকে প্রচলিত 8-বিট উপস্থাপনা / থেকে / এনকোডিং / ডিকোডিং স্কিমের প্রয়োজন। কিছুটা অপব্যয়।

5) টাইমআউট ভিত্তিক - এসওএফটিকে কিছু বদ্ধ নির্ধারিত সময়ের পরে প্রথম বাইট হিসাবে ধরে নেওয়া উচিত।

  • পেশাদাররা: কোনও উপাত্ত নেই, সহজ,
  • কনস: এটি নির্ভরযোগ্য নয়। উইন্ডোজ পিসির মতো দুর্বল টাইমিং সিস্টেমগুলির সাথে ভাল কাজ করবে না। সম্ভাব্য থ্রুপুট ওভারহেড।

প্রশ্ন: সমস্যা সমাধানের জন্য অন্যান্য সম্ভাব্য কৌশল / সমাধান কী কী? আপনি কি উপরের তালিকার কনসগুলিতে ইঙ্গিত করতে পারেন যা সহজেই চারপাশে কাজ করা যেতে পারে, যাতে এগুলি সরিয়ে দেওয়া হয়? আপনি কীভাবে (বা আপনি) আপনার সিস্টেম প্রোটোকল ডিজাইন করবেন?

serial  communication  protocol  brushless-dc-motor  hall-effect  hdd  scr  flipflop  state-machines  pic  c  uart  gps  arduino  gsm  microcontroller  can  resonance  memory  microprocessor  verilog  modelsim  transistors  relay  voltage-regulator  switch-mode-power-supply  resistance  bluetooth  emc  fcc  microcontroller  atmel  flash  microcontroller  pic  c  stm32  interrupts  freertos  oscilloscope  arduino  esp8266  pcb-assembly  microcontroller  uart  level  arduino  transistors  amplifier  audio  transistors  diodes  spice  ltspice  schmitt-trigger  voltage  digital-logic  microprocessor  clock-speed  overclocking  filter  passive-networks  arduino  mosfet  control  12v  switching  temperature  light  luminous-flux  photometry  circuit-analysis  integrated-circuit  memory  pwm  simulation  behavioral-source  usb  serial  rs232  converter  diy  energia  diodes  7segmentdisplay  keypad  pcb-design  schematics  fuses  fuse-holders  radio  transmitter  power-supply  voltage  multimeter  tools  control  servo  avr  adc  uc3  identification  wire  port  not-gate  dc-motor  microcontroller  c  spi  voltage-regulator  microcontroller  sensor  c  i2c  conversion  microcontroller  low-battery  arduino  resistors  voltage-divider  lipo  pic  microchip  gpio  remappable-pins  peripheral-pin-select  soldering  flux  cleaning  sampling  filter  noise  computers  interference  power-supply  switch-mode-power-supply  efficiency  lm78xx 

4 3 এর চেয়ে মাত্র 1/8 ম বেশি অপচয়
নিক জনসন

@ নিক জোনসন সম্মত হন তবে এটি কেবলমাত্র পরামর্শ দিচ্ছে যে আমি (3) এর মধ্যে "অপব্যয়ী" জিনিসটি যুক্ত করব :)
ইউজিন শ।

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

বসিভার একটি বাইটের মাঝখানে যোগদান করতে পারে এবং বিট 8 উদাহরণস্বরূপ বিট 4 হিসাবে ব্যাখ্যা করতে পারে। নবম বিট চিহ্নিতকরণ তাই বিশ্বাসযোগ্য নয়।
তিমিথ বাল্ডউইন

@ গবুলার আসল অনুমানটি হ'ল চ্যানেলটি নিখুঁত এবং কেবল প্রাথমিক মিসকনক্রোনাইজেশনের কারণে সমস্যাটি উঠতে পারে। এই অনুমানগুলির অধীনে আমি "নির্ভরযোগ্যতা" উল্লেখ করছি কেবল রিসাইঙ্কের সাথে সম্পর্কিত। উপরের তালিকায় এই সমস্ত কৌশল প্রথমটি ব্যতীত 100% সাফল্যের গ্যারান্টি দিচ্ছে। তবে সম্ভবত ত্রুটি পরীক্ষা করার ত্রুটি এবং ফ্রেমিংটি এভাবে আলাদা করা উচিত নয়।
ইউজিন শ।

উত্তর:


15

আপনি কীভাবে (বা আপনি) আপনার সিস্টেম প্রোটোকল ডিজাইন করবেন?

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

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

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

এম্বেড টু কম্পিউটার যোগাযোগের জন্য গুড আরএস 232-ভিত্তিক প্রোটোকলগুলিতে তালিকাভুক্ত এক ডজন এম্বেড থাকা সিস্টেম প্রোটোকল রয়েছে - আপনার প্রয়োজনীয়তার সবচেয়ে কাছেরটি কোনটি?

এমনকি কিছু পরিস্থিতিতে পূর্বের বিদ্যমান প্রোটোকলটি ঠিকঠাকভাবে ব্যবহার করা অসম্ভব হয়ে উঠলেও, প্রায়শই প্রয়োজনীয়তার সাথে খাপ খায় এমন কিছু প্রোটোকল শুরু করে আরও দ্রুত কিছু কাজ করার সম্ভাবনা আমার রয়েছে।

খারাপ সংবাদ

যেমনটি আমি আগে বলেছি :

দুর্ভাগ্যক্রমে, কোনও যোগাযোগ প্রোটোকলের পক্ষে এই সমস্ত সুন্দর বৈশিষ্ট্য থাকা অসম্ভব:

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

কোনও যোগাযোগ প্রোটোকলের জন্য এই সমস্ত বৈশিষ্ট্য রাখার কোনও উপায় থাকলে আমি অবাক এবং আনন্দিত হব।

ভাল খবর

সমস্যাটি সমাধানের জন্য অন্যান্য সম্ভাব্য কৌশল / সমাধানগুলি কী কী?

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

কিছু প্রোটোকল বার্তাগুলি "টেক্সট" বা "বাইনারি" মোডে প্রেরণের মঞ্জুরি দেয় (এবং সমস্ত সম্ভাব্য বাইনারি বার্তাগুলির জন্য কিছু "সমতুল্য" পাঠ্য বার্তা থাকা প্রয়োজন যার অর্থ একই জিনিস)। এটি ডিবাগিংকে আরও সহজ করতে সহায়তা করতে পারে।

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

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

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

আপনি কি উপরের তালিকার কনসগুলিতে ইঙ্গিত করতে পারেন যা সহজেই চারপাশে কাজ করা যেতে পারে, যাতে এগুলি সরিয়ে দেওয়া হয়?

নিকোলাস ক্লার্ক যেমন উল্লেখ করেছেন, ধারাবাহিক-ওভারহেড বাইট স্টাফিং (সিওবিএস) এর একটি স্থির ওভারহেড রয়েছে যা স্থির আকারের ফ্রেমের সাথে ভালভাবে কাজ করে।

একটি কৌশল যা প্রায়শই উপেক্ষা করা হয় তা হ'ল ডেডিকেটেড শেষ-ফ্রেম মার্কার বাইট। যখন রিসিভারটি সঞ্চালনের মাঝখানে চালু হয়, তখন একটি ডেডিকেটেড শেষ-ফ্রেম মার্কার বাইট রিসিভারটিকে দ্রুত সিঙ্ক্রোনাইজ করতে সহায়তা করে।

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

শুভকামনা।


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

1
আপনি সিওবিএসকে নির্দেশ করেছেন তা চমৎকার, সুতরাং আমাকে একটি উত্তর লিখতে হবে না :-)
নিলস পাইপেনব্রিন্ক

11

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

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

বাইট-স্টাফিংয়ের ওভারহেডের বিষয়ে আপনি কি সিওবিএস প্রোটোকলের দিকে নজর রেখেছেন? প্রতি 254 ট্রান্সমিশন প্রতি 1 বাইটের একটি নির্দিষ্ট ওভারহেড (প্লাস আপনার ফ্রেমিং, সিআরসি, লেন, ইত্যাদি) সহ বাইট-স্টাফিং করার প্রতিভা উপায়।

https://en.wikipedia.org/wiki/Consistent_Overhead_Byte_Stuffing


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

1
সিওবিএস দেখানোর জন্য আমার কাছ থেকেও ধন্যবাদ - খুব ঝরঝরে সামান্য অ্যালগরিদম।
নিক জনসন

6

আপনার বিকল্প # 1, এসওএইচ প্লাস চেকসাম, নির্ভরযোগ্য এবং এটি পরবর্তী অনিয়ন্ত্রিত ফ্রেমে পুনরুদ্ধার করে।

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

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

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

যদি বার্তাগুলি দৈর্ঘ্য স্থির হয়, আপনি সম্পূর্ণরূপে এসওএইচ বাইট সরবরাহ করতে পারেন - কেবলমাত্র বৈধ চেক মানের জন্য প্রতিটি সম্ভাব্য শুরু অবস্থান পরীক্ষা করুন।

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


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

অবশ্যই, এটি সম্ভব তবে অনুশীলনে, যথেষ্ট শক্তিশালী এমন একটি চেক অ্যালগরিদম বাছাই করা তুলনামূলকভাবে সহজ।
ডেভ টুইট করেছেন

আপনার যদি ডেটা ত্রুটির একটি ননজারো হার থাকে তবে সর্বদা একটি ননজারো সুযোগ থাকে আপনি যেভাবেই কোনও অবৈধ বার্তা গ্রহণ করবেন।
নিক জনসন

@ নিক জোনসন একটি সম্পূর্ণ পরিচ্ছন্ন চ্যানেল ধরে নিচ্ছেন, এই পদ্ধতির সাথে এখনও (তাত্ত্বিকভাবে) মিল থাকবে না mat অবশ্যই তাদের সম্ভাবনা নগণ্য হতে পারে।
ইউজিন শ।

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

5

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

পাঠ্য এনকোডিংয়ের সুবিধা হ'ল আপনি ফ্রেমিংয়ের জন্য প্রিন্টযোগ্য অক্ষরগুলি ব্যবহার করতে পারেন। উদাহরণস্বরূপ, সবচেয়ে সহজ হ'ল 0x00ফ্রেমের সূচনা এবং ফ্রেমের 0xffশেষের জন্য চিহ্নিত করার মতো কিছু ব্যবহার করা ।

আমি পাঠ্য হিসাবে ডেটা এনকোড করা দুটি প্রধান উপায় দেখেছি:

  1. যখন কোনও হার্ডওয়্যার / অ্যাসেমব্লিং লোককে এটি করতে বলা হয় তখন সম্ভবত এটি হেক্স এনকোডিং হিসাবে কার্যকর করা হবে। এটি কেবল ASCII এ বাইটগুলি তাদের হেক্স মানগুলিতে রূপান্তর করছে। ওভারহেড বড় is মূলত আপনি প্রতিটি আসল ডেটা বাইটের জন্য দুটি বাইট প্রেরণ করবেন।

  2. যখন কোনও সফ্টওয়্যার লোককে এটি করতে বলা হয় তখন সম্ভবত এটি বেস 64 এনকোডিং হিসাবে প্রয়োগ করা হবে। এটি হ'ল ইন্টারনেটের ডি-ফ্যাক্টো এনকোডিং। ইমেল এমআইএমএইচ সংযুক্তি থেকে URL ডেটা এনকোডিং পর্যন্ত সমস্ত কিছুর জন্য ব্যবহৃত হয়। ওভারহেড হুবহু 33%। সাধারণ হেক্স এনকোডিংয়ের চেয়ে অনেক ভাল।

বিকল্পভাবে, আপনি বাইনারি ডেটা পুরোপুরি ছেড়ে দিতে এবং পাঠ্য প্রেরণ করতে পারেন। এই ক্ষেত্রে সর্বাধিক সাধারণ কৌশলটি হ'ল নিউলাইনের সাথে ডেটা সীমিত করা (হয় কেবল "\n"বা হয় "\r\n")। এনএমইএ (জিপিএস), মডেম এটিএম কমান্ড এবং অ্যাডভেনটেক এডএএম সেন্সর এর কয়েকটি সাধারণ উদাহরণ।

এই সমস্ত পাঠ্য-ভিত্তিক প্রোটোকল / ফ্রেমিংয়ের নিম্নলিখিত উপকারিতা এবং কনস রয়েছে:

প্রো:

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

কন:

  • খাঁটি বাইনারি সংক্রমণের তুলনায় খুব বড় ওভারহেড (তারপরে আবার পাঠ্য I / O এছাড়াও "0"চার বাইট 0x00000000 এর পরিবর্তে বাইট (0x30) প্রেরণ করার মতো সংখ্যাকে "সংক্ষেপণ" করতে পারে )
  • পিআইসির মতো খুব ছোট মাইক্রোতে প্রয়োগ করতে এত পরিষ্কার নয় (যদি না আপনার লাইব্রেরিতে কোনও sprintf()ফাংশন অন্তর্ভুক্ত থাকে)

ব্যক্তিগতভাবে আমার পক্ষে উপকারগুলি ভারী করে তুলনামূলক বেশি out একা ডিবাগিংয়ের স্বাচ্ছন্দ্য 5 পয়েন্ট হিসাবে গণনা করা হয় (যাতে একা একা পয়েন্ট ইতিমধ্যে উভয় কনসকে ছাড়িয়ে যায়)।


তারপরে সফ্টওয়্যার বলার কাছ থেকে প্রায়শই সাবধানতার সাথে চিন্তা-ভাবনাযুক্ত সমাধান আসে না: ফ্রেমিংয়ের কথা চিন্তা না করে এনকোডযুক্ত ডেটা প্রেরণ করুন।

আমাকে এমন হার্ডওয়ারের সাথে ইন্টারফেস করতে হয়েছিল যা অতীতে কাঁচা এক্সএমএল প্রেরণ করেছিল। এক্সএমএল সমস্ত ফ্রেম ছিল সেখানে। ভাগ্যক্রমে, <xml></xml>ট্যাগগুলির দ্বারা ফ্রেম সীমানা নির্ধারণ করা মোটামুটি সহজ । আমার কাছে বড় কনটি এটি ফ্রেমিংয়ের জন্য একাধিক বাইট ব্যবহার করে। এছাড়াও, ফ্রেমিং নিজেই ঠিক করা যায় না যেহেতু ট্যাগটিতে বৈশিষ্ট্য থাকতে পারে: <tag foo="bar"></tag>তাই ফ্রেমের শুরুটি খুঁজে পেতে আপনাকে সবচেয়ে খারাপ অবস্থার জন্য বাফার করতে হবে।

সম্প্রতি আমি দেখেছি লোকেরা সিরিয়াল বন্দরগুলির বাইরে জেএসএনকে প্রেরণ শুরু করে। JSON ফ্রেমিংয়ের সাথে সর্বোত্তম অনুমান। আপনি শুধুমাত্র আছে "{"(অথবা "[") ফ্রেম সনাক্ত করতে চরিত্র কিন্তু তারা তথ্য অন্তর্ভুক্ত করছি। সুতরাং ফ্রেমটি বের করার জন্য আপনার পুনরাবৃত্ত বংশদ্ভুত পার্সার (বা কমপক্ষে একটি ব্রেস কাউন্টার) প্রয়োজন। অন্তত বর্তমান ফ্রেমটি অকালে শেষ হয় কিনা তা জানার পক্ষে এটি তুচ্ছ: "}{"বা "]["জেএসএন-তে অবৈধ এবং এভাবে ইঙ্গিত দেয় যে পুরানো ফ্রেমটি শেষ হয়ে গেছে এবং একটি নতুন ফ্রেম শুরু হয়েছে।


পাঠ্য এনকোডিংগুলির জন্য এখানে বেস 85 রয়েছে , যার 33% এর পরিবর্তে কেবল 25% ওভারহেড রয়েছে।
ডেভ টুইট করেছেন

আমি এটিকে 4 র্থ পদ্ধতির একটি উপসেট / তারতম্য বিবেচনা করব।
ইউজিন শ।

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

4

আপনি "Xth বিট চিহ্নিতকরণ" হিসাবে যা বর্ণনা করেন তা অন্যান্য কোডগুলিতে সাধারণীকরণ করা যেতে পারে যা ধ্রুবক ভগ্নাংশের মাধ্যমে ডেটা প্রসারিত করার সম্পত্তি রাখে, কিছু কোডওয়ার্ডকে সীমানা হিসাবে ব্যবহারের জন্য মুক্ত রাখে। প্রায়শই এই কোডগুলি অন্যান্য সুবিধাও সরবরাহ করে; সিডিগুলিতে আট থেকে চৌদ্দটি মড্যুলেশন ব্যবহৃত হয় , যা প্রতিটি মধ্যে ১ টি বিটের সর্বোচ্চ রান দৈর্ঘ্যের গ্যারান্টি দেয় Other অন্যান্য উদাহরণগুলির মধ্যে রয়েছে ফরোয়ার্ড ত্রুটি সংশোধন ব্লক কোডগুলি , যা ত্রুটি সনাক্তকরণ এবং সংশোধন তথ্যকেও এনকোড করতে অতিরিক্ত বিট ব্যবহার করে।

আপনি উল্লেখ করেন নি এমন অন্য সিস্টেমটি হ'ল ব্যান্ড তথ্য, যেমন একটি চিপ সিলেক্ট লাইন ব্যবহার করে লেনদেন বা প্যাকেটগুলি সীমিত করে।


ত্রুটি সংশোধন কোডগুলি প্রশ্নের কিছুটা আলাদা। এগুলি যে কোনও উপায়ে যেকোন স্কিমে যুক্ত করা উচিত। আপনি যে "ব্যান্ডের তথ্য ছাড়াই" উল্লেখ করছেন সেটি "হার্ডওয়্যার ফ্লো কন্ট্রোল" এর মতোই বলে মনে করি?
ইউজিন শ।

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

@ ডেভিটউইড ওয়েল, প্রথম কৌশলটি দ্বারা আমি যা বোঝাতে চেয়েছি এটি বেশ অনেকটা। নাকি আমি আপনাকে ভুল বুঝাব?
ইউজিন শ।

না, আপনি ভুল বোঝাবুঝি করছেন না; এটাই আমি বলছিলাম তবে আপনার "কন" ভুল - এটি নির্ভরযোগ্য এবং এটি প্রকৃত সংক্রমণ ত্রুটির ক্ষেত্রেও শক্তিশালী করা যেতে পারে।
ডেভ টুইট করেছেন

@ ডেভটুইড পুনরুদ্ধারের সময় সম্পর্কে কী? কীভাবে এটি শক্তিশালী করা যায় তার কোনও উদাহরণ আপনার কাছে রয়েছে?
ইউজিন শ।

3

আর একটি বিকল্প লাইন কোডিং হিসাবে পরিচিত যা হয় । লাইন কোডিং সংকেতকে কিছু বৈদ্যুতিক বৈশিষ্ট্য দেয় যা প্রেরণে সহজ করে তোলে (ডিসি ভারসাম্য এবং সর্বাধিক রান দৈর্ঘ্যের গ্যারান্টি) এবং ফ্রেমিং এবং ক্লক সিঙ্ক্রোনাইজেশনের জন্য তারা নিয়ন্ত্রণ অক্ষরকে সমর্থন করে। লাইন কোডগুলি সমস্ত আধুনিক হাই স্পিড সিরিয়াল প্রোটোকলগুলিতে ব্যবহৃত হয় - 10 এম, 100 এম, 1 জি, এবং 10 জি ইথারনেট, সিরিয়াল এটিএ, ফায়ারওয়্যার, ইউএসবি 3, পিসিআই ইত্যাদি। লাইন কোডগুলি 8 বি / 10 বি , 64 বি / 66 বি এবং 128 বি / 130 বি হয়। আরও সহজ লাইন কোড রয়েছে যা ফ্রেমিং তথ্য সরবরাহ করে না, কেবল ডিসি ব্যালান্স এবং ক্লক সিঙ্ক। এর উদাহরণগুলি ম্যাচেস্টার এবং এনআরজেড। আপনি যদি খুব দ্রুত সিঙ্ক করতে চান তবে আপনি সম্ভবত 8 বি / 10 বি ব্যবহার করতে চান; অন্যান্য লাইন কোডগুলি তাড়াতাড়ি সিঙ্ক করার জন্য ডিজাইন করা হয়নি। উপরের মতো একটি লাইনের কোড ব্যবহারের জন্য প্রেরণ ও গ্রহণ করতে কাস্টম হার্ডওয়্যার ব্যবহার প্রয়োজন।

আপনার বিকল্প 5 হিসাবে, স্ট্যান্ডার্ড আরএস 232 সিরিয়ালটি বিরতি প্রেরণ এবং গ্রহণকে সমর্থন করার কথা রয়েছে যেখানে কয়েক বাইট সময় লাইনটি অলস থাকে। তবে এটি সমস্ত সিস্টেমে সমর্থিত নাও হতে পারে।

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


এটি নিক জনসনের উত্তরের মতোই।
ডেভ টুইট করেছেন
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.