কীভাবে একটি স্থির টিসিপি লিঙ্গ-চেঞ্জার প্রক্সি সেট আপ করবেন?


10

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

এটির সমাধানের একটি উপায় হ'ল একটি পরিষেবা যা আগত টিসিপি এ পোর্টকে অন্য টিসিপি পোর্ট বি এর সাথে সংযুক্ত করে, যাতে গ্রাহক বি এর সাথে বহির্মুখী সংযোগ স্থাপন করতে পারেন

এটি কোনও অনন্য সমস্যা নয় [1] [2] , এবং সকেটের সাহায্যে আমি যা চাই তার খুব কাছাকাছি করতে পারি:

socat -d -d -d -u TCP4-LISTEN:PORT-A,reuseaddr TCP4-LISTEN:PORT-B,reuseaddr

তবে এটির নিম্নলিখিত সমস্যাগুলি রয়েছে:

  • যদি বি সংযোগ বিচ্ছিন্ন হয়, এটি পুনরায় সংযোগ করতে পারে না। সহ TCP4-LISTEN:PORT-B,reuseaddr,fork, এটি সংযোগ করতে পারে তবে ডেটা গ্রহণ করে না।
  • A একটি সংযোগ স্থাপনের আগে বি সংযোগ করতে পারে না (surmountable)
  • শুধুমাত্র একটি সংযোগ স্থাপন করা যেতে পারে PORT-B(surmountable)

কমান্ডটি সামঞ্জস্য করার কোনও উপায় আছে যাতে এটি "পারমামেন্ট" হয়ে যায় এবং ব্যর্থতার প্রতিরোধী হয়?

উত্তর:


10

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

পরিষেবা socatহিসাবে সেট আপ সম্পর্কে কীভাবে [x]inetd?

আপনি xinetdপোর্ট-বিতে শুনবেন, এবং socat -u TCP4-LISTEN:PORT-A,reuseaddr STDIOবি-সাইড সংযোগের সাথে সাথেই এটি শুরু করবেন start

xinetdবি-পাশ থেকে স্ট্যান্ডার্ড ইনপুটটিতে আগত ট্র্যাফিককে পাস করবে socatএবং এর স্ট্যান্ডার্ড আউটপুট ধরবে socatএবং এটিকে বি-পাশ দিয়ে যাবে।

বি যদি সংযোগ বিচ্ছিন্ন করে দেয়, তবে socatপ্রক্রিয়াটি শেষ হওয়ার অনুমতি দেওয়া যেতে পারে; xinetdবি আবার সংযোগের সাথে সাথেই একটি নতুন শুরু করবে। বি সংযোগ বিচ্ছিন্ন থাকা অবস্থায়, এ "সংযোগ অস্বীকৃত" ত্রুটি পাবে।

আমাকে একবার পুরানো এইচপি-ইউএক্স সিস্টেমে বেশ অনুরূপ কিছু করতে হয়েছিল।


একটি সংযোগ হারিয়ে যাওয়ার জন্য একটি বিরতিতে পুনরায় সংযোগ করার চেষ্টা করবে, যাতে এটি আবৃত থাকে। xinetd দেখে মনে হচ্ছে এটি কাজ করতে পারে। চেষ্টা করে আবার রিপোর্ট করবে, ধন্যবাদ!
dtech

এটি সর্বাধিক গুরুত্বপূর্ণ সমস্যার সমাধান করে: যে পরিষেবাগুলি ব্যর্থতার উপর পুনরায় সংযোগ স্থাপন করতে পারে। ধন্যবাদ!
dtech

3

আসল পৃথিবী অগোছালো।

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

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

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

তদুপরি টিসিপি সংযোগগুলি বাইটের স্রোত, বার্তাগুলির স্রোত নয়, সুতরাং যখন আপনার সংযোগটি মারা যায় আপনি একটি আংশিক বার্তা পেতে পারেন।

এর নেট ফলাফলটি আমাকে এই সিদ্ধান্তে নিয়ে যায় যে একটি শক্তিশালী সমাধানের জন্য অ্যাপ্লিকেশন প্রোটোকলের একটি বোঝার প্রয়োজন হয় যাতে আপনার সমাধান বুঝতে পারে।

  1. যখন কোনও নতুন সংযোগ আসবে তখন কীভাবে স্ট্রিমগুলি স্প্লাইস করবেন।
  2. ডেটা উত্সটি যখন তথ্য প্রাপক দ্বারা সংযুক্ত থাকে তখন বার্তাগুলি সংরক্ষণ করা উচিত।
  3. স্বীকৃতি প্রক্রিয়া শেষ করার কোনও বার্তা বার্তা হ্রাস রোধ করার জন্য উপযুক্ত কিনা।
  4. মৃত সংযোগগুলি সনাক্ত করার জন্য কোনও ধরণের অ্যাপ্লিকেশন স্তরের "পিং" প্রক্রিয়া প্রয়োজন কিনা mechanism

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