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

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

সুচিপত্র:

• ডকুমেন্টেশন... এটা বিদ্যমান, তাই না? এটা সত্যি?..
• একজন তরুণ লেখক হিসেবে কোথায় শুরু করবেন?
• বাইনারি সিরিয়ালাইজেশন: TL (টাইপ ল্যাঙ্গুয়েজ) এবং এর স্কিম, এবং লেয়ার, এবং অন্যান্য অনেক ভয়ঙ্কর শব্দ
  • যারা অফিসিয়াল ডকুমেন্টেশন পড়তে চান না তাদের জন্য TL সিনট্যাক্সের একটি উপসেটের একটি সংক্ষিপ্ত বিবরণ
  • ভেক্টর, যা কখনই মুক্তি পায়নি
  • কোডে বিদ্যমান TL বাস্তবায়ন
  • টাইপ ভাষার অভাব
  • সংস্করণ করা। স্তর
• এমটিপিপ্রোটো
  • পরিবহন স্তর
  • কী, বার্তা, সেশন, ডিফি-হেলম্যান
  • বার্তা বার্তা, msg_id, msg_seqno, নিশ্চিতকরণ, ভুল দিকে পিং এবং অন্যান্য বৈচিত্র্য
    • RPC: অনুরোধ, প্রতিক্রিয়া, ত্রুটি। নিশ্চিতকরণ
    • মাদকাসক্তি: বার্তা স্ট্যাটাস
    • পিং এবং সময়. সারি।
    • এটা কিভাবে ডিজাইন করা উচিত ছিল?
• এপিআই?
• চলবে!

ডকুমেন্টেশন... এটা বিদ্যমান, তাই না? এটা সত্যি?..

এই নিবন্ধটির জন্য নোটের টুকরো গত গ্রীষ্মে সংগ্রহ করা শুরু হয়েছিল। অফিসিয়াল ওয়েবসাইটে এই সব সময় https://core.telegram.org ডকুমেন্টেশন লেয়ার 23 হিসাবে ছিল, অর্থাৎ 2014 সালে কোথাও আটকে গেছে (মনে রাখবেন, তখনও চ্যানেল ছিল না?) অবশ্যই, তাত্ত্বিকভাবে, এটি আমাদের 2014 সালে সেই সময়ে কার্যকারিতা সহ একটি ক্লায়েন্ট বাস্তবায়নের অনুমতি দেওয়া উচিত ছিল। কিন্তু এই অবস্থায়ও, ডকুমেন্টেশন ছিল, প্রথমত, অসম্পূর্ণ, এবং দ্বিতীয়ত, বিভিন্ন জায়গায় এটি নিজেই বিরোধিতা করেছিল। মাত্র এক মাস আগে, 2019 সালের সেপ্টেম্বরে, এটি ছিল ঘটনাক্রমে এটি আবিষ্কৃত হয়েছিল যে সাইটটিতে ডকুমেন্টেশনের একটি বড় আপডেট ছিল, সম্পূর্ণ সাম্প্রতিক স্তর 105 এর জন্য, একটি নোট সহ যে এখন সবকিছু আবার পড়তে হবে। প্রকৃতপক্ষে, অনেক নিবন্ধ সংশোধন করা হয়েছিল, কিন্তু অনেকগুলি অপরিবর্তিত ছিল। অতএব, ডকুমেন্টেশন সম্পর্কে নীচের সমালোচনা পড়ার সময়, আপনার মনে রাখা উচিত যে এই জিনিসগুলির মধ্যে কিছু আর প্রাসঙ্গিক নয়, তবে কিছু এখনও যথেষ্ট। সর্বোপরি, আধুনিক বিশ্বে 5 বছর কেবল একটি দীর্ঘ সময় নয়, তবে খুব অনেক সেই সময় থেকে (বিশেষত যদি আপনি বাতিল করা এবং পুনরুজ্জীবিত জিওচ্যাট সাইটগুলিকে বিবেচনায় না নেন তখন থেকে), স্কিমে API পদ্ধতির সংখ্যা একশ থেকে দুইশ পঞ্চাশের বেশি হয়ে গেছে!

একজন তরুণ লেখক হিসেবে কোথায় শুরু করবেন?

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

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

এবং যদি আপনি স্ক্র্যাচ থেকে লেখেন, তাহলে প্রাপ্ত প্যারামিটারগুলি ব্যবহার করা আসলে এখনও অনেক দূরে। যদিও https://core.telegram.org/ এবং প্রথমে শুরুতে সেগুলি সম্পর্কে আলোচনা করে, আসলে, আপনাকে প্রথমে বাস্তবায়ন করতে হবে MTProto প্রোটোকল - কিন্তু তুমি যদি বিশ্বাস কর OSI মডেল অনুযায়ী লেআউট প্রোটোকলের একটি সাধারণ বিবরণের জন্য পৃষ্ঠার শেষে, তারপর এটি সম্পূর্ণরূপে বৃথা।

প্রকৃতপক্ষে, MTProto-এর আগে এবং পরে উভয়ই, একসাথে বেশ কয়েকটি স্তরে (যেমন OS কার্নেলে কাজ করা বিদেশী নেটওয়ার্কাররা বলছেন, স্তর লঙ্ঘন), একটি বড়, বেদনাদায়ক এবং ভয়ানক বিষয় আসবে...

বাইনারি সিরিয়ালাইজেশন: TL (টাইপ ল্যাঙ্গুয়েজ) এবং এর স্কিম, এবং লেয়ার, এবং অন্যান্য অনেক ভয়ঙ্কর শব্দ

এই বিষয়টি, আসলে, টেলিগ্রামের সমস্যার মূল। এবং আপনি যদি এটি গভীরভাবে অনুসন্ধান করার চেষ্টা করেন তবে অনেক ভয়ঙ্কর শব্দ থাকবে।

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

int ? = Int;
long ? = Long;
double ? = Double;
string ? = String;

vector#1cb5c415 {t:Type} # [ t ] = Vector t;

rpc_error#2144ca19 error_code:int error_message:string = RpcError;

rpc_answer_unknown#5e2ad36e = RpcDropAnswer;
rpc_answer_dropped_running#cd78e586 = RpcDropAnswer;
rpc_answer_dropped#a43ad8b7 msg_id:long seq_no:int bytes:int = RpcDropAnswer;

msg_container#73f1f8dc messages:vector<%Message> = MessageContainer;

---functions---

set_client_DH_params#f5045f1f nonce:int128 server_nonce:int128 encrypted_data:bytes = Set_client_DH_params_answer;

ping#7abe77ec ping_id:long = Pong;
ping_delay_disconnect#f3427b8c ping_id:long disconnect_delay:int = Pong;

invokeAfterMsg#cb9f372d msg_id:long query:!X = X;
invokeAfterMsgs#3dc4b4f0 msg_ids:Vector<long> query:!X = X;

account.updateProfile#78515775 flags:# first_name:flags.0?string last_name:flags.1?string about:flags.2?string = User;
account.sendChangePhoneCode#8e57deb flags:# allow_flashcall:flags.0?true phone_number:string current_number:flags.0?Bool = auth.SentCode;

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

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

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

• হ্যাঁ, цель ভাল শোনাচ্ছে, কিন্তু হায়, সে অর্জিত না
• রাশিয়ান বিশ্ববিদ্যালয়গুলিতে শিক্ষা এমনকি আইটি বিশেষত্বের মধ্যেও পরিবর্তিত হয় - প্রত্যেকেই সংশ্লিষ্ট কোর্স গ্রহণ করেনি
• অবশেষে, আমরা দেখতে পাব, বাস্তবে তা হয় প্রয়োজন নেই, যেহেতু বর্ণনা করা হয়েছে এমন TL-এর শুধুমাত্র একটি সীমিত উপসেট ব্যবহার করা হয়েছে

যেমন বললে লিওনার্ড চ্যানেলে #perl ফ্রিনোড আইআরসি নেটওয়ার্কে, যিনি টেলিগ্রাম থেকে ম্যাট্রিক্সে একটি গেট বাস্তবায়নের চেষ্টা করেছিলেন (উদ্ধৃতিটির অনুবাদ মেমরি থেকে ভুল):

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

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

কিন্তু আগে

যারা অফিসিয়াল ডকুমেন্টেশন পড়েন না তাদের জন্য TL সিনট্যাক্সের একটি উপসেটের সংক্ষিপ্ত বিবরণ

constructor = Type;
myVec ids:Vector<long> = Type;

fixed#abcdef34 id:int = Type2;

fixedVec set:Vector<Type2> = FixedVec;

constructorOne#crc32 field1:int = PolymorType;
constructorTwo#2crc32 field_a:long field_b:Type3 field_c:int = PolymorType;
constructorThree#deadcrc bit_flags_of_what_really_present:# optional_field4:bit_flags_of_what_really_present.1?Type = PolymorType;

an_id#12abcd34 id:int = Type3;
a_null#6789cdef = Type3;

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

যদি লাইনের পরে সংজ্ঞা হয় ---functions---, তাহলে সিনট্যাক্স একই থাকবে, কিন্তু অর্থ ভিন্ন হবে: কনস্ট্রাক্টর RPC ফাংশনের নাম হয়ে যাবে, ক্ষেত্রগুলি পরামিতি হয়ে যাবে (ভাল, অর্থাৎ, এটি ঠিক একই প্রদত্ত কাঠামো থাকবে, যেমন নীচে বর্ণিত হয়েছে , এটি কেবল নির্ধারিত অর্থ হবে), এবং "পলিমরফিক টাইপ " - প্রত্যাবর্তিত ফলাফলের প্রকার। সত্য, এটি এখনও বহুরূপী থাকবে - শুধু বিভাগে সংজ্ঞায়িত করা হয়েছে ---types---, কিন্তু এই কনস্ট্রাক্টর "বিবেচনা করা হবে না"। তাদের আর্গুমেন্ট দ্বারা কল ফাংশন ধরনের ওভারলোডিং, যেমন কিছু কারণে, একই নামের কিন্তু ভিন্ন স্বাক্ষর সহ বেশ কয়েকটি ফাংশন, যেমন C++, TL-তে দেওয়া হয় না।

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

এটা কিভাবে হয়? deserializer, যা সর্বদা 4 বাইট পড়ে, মান দেখে 0xcrc32 - এবং বুঝতে পারে পরবর্তী কি হবে field1 টাইপ সহ int, অর্থাৎ ঠিক 4 বাইট পড়ে, এর উপর টাইপ সহ ওভারলাইং ফিল্ড PolymorType পড়া দেখে 0x2crc32 এবং বুঝতে পারে যে আরও দুটি ক্ষেত্র রয়েছে, প্রথম long, যার মানে আমরা 8 বাইট পড়ি। এবং তারপর আবার একটি জটিল ধরনের, যা একই ভাবে deserialized হয়. উদাহরণ স্বরূপ, Type3 যথাক্রমে দুটি কনস্ট্রাক্টরের সাথে সাথে সার্কিটে ঘোষণা করা যেতে পারে, তারপর তাদের অবশ্যই দেখা হবে 0x12abcd34, তারপরে আপনাকে আরও 4 বাইট পড়তে হবে int, বা 0x6789cdef, তারপর কিছুই হবে না. অন্য কিছু - আপনাকে একটি ব্যতিক্রম নিক্ষেপ করতে হবে। যাইহোক, এর পরে আমরা 4 বাইট পড়তে ফিরে যাই int ক্ষেত্র field_c в constructorTwo এবং এর সাথে আমরা আমাদের পড়া শেষ করি PolymorType.

অবশেষে ধরা পড়লে 0xdeadcrc থেকে constructorThree, তারপর সবকিছু আরও জটিল হয়ে ওঠে। আমাদের প্রথম মাঠ bit_flags_of_what_really_present টাইপ সহ # - আসলে, এটি টাইপের জন্য একটি উপনাম nat, মানে "প্রাকৃতিক সংখ্যা"। যে, প্রকৃতপক্ষে, স্বাক্ষরবিহীন int হল, উপায় দ্বারা, একমাত্র ক্ষেত্রে যখন স্বাক্ষরবিহীন সংখ্যা বাস্তব সার্কিটে ঘটে। সুতরাং, পরবর্তীটি একটি প্রশ্নবোধক চিহ্ন সহ একটি নির্মাণ, যার অর্থ এই ক্ষেত্রটি - এটি কেবলমাত্র তারের উপর উপস্থিত থাকবে যদি সংশ্লিষ্ট বিটটি উল্লেখ করা ক্ষেত্রে সেট করা থাকে (প্রায় একটি টার্নারি অপারেটরের মতো)। সুতরাং, ধরে নেওয়া যাক যে এই বিটটি সেট করা হয়েছিল, যার মানে আরও আমাদের একটি ক্ষেত্র পড়তে হবে Type, যা আমাদের উদাহরণে 2টি কনস্ট্রাক্টর রয়েছে। একটি খালি (শুধুমাত্র শনাক্তকারী নিয়ে গঠিত), অন্যটির একটি ক্ষেত্র রয়েছে ids টাইপ সহ ids:Vector<long>.

আপনি ভাবতে পারেন যে টেমপ্লেট এবং জেনেরিক উভয়ই পেশাদার বা জাভাতে রয়েছে। কিন্তু না. প্রায়। এই শুধুমাত্র বাস্তব সার্কিটে কোণ বন্ধনী ব্যবহার করার ক্ষেত্রে, এবং এটি শুধুমাত্র ভেক্টরের জন্য ব্যবহৃত হয়। একটি বাইট স্ট্রীমে, এগুলি ভেক্টর টাইপের জন্য 4 CRC32 বাইট হবে, সর্বদা একই, তারপর 4 বাইট - অ্যারের উপাদানগুলির সংখ্যা এবং তারপরে এই উপাদানগুলি নিজেই।

এর সাথে যোগ করুন যে সিরিয়ালাইজেশন সর্বদা 4 বাইটের শব্দে ঘটে, সমস্ত প্রকার এটির গুণিতক - অন্তর্নির্মিত প্রকারগুলিও বর্ণনা করা হয়েছে bytes и string দৈর্ঘ্যের ম্যানুয়াল সিরিয়ালাইজেশন এবং 4 দ্বারা এই প্রান্তিককরণের সাথে - ভাল, এটি স্বাভাবিক এবং এমনকি তুলনামূলকভাবে কার্যকর বলে মনে হচ্ছে? যদিও TL কে একটি কার্যকর বাইনারি সিরিয়ালাইজেশন বলে দাবি করা হয়, তাদের সাথে জাহান্নামে, প্রায় কিছুর সম্প্রসারণ সহ, এমনকি বুলিয়ান মান এবং একক-অক্ষর স্ট্রিং 4 বাইটে, JSON কি এখনও অনেক মোটা হবে? দেখুন, এমনকি অপ্রয়োজনীয় ক্ষেত্রগুলিও বিট ফ্ল্যাগ দ্বারা এড়িয়ে যেতে পারে, সবকিছুই বেশ ভাল, এমনকি ভবিষ্যতের জন্যও এক্সটেনসিবল, তাহলে কেন পরবর্তীতে কনস্ট্রাক্টরে নতুন ঐচ্ছিক ক্ষেত্র যুক্ত করবেন না?...

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

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

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

অবশেষে, ঠিক আছে, আমরা বুঝতে পেরেছি যে একটি ক্ষেত্রের ধরন সহ নির্মাতারা Vector<int> и Vector<PolymorType> আলাদা CRC32 থাকবে। অনলাইন কর্মক্ষমতা সম্পর্কে কি? এবং তাত্ত্বিক দৃষ্টিকোণ থেকে, এই ধরনের অংশ হয়ে ওঠে? ধরা যাক আমরা দশ হাজার সংখ্যার একটি অ্যারে পাস করি Vector<int> সবকিছু পরিষ্কার, দৈর্ঘ্য এবং আরও 40000 বাইট। এই হলে কি হবে Vector<Type2>, যা শুধুমাত্র একটি ক্ষেত্র নিয়ে গঠিত int এবং এটি টাইপের মধ্যে একা - আমাদের কি 10000xabcdef0 34 বার এবং তারপর 4 বাইট পুনরাবৃত্তি করতে হবে? int, অথবা ভাষা আমাদের জন্য কনস্ট্রাক্টর থেকে এটি স্বাধীন করতে সক্ষম fixedVec এবং 80000 বাইটের পরিবর্তে, আবার শুধুমাত্র 40000 স্থানান্তর?

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

তাই…

ভেক্টর, যা কখনই মুক্তি পায়নি

আপনি যদি কম্বিনেটর ইত্যাদির বর্ণনার পৃষ্ঠাগুলি ঘুরে দেখার চেষ্টা করেন তবে আপনি দেখতে পাবেন যে একটি ভেক্টর (এবং এমনকি একটি ম্যাট্রিক্স) আনুষ্ঠানিকভাবে বেশ কয়েকটি শীটের টিপলের মাধ্যমে আউটপুট হওয়ার চেষ্টা করছে। কিন্তু শেষ পর্যন্ত তারা ভুলে যায়, চূড়ান্ত ধাপটি বাদ দেওয়া হয়, এবং একটি ভেক্টরের একটি সংজ্ঞা দেওয়া হয়, যা এখনও একটি প্রকারের সাথে বাঁধা হয়নি। কি ব্যাপার? ভাষায় প্রোগ্রামিং, বিশেষ করে কার্যকরী, কাঠামোটিকে পুনরাবৃত্তিমূলকভাবে বর্ণনা করা বেশ সাধারণ - এর অলস মূল্যায়ন সহ কম্পাইলার নিজেই সবকিছু বুঝতে পারবে এবং করবে। ভাষায় ডেটা সিরিয়ালাইজেশন যা প্রয়োজন তা হ'ল দক্ষতা: এটি কেবল বর্ণনা করাই যথেষ্ট তালিকা, অর্থাৎ দুটি উপাদানের গঠন - প্রথমটি একটি ডেটা উপাদান, দ্বিতীয়টি একই কাঠামো বা লেজের জন্য একটি খালি স্থান (প্যাক (cons) লিস্পে)। কিন্তু এই স্পষ্টতই প্রয়োজন হবে প্রতিটি উপাদানটি তার প্রকার বর্ণনা করতে অতিরিক্ত 4 বাইট (TL-এর ক্ষেত্রে CRC32) ব্যয় করে। একটি অ্যারেও সহজেই বর্ণনা করা যায় নির্দিষ্ট আকার, কিন্তু আগাম অজানা দৈর্ঘ্যের একটি বিন্যাসের ক্ষেত্রে, আমরা বন্ধ হয়ে যাই।

অতএব, যেহেতু TL একটি ভেক্টর আউটপুট করার অনুমতি দেয় না, তাই এটিকে পাশে যোগ করতে হয়েছিল। শেষ পর্যন্ত ডকুমেন্টেশন বলে:

সিরিয়ালাইজেশন সবসময় একই কনস্ট্রাক্টর "ভেক্টর" ব্যবহার করে (const 0x1cb5c415 = crc32("ভেক্টর t:Type # [ t ] = Vector t") যা t টাইপের ভেরিয়েবলের নির্দিষ্ট মানের উপর নির্ভর করে না।

ঐচ্ছিক পরামিতি t-এর মানটি ক্রমিককরণের সাথে জড়িত নয় কারণ এটি ফলাফলের ধরন থেকে প্রাপ্ত (সর্বদা ডিসিরিয়ালাইজেশনের আগে পরিচিত)।

আপনি সব: vector {t:Type} # [ t ] = Vector t - কিন্তু কোথাও না এই সংজ্ঞা নিজেই বলে না যে প্রথম সংখ্যাটি ভেক্টরের দৈর্ঘ্যের সমান হতে হবে! এবং এটি কোথাও থেকে আসে না। এটি এমন একটি প্রদত্ত যা মনে রাখা এবং আপনার হাতে প্রয়োগ করা দরকার। অন্যত্র, ডকুমেন্টেশন এমনকি সততার সাথে উল্লেখ করে যে প্রকারটি বাস্তব নয়:

ভেক্টর টি পলিমরফিক সিউডোটাইপ হল একটি "টাইপ" যার মান হল বাক্সযুক্ত বা বেয়ার যেকোন ধরনের টি মানের ক্রম।

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

উপায় দ্বারা, সংখ্যা সম্পর্কে. আমাদের আপনাকে মনে করিয়ে দেওয়া যাক # এটি একটি প্রতিশব্দ nat, প্রাকৃতিক সংখ্যা:

টাইপ এক্সপ্রেশন আছে (টাইপ-এক্সপ্র) এবং সংখ্যাসূচক অভিব্যক্তি (nat-এক্সপ্র) যাইহোক, তারা একই ভাবে সংজ্ঞায়িত করা হয়।

type-expr ::= expr
nat-expr ::= expr

কিন্তু ব্যাকরণে তারা একইভাবে বর্ণনা করা হয়েছে, যেমন এই পার্থক্যটি আবার মনে রাখতে হবে এবং ম্যানুয়ালি বাস্তবায়ন করতে হবে।

আচ্ছা, হ্যাঁ, টেমপ্লেটের ধরন (vector<int>, vector<User>) একটি সাধারণ শনাক্তকারী আছে (#1cb5c415), i.e. আপনি যদি জানেন যে কল হিসাবে ঘোষণা করা হয়

users.getUsers#d91a548 id:Vector<InputUser> = Vector<User>;

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

এই মুহুর্তে আপনি ভাবতে শুরু করেন - এমন একটি টিএল কি প্রয়োজনীয়? হয়তো কার্টের জন্য মানব সিরিয়ালাইজার ব্যবহার করা সম্ভব হবে, একই প্রোটোবাফ যা ইতিমধ্যে বিদ্যমান ছিল? এটাই ছিল তত্ত্ব, চলুন অনুশীলন দেখি।

কোডে বিদ্যমান TL বাস্তবায়ন

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

Templates are not used now. Instead, the same universal constructors (for example, vector {t:Type} [t] = Vector t) are used w

কিন্তু আমাদের বিবেচনা করা যাক, সম্পূর্ণতার খাতিরে, ট্রেস করার জন্য, তাই বলতে গেলে, চিন্তার দৈত্যের বিবর্তন।

#define ZHUKOV_BYTES_HACK

#ifdef ZHUKOV_BYTES_HACK

/* dirty hack for Zhukov request */

অথবা এই সুন্দর একটি:

    static const char *reserved_words_polymorhic[] = {

      "alpha", "beta", "gamma", "delta", "epsilon", "zeta", "eta", "theta", NULL

      };

এই খণ্ডটি টেমপ্লেট সম্পর্কে:

intHash {alpha:Type} vector<coupleInt<alpha>> = IntHash<alpha>;

এটি একটি হ্যাশম্যাপ টেমপ্লেট টাইপের সংজ্ঞা int - টাইপ জোড়ার ভেক্টর হিসাবে। C++ এ এটি দেখতে এরকম কিছু হবে:

    template <T> class IntHash {
      vector<pair<int,T>> _map;
    }

তাই, alpha - কীওয়ার্ড! কিন্তু শুধুমাত্র C++ এ আপনি T লিখতে পারেন, কিন্তু আপনাকে আলফা, বিটা লিখতে হবে... কিন্তু 8টির বেশি প্যারামিটার নয়, এখানেই ফ্যান্টাসি শেষ হয়। মনে হচ্ছে সেন্ট পিটার্সবার্গে এক সময় এরকম কিছু সংলাপ হয়েছিল:

-- Надо сделать в TL шаблоны
-- Бл... Ну пусть параметры зовут альфа, бета,... Какие там ещё буквы есть... О, тэта!
-- Грамматика? Ну потом напишем

-- Смотрите, какой я синтаксис придумал для шаблонов и вектора!
-- Ты долбанулся, как мы это парсить будем?
-- Да не ссыте, он там один в схеме, захаркодить -- и ок

কিন্তু এটি TL এর প্রথম প্রকাশিত বাস্তবায়ন সম্পর্কে ছিল "সাধারণভাবে"। আসুন টেলিগ্রাম ক্লায়েন্টদের নিজেদের মধ্যে বাস্তবায়ন বিবেচনা করা যাক।

ভ্যাসিলির কাছে শব্দ:

ভ্যাসিলি, [09.10.18 17:07] সর্বোপরি, গাধাটি গরম কারণ তারা একগুচ্ছ বিমূর্ততা তৈরি করেছিল এবং তারপরে তাদের উপর একটি বোল্ট মেরেছিল এবং কোড জেনারেটরটিকে ক্রাচ দিয়ে ঢেকে দেয়।
ফলস্বরূপ, প্রথমে ডক পাইলট.জেপিজি থেকে
তারপর dzhekichan.webp কোড থেকে

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

দ্বারা টেলিগ্রাম-cli ভাইটালি ভ্যাল্টম্যান, টিএলও ফরম্যাটের (cli) সীমানার বাইরের ঘটনা থেকে বোঝা যায়, দলের একজন সদস্য - এখন TL পার্সিংয়ের জন্য একটি লাইব্রেরি বরাদ্দ করা হয়েছে আলাদাভাবে, কি তার ছাপ TL পার্সার? ..

16.12 04:18 ভ্যাসিলি: আমার মনে হয় কেউ lex+yacc আয়ত্ত করেনি
16.12 04:18 ভ্যাসিলি: আমি অন্যথায় ব্যাখ্যা করতে পারব না
16.12 04:18 ভ্যাসিলি: ভাল, অথবা তাদের ভিকে লাইনের সংখ্যার জন্য অর্থ প্রদান করা হয়েছিল
16.12 04:19 ভ্যাসিলি: 3k+ লাইন ইত্যাদি<censored> একটি পার্সার পরিবর্তে

সম্ভবত একটি ব্যতিক্রম? দেখা যাক কিভাবে করে এটি অফিসিয়াল ক্লায়েন্ট - টেলিগ্রাম ডেস্কটপ:

    nametype = re.match(r'([a-zA-Z.0-9_]+)(#[0-9a-f]+)?([^=]*)=s*([a-zA-Z.<>0-9_]+);', line);
    if (not nametype):
      if (not re.match(r'vector#1cb5c415 {t:Type} # [ t ] = Vector t;', line)):
         print('Bad line found: ' + line);

পাইথনে 1100+ লাইন, কয়েকটি নিয়মিত এক্সপ্রেশন + একটি ভেক্টরের মতো বিশেষ ক্ষেত্রে, যা অবশ্যই, টিএল সিনট্যাক্স অনুসারে হওয়া উচিত হিসাবে স্কিমে ঘোষণা করা হয়েছে, তবে তারা এটি পার্স করার জন্য এই সিনট্যাক্সের উপর নির্ভর করেছিল ... প্রশ্ন জাগে, কেন সব অলৌকিক ছিল?иএটি আরও স্তরযুক্ত যদি যাইহোক ডকুমেন্টেশন অনুসারে কেউ এটি পার্স করতে যাচ্ছে না?!

যাইহোক... মনে আছে আমরা CRC32 চেক করার কথা বলেছিলাম? সুতরাং, টেলিগ্রাম ডেস্কটপ কোড জেনারেটরে সেই ধরণের ব্যতিক্রমগুলির একটি তালিকা রয়েছে যেখানে গণনা করা CRC32 মেলে না ডায়াগ্রামে নির্দেশিত এক সঙ্গে!

ভ্যাসিলি, [18.12/22 49:XNUMX] এবং এখানে আমি এই ধরনের টিএল প্রয়োজন কিনা তা নিয়ে ভাবব
যদি আমি বিকল্প বাস্তবায়নের সাথে তালগোল পাকিয়ে ফেলতে চাই, আমি লাইন বিরতি সন্নিবেশ করা শুরু করব, অর্ধেক পার্সার বহু-লাইন সংজ্ঞায় ভাঙবে
tdesktop, তবে, খুব

ওয়ান-লাইনার সম্পর্কে পয়েন্টটি মনে রাখবেন, আমরা একটু পরে এটিতে ফিরে যাব।

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

সিরিয়ালাইজেশন অনুশীলনে অন্য কোন প্রশ্ন উত্থাপন করে? উদাহরণস্বরূপ, তারা অনেক কিছু করেছে, অবশ্যই, বিট ক্ষেত্র এবং শর্তাধীন ক্ষেত্রগুলির সাথে:

ভ্যাসিলি: flags.0? true
ক্ষেত্রটি উপস্থিত এবং পতাকা সেট করা থাকলে সমান সত্য

ভ্যাসিলি: flags.1? int
এর মানে হল যে ক্ষেত্রটি বর্তমান এবং ডিসিরিয়ালাইজ করা দরকার

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

টেলিথন সম্পর্কে কি? MTProto বিষয়ের দিকে তাকিয়ে, একটি উদাহরণ - ডকুমেন্টেশনে এই ধরনের টুকরা আছে, কিন্তু সাইন % এটি শুধুমাত্র "প্রদত্ত বেয়ার-টাইপের সাথে সম্পর্কিত" হিসাবে বর্ণনা করা হয়েছে, যেমন নীচের উদাহরণগুলিতে একটি ত্রুটি বা নথিভুক্ত কিছু আছে:

ভ্যাসিলি, [22.06.18 18:38] এক জায়গায়:

msg_container#73f1f8dc messages:vector message = MessageContainer;

ভিন্নভাবে:

msg_container#73f1f8dc messages:vector<%Message> = MessageContainer;

এবং এই দুটি বড় পার্থক্য, বাস্তব জীবনে একধরনের নগ্ন ভেক্টর আসে

আমি একটি বেয়ার ভেক্টর সংজ্ঞা দেখিনি এবং একটি জুড়ে আসিনি

বিশ্লেষণ টেলিথনে হাতে লেখা হয়

তার ডায়াগ্রামে সংজ্ঞাটি মন্তব্য করা হয়েছে msg_container

আবার, প্রশ্নটি % সম্পর্কে রয়ে গেছে। এটা বর্ণনা করা হয় না.

ভাদিম গনচারভ, [22.06.18 19:22] এবং tdesktop এ?

ভ্যাসিলি, [22.06.18 19:23] তবে নিয়মিত ইঞ্জিনে তাদের TL পার্সার সম্ভবত এটিও খাবে না

// parsed manually

TL একটি সুন্দর বিমূর্ততা, কেউ এটি সম্পূর্ণরূপে প্রয়োগ করে না

এবং % তাদের স্কিমের সংস্করণে নেই

কিন্তু এখানে ডকুমেন্টেশন নিজেই বিপরীত, তাই idk

এটা ব্যাকরণে পাওয়া গেছে, তারা সহজভাবে শব্দার্থক বর্ণনা করতে ভুলে যেতে পারে

আপনি টিএল-এ নথিটি দেখেছেন, আপনি আধা লিটার ছাড়া এটি বের করতে পারবেন না

"ঠিক আছে, আসুন বলি," অন্য পাঠক বলবে, "আপনি কিছু সমালোচনা করেন, তাই আমাকে দেখান কিভাবে এটি করা উচিত।"

ভ্যাসিলি উত্তর দেয়: "পার্সারের জন্য, আমি এর মতো জিনিস পছন্দ করি

    args: /* empty */ { $$ = NULL; }
        | args arg { $$ = g_list_append( $1, $2 ); }
        ;

    arg: LC_ID ':' type-term { $$ = tl_arg_new( $1, $3 ); }
            | LC_ID ':' condition '?' type-term { $$ = tl_arg_new_cond( $1, $5, $3 ); free($3); }
            | UC_ID ':' type-term { $$ = tl_arg_new( $1, $3 ); }
            | type-term { $$ = tl_arg_new( "", $1 ); }
            | '[' LC_ID ']' { $$ = tl_arg_new_mult( "", tl_type_new( $2, TYPE_MOD_NONE ) ); }
            ;

একরকমের চেয়ে ভালো লাগে

struct tree *parse_args4 (void) {
  PARSE_INIT (type_args4);
  struct parse so = save_parse ();
  PARSE_TRY (parse_optional_arg_def);
  if (S) {
    tree_add_child (T, S);
  } else {
    load_parse (so);
  }
  if (LEX_CHAR ('!')) {
    PARSE_ADD (type_exclam);
    EXPECT ("!");
  }
  PARSE_TRY_PES (parse_type_term);
  PARSE_OK;
}

বা

        # Regex to match the whole line
        match = re.match(r'''
            ^                  # We want to match from the beginning to the end
            ([w.]+)           # The .tl object can contain alpha_name or namespace.alpha_name
            (?:
                #             # After the name, comes the ID of the object
                ([0-9a-f]+)    # The constructor ID is in hexadecimal form
            )?                 # If no constructor ID was given, CRC32 the 'tl' to determine it

            (?:s              # After that, we want to match its arguments (name:type)
                {?             # For handling the start of the '{X:Type}' case
                w+            # The argument name will always be an alpha-only name
                :              # Then comes the separator between name:type
                [wd<>#.?!]+  # The type is slightly more complex, since it's alphanumeric and it can
                               # also have Vector<type>, flags:# and flags.0?default, plus :!X as type
                }?             # For handling the end of the '{X:Type}' case
            )*                 # Match 0 or more arguments
            s                 # Leave a space between the arguments and the equal
            =
            s                 # Leave another space between the equal and the result
            ([wd<>#.?]+)     # The result can again be as complex as any argument type
            ;$                 # Finally, the line should always end with ;
            ''', tl, re.IGNORECASE | re.VERBOSE)

এটি পুরো লেক্সার:

    ---functions---         return FUNCTIONS;
    ---types---             return TYPES;
    [a-z][a-zA-Z0-9_]*      yylval.string = strdup(yytext); return LC_ID;
    [A-Z][a-zA-Z0-9_]*      yylval.string = strdup(yytext); return UC_ID;
    [0-9]+                  yylval.number = atoi(yytext); return NUM;
    #[0-9a-fA-F]{1,8}       yylval.number = strtol(yytext+1, NULL, 16); return ID_HASH;

    n                      /* skip new line */
    [ t]+                  /* skip spaces */
    //.*$                 /* skip comments */
    /*.**/              /* skip comments */
    .                       return (int)yytext[0];

সেগুলো. সহজতর হল এটিকে হালকাভাবে রাখা।"

সাধারণভাবে, ফলস্বরূপ, TL-এর প্রকৃতপক্ষে ব্যবহৃত উপসেটের জন্য পার্সার এবং কোড জেনারেটর ব্যাকরণের প্রায় 100 লাইন এবং জেনারেটরের ~300 লাইনে ফিট করে (সমস্ত গণনা করে printএর জেনারেটেড কোড), প্রতিটি ক্লাসে আত্মদর্শনের জন্য টাইপ তথ্য খরগোশ সহ। প্রতিটি পলিমরফিক টাইপ একটি খালি বিমূর্ত বেস শ্রেণীতে পরিণত হয়, এবং কনস্ট্রাক্টররা এটি থেকে উত্তরাধিকার সূত্রে প্রাপ্ত হয় এবং সিরিয়ালাইজেশন এবং ডিসিরিয়ালাইজেশনের পদ্ধতি রয়েছে।

টাইপ ভাষার অভাব

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

প্রথমত, সীমাবদ্ধতা। এখানে আমরা ফাইল আপলোড করার জন্য ডকুমেন্টেশন দেখতে পাচ্ছি:

ফাইলের বাইনারি বিষয়বস্তু তারপর অংশে বিভক্ত করা হয়। সমস্ত অংশ একই আকার হতে হবে ( part_size ) এবং নিম্নলিখিত শর্তগুলি অবশ্যই পূরণ করতে হবে:

• part_size % 1024 = 0 (1KB দ্বারা বিভাজ্য)
• 524288 % part_size = 0 (512KB অবশ্যই part_size দ্বারা সমানভাবে বিভাজ্য হতে হবে)

শেষ অংশটিকে এই শর্তগুলি পূরণ করতে হবে না, যদি এর আকার part_size থেকে কম হয়।

প্রতিটি অংশের একটি ক্রম সংখ্যা থাকা উচিত, ফাইল_পার্ট, 0 থেকে 2,999 পর্যন্ত মান সহ।

ফাইলটি পার্টিশন করার পরে আপনাকে সার্ভারে সংরক্ষণ করার জন্য একটি পদ্ধতি বেছে নিতে হবে। ব্যবহার করুন upload.saveBigFilePart ফাইলের পূর্ণ আকার 10 MB এর বেশি হলে এবং upload.saveFilePart ছোট ফাইলের জন্য।
[...] নিম্নলিখিত ডেটা ইনপুট ত্রুটিগুলির মধ্যে একটি ফিরে আসতে পারে:

• FILE_PARTS_INVALID — অংশের অবৈধ সংখ্যা। মান এর মধ্যে নেই 1..3000

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

এর কোনোটিই টিএল-এ নেই। কিন্তু আছে, উদাহরণস্বরূপ, JSON স্কিমা. এবং যদি অন্য কেউ 512 KB এর বিভাজ্যতা সম্পর্কে তর্ক করতে পারে যে এটি এখনও কোডে চেক করা দরকার, তাহলে নিশ্চিত করুন যে ক্লায়েন্ট সহজভাবে পারে না সীমার বাইরে একটি নম্বর পাঠান 1..3000 (এবং সংশ্লিষ্ট ত্রুটিটি উদ্ভূত হতে পারে না) এটি সম্ভব হতো, তাই না? ..

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

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

-channelFull#76af5481 flags:# can_view_participants:flags.3?true can_set_username:flags.6?true can_set_stickers:flags.7?true hidden_prehistory:flags.10?true id:int about:string participants_count:flags.0?int admins_count:flags.1?int kicked_count:flags.2?int banned_count:flags.2?int read_inbox_max_id:int read_outbox_max_id:int unread_count:int chat_photo:Photo notify_settings:PeerNotifySettings exported_invite:ExportedChatInvite bot_info:Vector<BotInfo> migrated_from_chat_id:flags.4?int migrated_from_max_id:flags.4?int pinned_msg_id:flags.5?int stickerset:flags.8?StickerSet available_min_id:flags.9?int = ChatFull;
+channelFull#1c87a71a flags:# can_view_participants:flags.3?true can_set_username:flags.6?true can_set_stickers:flags.7?true hidden_prehistory:flags.10?true can_view_stats:flags.12?true id:int about:string participants_count:flags.0?int admins_count:flags.1?int kicked_count:flags.2?int banned_count:flags.2?int online_count:flags.13?int read_inbox_max_id:int read_outbox_max_id:int unread_count:int chat_photo:Photo notify_settings:PeerNotifySettings exported_invite:ExportedChatInvite bot_info:Vector<BotInfo> migrated_from_chat_id:flags.4?int migrated_from_max_id:flags.4?int pinned_msg_id:flags.5?int stickerset:flags.8?StickerSet available_min_id:flags.9?int = ChatFull;

বা

-message#44f9b43d flags:# out:flags.1?true mentioned:flags.4?true media_unread:flags.5?true silent:flags.13?true post:flags.14?true id:int from_id:flags.8?int to_id:Peer fwd_from:flags.2?MessageFwdHeader via_bot_id:flags.11?int reply_to_msg_id:flags.3?int date:int message:string media:flags.9?MessageMedia reply_markup:flags.6?ReplyMarkup entities:flags.7?Vector<MessageEntity> views:flags.10?int edit_date:flags.15?int post_author:flags.16?string grouped_id:flags.17?long = Message;
+message#44f9b43d flags:# out:flags.1?true mentioned:flags.4?true media_unread:flags.5?true silent:flags.13?true post:flags.14?true from_scheduled:flags.18?true id:int from_id:flags.8?int to_id:Peer fwd_from:flags.2?MessageFwdHeader via_bot_id:flags.11?int reply_to_msg_id:flags.3?int date:int message:string media:flags.9?MessageMedia reply_markup:flags.6?ReplyMarkup entities:flags.7?Vector<MessageEntity> views:flags.10?int edit_date:flags.15?int post_author:flags.16?string grouped_id:flags.17?long = Message;

এটি প্রত্যেকের উপর নির্ভর করে, কিন্তু GitHub, উদাহরণস্বরূপ, এই ধরনের দীর্ঘ লাইনের মধ্যে পরিবর্তনগুলি হাইলাইট করতে অস্বীকার করে। গেমটি "10টি পার্থক্য খুঁজুন" এবং মস্তিষ্ক অবিলম্বে যা দেখে তা হল যে উভয় উদাহরণের শুরু এবং শেষ একই, আপনাকে ক্লান্তিকরভাবে মাঝখানে কোথাও পড়তে হবে... আমার মতে, এটি শুধুমাত্র তত্ত্বে নয়, কিন্তু বিশুদ্ধভাবে দৃশ্যত নোংরা এবং ঢালু.

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

storage.fileUnknown#aa963b05 = storage.FileType;
storage.filePartial#40bc6f52 = storage.FileType;
storage.fileJpeg#7efe0e = storage.FileType;
storage.fileGif#cae1aadf = storage.FileType;
storage.filePng#a4f63c0 = storage.FileType;
storage.filePdf#ae1e508d = storage.FileType;
storage.fileMp3#528a0677 = storage.FileType;
storage.fileMov#4b09ebbc = storage.FileType;
storage.fileMp4#b3cea0e4 = storage.FileType;
storage.fileWebp#1081464c = storage.FileType;

কিন্তু এখন কল্পনা করুন, আপনার কাঠামোতে যদি 5টি ঐচ্ছিক ক্ষেত্র থাকে, তাহলে আপনার সমস্ত সম্ভাব্য বিকল্পের জন্য 32 প্রকারের প্রয়োজন হবে। সম্মিলিত বিস্ফোরণ। এইভাবে, TL তত্ত্বের স্ফটিক বিশুদ্ধতা আবারও সিরিয়ালাইজেশনের কঠোর বাস্তবতার ঢালাই-লোহা গাধার বিরুদ্ধে ছিন্নভিন্ন হয়ে গেছে।

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

বা অন্য একটি উদাহরণ, আমরা একবার একটি ত্রুটি আবিষ্কার করেছি - এটি পাঠানো হয়েছিল InputPeerUser পরিবর্তে InputUser. অথবা উলটা. কিন্তু এটা কাজ! অর্থাৎ, সার্ভার টাইপ সম্পর্কে চিন্তা করে না। এটা কিভাবে হতে পারে? উত্তরটি টেলিগ্রাম-ক্লি থেকে কোড টুকরো দ্বারা আমাদের দেওয়া যেতে পারে:

  if (tgl_get_peer_type (E->id) != TGL_PEER_CHANNEL || (C && (C->flags & TGLCHF_MEGAGROUP))) {
    out_int (CODE_messages_get_history);
    out_peer_id (TLS, E->id);
  } else {    
    out_int (CODE_channels_get_important_history);

    out_int (CODE_input_channel);
    out_int (tgl_get_peer_id (E->id));
    out_long (E->id.access_hash);
  }
  out_int (E->max_id);
  out_int (E->offset);
  out_int (E->limit);
  out_int (0);
  out_int (0);

অন্য কথায়, এখানেই সিরিয়ালাইজেশন করা হয় ম্যানুয়ালি, জেনারেটেড কোড নয়! হয়তো সার্ভারটি একইভাবে প্রয়োগ করা হয়েছে?... নীতিগতভাবে, এটি একবার করা হলে এটি কাজ করবে, কিন্তু আপডেটের সময় এটি কীভাবে সমর্থন করা যেতে পারে? এই স্কিম উদ্ভাবিত হয়েছে কেন? এবং এখানে আমরা পরবর্তী প্রশ্নে এগিয়ে যাই।

সংস্করণ করা। স্তর

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

যদি একটি ক্লায়েন্ট লেয়ার 2 সমর্থন করে, তাহলে নিম্নলিখিত কনস্ট্রাক্টর ব্যবহার করা আবশ্যক:

invokeWithLayer2#289dd1f6 {X:Type} query:!X = X;

অনুশীলনে, এর মানে হল যে প্রতিটি API কল করার আগে, মান সহ একটি int 0x289dd1f6 পদ্ধতি নম্বরের আগে যোগ করতে হবে।

স্বাভাবিক শোনাচ্ছে। কিন্তু এরপর কী হল? তারপর হাজির

invokeWithLayer3#b7475268 query:!X = X;

তাহলে পরবর্তী কি? আপনি অনুমান করতে পারেন,

invokeWithLayer4#dea0d430 query:!X = X;

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

invokeWithLayer5#417a57ae query:!X = X;

তবে এটা স্পষ্ট যে কিছুক্ষণ পরে এটি একরকম বাচনলিয়ায় পরিণত হবে। এবং সমাধান এসেছে:

আপডেট: লেয়ার 9 দিয়ে শুরু, সহায়ক পদ্ধতি invokeWithLayerN শুধুমাত্র একসাথে ব্যবহার করা যেতে পারে initConnection

হুররে! 9 সংস্করণের পরে, আমরা অবশেষে 80-এর দশকে ইন্টারনেট প্রোটোকলগুলিতে যা করা হয়েছিল তাতে এসেছি - সংযোগের শুরুতে একবার সংস্করণে সম্মত!

তাহলে পরবর্তী কি? ..

invokeWithLayer10#39620c41 query:!X = X;
...
invokeWithLayer18#1c900537 query:!X = X;

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

ঠিক? ..

ভ্যাসিলি, [16.07.18 14:01] এমনকি শুক্রবারেও আমি ভেবেছিলাম:
টেলিসার্ভার একটি অনুরোধ ছাড়া ইভেন্ট পাঠায়. অনুরোধগুলি অবশ্যই InvokeWithLayer এ আবৃত করতে হবে৷ সার্ভার আপডেটগুলি মোড়ানো হয় না; প্রতিক্রিয়া এবং আপডেটগুলি মোড়ানোর জন্য কোনও কাঠামো নেই৷

সেগুলো. ক্লায়েন্ট যে স্তরটিতে আপডেট চায় তা নির্দিষ্ট করতে পারে না

Vadim Goncharov, [16.07.18 14:02] InvokeWithLayer নীতিগতভাবে একটি ক্রাচ নয়?

ভ্যাসিলি, [16.07.18 14:02] এটাই একমাত্র উপায়

ভাদিম গনচারভ, [16.07.18 14:02] যার অর্থ মূলত অধিবেশনের শুরুতে স্তরে একমত হওয়া উচিত

যাইহোক, এটি অনুসরণ করে যে ক্লায়েন্ট ডাউনগ্রেড প্রদান করা হয় না

আপডেট, i.e. টাইপ Updates স্কিমে, সার্ভার ক্লায়েন্টকে এপিআই অনুরোধের জবাবে নয়, কিন্তু একটি ঘটনা ঘটলে স্বাধীনভাবে পাঠায়। এটি একটি জটিল বিষয় যা অন্য পোস্টে আলোচনা করা হবে, তবে আপাতত এটি জানা গুরুত্বপূর্ণ যে ক্লায়েন্ট অফলাইনে থাকা সত্ত্বেও সার্ভার আপডেটগুলি সংরক্ষণ করে।

এইভাবে, আপনি মোড়ানো প্রত্যাখ্যান প্রতিটি প্যাকেজ এর সংস্করণ নির্দেশ করার জন্য, এটি যৌক্তিকভাবে নিম্নলিখিত সম্ভাব্য সমস্যার দিকে পরিচালিত করে:

• ক্লায়েন্ট কোন সংস্করণ সমর্থন করে তা জানানোর আগেই সার্ভার ক্লায়েন্টকে আপডেট পাঠায়
• ক্লায়েন্ট আপগ্রেড করার পরে আমার কি করা উচিত?
• কে গ্যারান্টিলেয়ার নম্বর সম্পর্কে সার্ভারের মতামত প্রক্রিয়া চলাকালীন পরিবর্তন হবে না?

আপনি কি মনে করেন যে এটি সম্পূর্ণরূপে তাত্ত্বিক অনুমান, এবং বাস্তবে এটি ঘটতে পারে না, কারণ সার্ভারটি সঠিকভাবে লেখা হয়েছে (অন্তত, এটি ভালভাবে পরীক্ষা করা হয়েছে)? হা! সেটা যেভাবেই হোক না কেন!

এই আমরা আগস্টে দৌড়ে ঠিক কি. 14 আগস্ট, সেখানে বার্তা ছিল যে টেলিগ্রাম সার্ভারে কিছু আপডেট করা হচ্ছে... এবং তারপরে লগগুলিতে:

2019-08-15 09:28:35.880640 MSK warn  main: ANON:87: unknown object type: 0x80d182d1 at TL/Object.pm line 213.
2019-08-15 09:28:35.751899 MSK warn  main: ANON:87: unknown object type: 0xb5223b0f at TL/Object.pm line 213.

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

ঠিক আছে, যে কারও মনে প্রথম জিনিসটি আসে তা হল সংযোগ বিচ্ছিন্ন করা এবং আবার চেষ্টা করা। সাহায্য না. আমরা CRC32 গুগল করি - এগুলি 73 স্কিম থেকে অবজেক্টে পরিণত হয়েছে, যদিও আমরা 82-এ কাজ করেছি। আমরা লগগুলি সাবধানে দেখি - দুটি ভিন্ন স্কিম থেকে শনাক্তকারী রয়েছে!

হয়তো সমস্যাটি আমাদের অনানুষ্ঠানিক ক্লায়েন্টে বিশুদ্ধভাবে? না, আমরা টেলিগ্রাম ডেস্কটপ 1.2.17 চালু করি (লিনাক্স বিতরণের একটি সংখ্যায় সরবরাহ করা সংস্করণ), এটি ব্যতিক্রম লগে লিখে: MTP অপ্রত্যাশিত টাইপ আইডি #b5223b0f MTPMessageMedia-এ পড়া…

গুগল দেখিয়েছে যে একটি অনুরূপ সমস্যা ইতিমধ্যে একটি অনানুষ্ঠানিক ক্লায়েন্টের সাথে ঘটেছে, কিন্তু তারপরে সংস্করণ সংখ্যা এবং সেই অনুযায়ী, অনুমানগুলি ভিন্ন ছিল ...

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

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

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

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

public static class TL_message_layer68 extends TL_message {
    public static int constructor = 0xc09be45f;
//...
//еще пачка подобных
//...
    public static class TL_message_layer47 extends TL_message {
        public static int constructor = 0xc992e15c;
        public static Message TLdeserialize(AbstractSerializedData stream, int constructor, boolean exception) {
            Message result = null;
            switch (constructor) {
                case 0x1d86f70e:
                    result = new TL_messageService_old2();
                    break;
                case 0xa7ab1991:
                    result = new TL_message_old3();
                    break;
                case 0xc3060325:
                    result = new TL_message_old4();
                    break;
                case 0x555555fa:
                    result = new TL_message_secret();
                    break;
                case 0x555555f9:
                    result = new TL_message_secret_layer72();
                    break;
                case 0x90dddc11:
                    result = new TL_message_layer72();
                    break;
                case 0xc09be45f:
                    result = new TL_message_layer68();
                    break;
                case 0xc992e15c:
                    result = new TL_message_layer47();
                    break;
                case 0x5ba66c13:
                    result = new TL_message_old7();
                    break;
                case 0xc06b9607:
                    result = new TL_messageService_layer48();
                    break;
                case 0x83e5de54:
                    result = new TL_messageEmpty();
                    break;
                case 0x2bebfa86:
                    result = new TL_message_old6();
                    break;
                case 0x44f9b43d:
                    result = new TL_message_layer104();
                    break;
                case 0x1c9b1027:
                    result = new TL_message_layer104_2();
                    break;
                case 0xa367e716:
                    result = new TL_messageForwarded_old2(); //custom
                    break;
                case 0x5f46804:
                    result = new TL_messageForwarded_old(); //custom
                    break;
                case 0x567699b3:
                    result = new TL_message_old2(); //custom
                    break;
                case 0x9f8d60bb:
                    result = new TL_messageService_old(); //custom
                    break;
                case 0x22eb6aba:
                    result = new TL_message_old(); //custom
                    break;
                case 0x555555F8:
                    result = new TL_message_secret_old(); //custom
                    break;
                case 0x9789dac4:
                    result = new TL_message_layer104_3();
                    break;

বা

    boolean fixCaption = !TextUtils.isEmpty(message) &&
    (media instanceof TLRPC.TL_messageMediaPhoto_old ||
     media instanceof TLRPC.TL_messageMediaPhoto_layer68 ||
     media instanceof TLRPC.TL_messageMediaPhoto_layer74 ||
     media instanceof TLRPC.TL_messageMediaDocument_old ||
     media instanceof TLRPC.TL_messageMediaDocument_layer68 ||
     media instanceof TLRPC.TL_messageMediaDocument_layer74)
    && message.startsWith("-1");

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

TL_message_layer104
TL_message_layer104_2
TL_message_layer104_3

বন্ধুরা, আপনি কি এক স্তরের ভিতরে কী তা নির্ধারণ করতে পারেন না?! আচ্ছা, ঠিক আছে, ধরা যাক "দুটি" একটি ত্রুটি সহ মুক্তি পেয়েছিল, আচ্ছা, এটি ঘটে, তবে তিন?.. এখনই, আবার একই রেক? এটা কি ধরনের পর্নোগ্রাফি, দুঃখিত?...

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

কিভাবে এই এমনকি পরীক্ষা করা যেতে পারে? আমি আশা করি ইউনিট, কার্যকরী এবং অন্যান্য পরীক্ষার ভক্তরা মন্তব্যে ভাগ করবে।

ঠিক আছে, আসুন কোডের আরেকটি অংশ দেখি:

public static class TL_folders_deleteFolder extends TLObject {
    public static int constructor = 0x1c295881;

    public int folder_id;

    public TLObject deserializeResponse(AbstractSerializedData stream, int constructor, boolean exception) {
        return Updates.TLdeserialize(stream, constructor, exception);
    }

    public void serializeToStream(AbstractSerializedData stream) {
        stream.writeInt32(constructor);
        stream.writeInt32(folder_id);
    }
}

//manually created

//RichText start
public static abstract class RichText extends TLObject {
    public String url;
    public long webpage_id;
    public String email;
    public ArrayList<RichText> texts = new ArrayList<>();
    public RichText parentRichText;

    public static RichText TLdeserialize(AbstractSerializedData stream, int constructor, boolean exception) {
        RichText result = null;
        switch (constructor) {
            case 0x1ccb966a:
                result = new TL_textPhone();
                break;
            case 0xc7fb5e01:
                result = new TL_textSuperscript();
                break;

এই মন্তব্যটি "ম্যানুয়ালি তৈরি" পরামর্শ দেয় যে এই ফাইলটির শুধুমাত্র একটি অংশ ম্যানুয়ালি লেখা হয়েছিল (আপনি কি পুরো রক্ষণাবেক্ষণের দুঃস্বপ্ন কল্পনা করতে পারেন?), এবং বাকিটি মেশিন দ্বারা তৈরি করা হয়েছিল। যাইহোক, তারপর আরেকটি প্রশ্ন ওঠে - যে সূত্র পাওয়া যায় না সম্পূর্ণরূপে (লিনাক্স কার্নেলে একটি লা জিপিএল ব্লব), কিন্তু এটি ইতিমধ্যে দ্বিতীয় অংশের জন্য একটি বিষয়।

কিন্তু যথেষ্ট। আসুন প্রোটোকলের দিকে এগিয়ে যাই যার উপরে এই সমস্ত সিরিয়ালাইজেশন চলে।

এমটিপিপ্রোটো

সুতরাং, এর খোলা যাক সাধারণ বিবরণ и প্রোটোকলের বিস্তারিত বিবরণ এবং আমরা প্রথম যে বিষয়ে হোঁচট খাই তা হল পরিভাষা। এবং সবকিছু একটি প্রাচুর্য সঙ্গে. সাধারণভাবে, এটি টেলিগ্রামের একটি মালিকানাধীন বৈশিষ্ট্য বলে মনে হচ্ছে - বিভিন্ন জায়গায় বিভিন্ন জিনিসকে আলাদাভাবে কল করা, বা একটি শব্দের সাথে ভিন্ন জিনিস, বা বিপরীতভাবে (উদাহরণস্বরূপ, একটি উচ্চ-স্তরের API-এ, আপনি যদি একটি স্টিকার প্যাক দেখেন, এটি নয় আপনি কি ভেবেছিলেন)।

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

পরিবহন স্তর

প্রথম জিনিসটি পরিবহন। তারা আমাদের 5টি বিকল্প সম্পর্কে বলবে:

• বিভিন্ন TCP
• ওয়েবসাইট
• HTTPS এর উপর ওয়েবসকেট
• HTTP- র
• HTTPS দ্বারা

ভ্যাসিলি, [15.06.18 15:04] এছাড়াও UDP পরিবহন আছে, কিন্তু এটি নথিভুক্ত নয়

এবং টিসিপি তিনটি ভেরিয়েন্টে

প্রথমটি টিসিপির উপর ইউডিপির অনুরূপ, প্রতিটি প্যাকেটে একটি সিকোয়েন্স নম্বর এবং সিআরসি রয়েছে
কেন একটি কার্টে নথি পড়া এত বেদনাদায়ক?

ওয়েল, এটা এখন আছে TCP ইতিমধ্যেই 4টি ভেরিয়েন্টে রয়েছে৷:

• সংক্ষেপিত
• অন্তর্বর্তী
• প্যাডেড মধ্যবর্তী
• পূর্ণ

আচ্ছা, ঠিক আছে, MTProxy-এর জন্য প্যাডেড ইন্টারমিডিয়েট, এটি পরে সুপরিচিত ইভেন্টের কারণে যোগ করা হয়েছে। কিন্তু কেন আরও দুটি সংস্করণ (মোট তিনটি) যখন আপনি একটি দিয়ে পেতে পারেন? মূল MTProto এর দৈর্ঘ্য এবং পেলোড কিভাবে সেট করতে হয় তার চারটিই মূলত ভিন্ন, যা আরও আলোচনা করা হবে:

• সংক্ষেপে এটি 1 বা 4 বাইট, কিন্তু 0xef নয়, তারপর বডি
• ইন্টারমিডিয়েটে এটি দৈর্ঘ্যের 4 বাইট এবং একটি ক্ষেত্র, এবং ক্লায়েন্টকে প্রথমবার পাঠাতে হবে 0xeeeeeeee ইঙ্গিত করার জন্য যে এটি মধ্যবর্তী
• একটি নেটওয়ার্কারের দৃষ্টিকোণ থেকে সম্পূর্ণরূপে সবচেয়ে আসক্ত: দৈর্ঘ্য, ক্রম সংখ্যা, এবং প্রধানত MTProto, বডি, CRC32 নয়। হ্যাঁ, এই সবই TCP-এর উপরে। যা আমাদেরকে একটি অনুক্রমিক বাইট স্ট্রিম আকারে নির্ভরযোগ্য পরিবহন সরবরাহ করে, বিশেষ করে চেকসামগুলির প্রয়োজন নেই। ঠিক আছে, এখন কেউ আমাকে আপত্তি করবে যে TCP এর 16-বিট চেকসাম আছে, তাই ডেটা দুর্নীতি হয়। দুর্দান্ত, কিন্তু আমাদের কাছে আসলে 16 বাইটের বেশি হ্যাশ সহ একটি ক্রিপ্টোগ্রাফিক প্রোটোকল রয়েছে, এই সমস্ত ত্রুটি - এবং আরও বেশি - একটি উচ্চ স্তরে একটি SHA অমিল দ্বারা ধরা হবে৷ এর উপরে CRC32 এর কোন পয়েন্ট নেই।

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

একজনের ধারণা পাওয়া যায় যে নিকোলাই দুরভ সত্যিকার অর্থে কোনো বাস্তব প্রয়োজন ছাড়াই নেটওয়ার্ক প্রোটোকল সহ চাকার নতুন উদ্ভাবন করতে পছন্দ করেন।

অন্যান্য পরিবহন বিকল্প, সহ। ওয়েব এবং MTProxy, আমরা এখন বিবেচনা করব না, হয়ত অন্য পোস্টে, যদি অনুরোধ থাকে। এই একই MTProxy সম্পর্কে, আসুন আমরা এখন শুধু মনে রাখি যে 2018 সালে এটির প্রকাশের পরপরই, প্রদানকারীরা দ্রুত এটি ব্লক করতে শিখেছিল, যার উদ্দেশ্যে বাইপাস ব্লকিংঅনুযায়ী প্যাকেজ আকার! এবং এটিও যে MTProxy সার্ভারটি সি-তে লেখা (আবার ওয়াল্টম্যান দ্বারা) লিনাক্স স্পেসিফিকেশনের সাথে অত্যধিকভাবে আবদ্ধ ছিল, যদিও এটি মোটেই প্রয়োজন ছিল না (ফিল কুলিন নিশ্চিত করবেন), এবং Go বা Node.js-এ অনুরূপ সার্ভার হবে একশোরও কম লাইনে ফিট।

তবে আমরা অন্যান্য বিষয়গুলি বিবেচনা করার পরে বিভাগের শেষে এই লোকদের প্রযুক্তিগত সাক্ষরতা সম্পর্কে সিদ্ধান্তে আঁকব। আপাতত, চলুন OSI লেয়ার 5, সেশনে যাওয়া যাক - যেখানে তারা MTProto সেশন রেখেছে।

কী, বার্তা, সেশন, ডিফি-হেলম্যান

তারা সেখানে এটিকে সম্পূর্ণভাবে সঠিকভাবে স্থাপন করেনি... একটি সেশন একই সেশন নয় যা সক্রিয় সেশনের অধীনে ইন্টারফেসে দৃশ্যমান। কিন্তু ক্রমানুসারে।

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

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

এই দুইয়ের মধ্যে সেশন একটি ধারণা আছে অনুমোদন. অধঃপতনের ক্ষেত্রে আমরা তা বলতে পারি UI সেশন এটার মতই অনুমোদন, কিন্তু হায়, সবকিছুই জটিল। চলুন দেখা যাক:

• নতুন ডিভাইসে ব্যবহারকারী প্রথমে তৈরি করে প্রমাণীকরণ কী এবং এটিকে অ্যাকাউন্টে আবদ্ধ করে, উদাহরণস্বরূপ এসএমএসের মাধ্যমে - তাই অনুমোদন
• এটা প্রথম ভিতরে ঘটেছে MTProto অধিবেশন, কোনটি আছে session_id নিজের ভিতরে।
• এই ধাপে, সমন্বয় অনুমোদন и session_id বলা যেতে পারে উদাহরণ - এই শব্দটি কিছু ক্লায়েন্টের ডকুমেন্টেশন এবং কোডে উপস্থিত হয়
• তারপর, ক্লায়েন্ট খুলতে পারেন বিভিন্ন MTProto সেশন একই অধীনে প্রমাণীকরণ কী - একই ডিসির কাছে।
• তারপরে, একদিন ক্লায়েন্টকে ফাইলটি অনুরোধ করতে হবে অন্য ডিসি - এবং এর জন্য একটি নতুন ডিসি তৈরি করা হবে প্রমাণীকরণ কী !
• সিস্টেমকে জানানো যে এটি একটি নতুন ব্যবহারকারী নয় যারা নিবন্ধন করছে, তবে একই অনুমোদন (UI সেশন), ক্লায়েন্ট API কল ব্যবহার করে auth.exportAuthorization বাড়িতে ডিসি auth.importAuthorization নতুন ডিসিতে।
• সবকিছু একই, বেশ কয়েকটি খোলা হতে পারে MTProto সেশন (প্রতিটি তার নিজস্ব session_id) এই নতুন ডিসি, অধীনে তার প্রমাণীকরণ কী.
• অবশেষে, ক্লায়েন্ট পারফেক্ট ফরওয়ার্ড সিক্রেসি চাইতে পারে। প্রতি প্রমাণীকরণ কী মনে হচ্ছিল স্থায়ী কী - প্রতি ডিসি - এবং ক্লায়েন্ট কল করতে পারে auth.bindTempAuthKey ব্যবহারের জন্য অস্থায়ী প্রমাণীকরণ কী - এবং আবার, শুধুমাত্র একটি temp_auth_key ডিসি প্রতি, সবার জন্য সাধারণ MTProto সেশন এই ডিসির কাছে।

নোট করুন লবণ (এবং ভবিষ্যতের লবণ)ও এক প্রমাণীকরণ কী সেগুলো. সবার মধ্যে ভাগ করা MTProto সেশন একই ডিসির কাছে।

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

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

তাই এর জেনারেট করা যাক auth_key এ টেলিগ্রাম থেকে ডিফি-হেলম্যান সংস্করণ. ডকুমেন্টেশন বোঝার চেষ্টা করা যাক...

Vasily, [19.06.18 20:05] data_with_hash := SHA1(ডেটা) + ডেটা + (যেকোনো র্যান্ডম বাইট); যেমন দৈর্ঘ্য 255 বাইট সমান;
এনক্রিপ্টেড_ডেটা := RSA(ডেটা_ওয়াইথ_হ্যাশ, সার্ভার_পাবলিক_কি); একটি 255-বাইট দীর্ঘ সংখ্যা (বড় এন্ডিয়ান) প্রয়োজনীয় মডুলাসের উপরে প্রয়োজনীয় শক্তিতে উত্থাপিত হয় এবং ফলাফলটি 256-বাইট সংখ্যা হিসাবে সংরক্ষণ করা হয়।

তাদের কিছু ডোপ DH আছে

একটি সুস্থ ব্যক্তির DH মত দেখায় না
dx-এ কোন দুটি পাবলিক কী নেই

ঠিক আছে, শেষ পর্যন্ত এটি বাছাই করা হয়েছিল, কিন্তু একটি অবশিষ্টাংশ রয়ে গেছে - কাজের প্রমাণ ক্লায়েন্ট দ্বারা করা হয়েছে যে তিনি সংখ্যাটি ফ্যাক্টর করতে পেরেছিলেন। DoS আক্রমণের বিরুদ্ধে সুরক্ষার প্রকার। আর RSA কী শুধুমাত্র একবার এক দিকে ব্যবহার করা হয়, মূলত এনক্রিপশনের জন্য new_nonce. কিন্তু এই আপাতদৃষ্টিতে সহজ অপারেশন সফল হবে, আপনি কি সম্মুখীন হতে হবে?

ভ্যাসিলি, [20.06.18/00/26 XNUMX:XNUMX] আমি এখনও অ্যাপিড অনুরোধ পাইনি

আমি এই অনুরোধটি ডিএইচকে পাঠিয়েছি

এবং, পরিবহন ডকে এটি বলে যে এটি একটি ত্রুটি কোডের 4 বাইটের সাথে প্রতিক্রিয়া জানাতে পারে। এখানেই শেষ

আচ্ছা, সে আমাকে বলল -404, তাই কি?

তাই আমি তাকে বলেছিলাম: "এইভাবে একটি আঙ্গুলের ছাপ সহ একটি সার্ভার কী দিয়ে এনক্রিপ্ট করা আপনার বুলশিট ধরুন, আমি DH চাই," এবং এটি একটি বোকা 404 দিয়ে প্রতিক্রিয়া জানায়

আপনি এই সার্ভার প্রতিক্রিয়া কি মনে হবে? কি করো? জিজ্ঞাসা করার কেউ নেই (তবে দ্বিতীয় অংশে আরও বেশি)।

এখানে সব স্বার্থ ডক করা হয়

আমার আর কিছু করার নেই, আমি শুধু বারবার সংখ্যা পরিবর্তন করার স্বপ্ন দেখেছি

দুটি 32 বিট সংখ্যা। আমি অন্য সবার মত তাদের বস্তাবন্দী

কিন্তু না, এই দুটি লাইনে প্রথমে BE হিসেবে যোগ করতে হবে

ভাদিম গনচারভ, [20.06.18 15:49] এবং এই 404 এর কারণে?

ভ্যাসিলি, [20.06.18 15:49] হ্যাঁ!

ভাদিম গনচারভ, [20.06.18 15:50] তাই আমি বুঝতে পারছি না তিনি কি "খুঁজে পাননি"

ভ্যাসিলি, [20.06.18 15:50] প্রায়

আমি প্রাইম ফ্যাক্টর% এ এরকম পচন খুঁজে পাইনি)

এমনকি আমরা ত্রুটি রিপোর্টিং পরিচালনা করিনি

ভ্যাসিলি, [20.06.18 20:18] ওহ, MD5ও আছে। ইতিমধ্যে তিনটি ভিন্ন হ্যাশ

কী ফিঙ্গারপ্রিন্ট নিম্নরূপ গণনা করা হয়:

digest = md5(key + iv)
fingerprint = substr(digest, 0, 4) XOR substr(digest, 4, 4)

SHA1 এবং sha2

তাই এটা করা যাক auth_key আমরা ডিফি-হেলম্যান ব্যবহার করে আকারে 2048 বিট পেয়েছি। এরপর কি? এরপরে আমরা আবিষ্কার করি যে এই কীটির নীচের 1024 বিটগুলি কোনও ভাবেই ব্যবহার করা হয় না... তবে আপাতত এটি সম্পর্কে চিন্তা করা যাক। এই ধাপে, আমাদের সার্ভারের সাথে একটি ভাগ করা গোপন আছে। টিএলএস সেশনের একটি অ্যানালগ প্রতিষ্ঠিত হয়েছে, যা একটি অত্যন্ত ব্যয়বহুল পদ্ধতি। কিন্তু সার্ভার এখনও কিছু জানে না আমরা কে! এখনও না, আসলে. অনুমোদন. সেগুলো. আপনি যদি "লগইন-পাসওয়ার্ড" এর পরিপ্রেক্ষিতে চিন্তা করেন, যেমনটি আপনি একবার ICQ তে করেছিলেন, বা কমপক্ষে "লগইন-কি", যেমন SSH-এ (উদাহরণস্বরূপ, কিছু গিটল্যাব/গিথুবে)। আমরা একটি বেনামী পেয়েছিলাম. যদি সার্ভার আমাদের বলে "এই ফোন নম্বরগুলি অন্য DC দ্বারা পরিষেবা দেওয়া হয়"? অথবা এমনকি "আপনার ফোন নম্বর নিষিদ্ধ"? আমরা যা করতে পারি তা হল চাবিটি এই আশায় রাখা যে এটি কার্যকর হবে এবং ততক্ষণে পচে যাবে না।

যাইহোক, আমরা এটি সংরক্ষণের সাথে "প্রাপ্ত" করেছি। উদাহরণস্বরূপ, আমরা কি সার্ভারকে বিশ্বাস করি? এটা জাল হলে কি হবে? ক্রিপ্টোগ্রাফিক চেক প্রয়োজন হবে:

Vasily, [21.06.18 17:53] তারা মোবাইল ক্লায়েন্টদের অফার করে 2kbit সংখ্যার জন্য প্রাথমিক%)

কিন্তু এটা মোটেও পরিষ্কার নয়, নাফেইজোয়া

Vasily, [21.06.18 18:02] নথিতে বলা নেই যে এটি সহজ না হলে কী করতে হবে

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

278     static const char *goodPrime = "c71caeb9c6b1c9048e6c522f70f13f73980d40238e3e21c14934d037563d930f48198a0aa7c14058229493d22530f4dbfa336f6e0ac925139543aed44cce7c3720fd51f69458705ac68cd4fe6b6b13abdc9746512969328454f18faf8c595f642477fe96bb2a941d5bcd1d4ac8cc49880708fa9b378e3c4f3a9060bee67cf9a4a4a695811051907e162753b56b0f6b410dba74d8a84b2a14b3144e0ef1284754fd17ed950d5965b4b9dd46582db1178d169c6bc465b0d6ff9ca3928fef5b9ae4e418fc15e83ebea0f87fa9ff5eed70050ded2849f47bf959d956850ce929851f0d8115f635b105ee2e4e15d04b2454bf6f4fadf034b10403119cd8e3b92fcc5b";
279   if (!strcasecmp(prime, goodPrime)) {

না, অবশ্যই এটা এখনও আছে কিছু একটি সংখ্যার প্রাথমিকতার জন্য পরীক্ষা আছে, কিন্তু ব্যক্তিগতভাবে আমার আর গণিতের পর্যাপ্ত জ্ঞান নেই।

ঠিক আছে, আমরা মাস্টার কী পেয়েছি। লগ ইন করতে, i.e. অনুরোধ পাঠান, আপনাকে AES ব্যবহার করে আরও এনক্রিপশন করতে হবে।

বার্তা কীটিকে বার্তার মূল অংশের SHA128 এর 256টি মধ্যম বিট হিসাবে সংজ্ঞায়িত করা হয়েছে (সেশন, বার্তা আইডি, ইত্যাদি সহ), প্যাডিং বাইট সহ, অনুমোদন কী থেকে নেওয়া 32 বাইট দ্বারা প্রিপেন্ড করা হয়েছে।

ভ্যাসিলি, [22.06.18 14:08] গড়, কুত্তা, বিট

গৃহীত auth_key. সব তাদের বাইরে... এটি নথি থেকে পরিষ্কার নয়। ওপেন সোর্স কোড অধ্যয়ন নির্দ্বিধায়.

মনে রাখবেন যে MTProto 2.0-এর জন্য 12 থেকে 1024 বাইট প্যাডিং প্রয়োজন, এখনও শর্ত সাপেক্ষে যে ফলাফল বার্তার দৈর্ঘ্য 16 বাইট দ্বারা বিভাজ্য হবে।

তাই আপনি কত প্যাডিং যোগ করা উচিত?

এবং হ্যাঁ, একটি ত্রুটির ক্ষেত্রে একটি 404 আছে

কেউ যদি ডকুমেন্টেশনের ডায়াগ্রাম এবং পাঠ্যটি সাবধানে অধ্যয়ন করে, তারা লক্ষ্য করেছে যে সেখানে কোনও MAC নেই। এবং সেই AES একটি নির্দিষ্ট IGE মোডে ব্যবহৃত হয় যা অন্য কোথাও ব্যবহার করা হয় না। তারা, অবশ্যই, তাদের প্রায়শই জিজ্ঞাসিত প্রশ্নপত্রে এটি সম্পর্কে লেখেন... এখানে, যেমন, বার্তা কী নিজেই ডিক্রিপ্ট করা ডেটার SHA হ্যাশ, যা অখণ্ডতা পরীক্ষা করতে ব্যবহৃত হয় - এবং অমিলের ক্ষেত্রে, কোনো কারণে ডকুমেন্টেশন নিঃশব্দে তাদের উপেক্ষা করার পরামর্শ দেয় (কিন্তু নিরাপত্তা সম্পর্কে কি, তারা যদি আমাদের ভেঙে দেয়?)

আমি একটি ক্রিপ্টোগ্রাফার নই, সম্ভবত একটি তাত্ত্বিক দৃষ্টিকোণ থেকে এই ক্ষেত্রে এই মোডের সাথে কিছু ভুল নেই। কিন্তু আমি স্পষ্টভাবে একটি ব্যবহারিক সমস্যার নাম দিতে পারি, উদাহরণ হিসেবে টেলিগ্রাম ডেস্কটপ ব্যবহার করে। এটি স্থানীয় ক্যাশে এনক্রিপ্ট করে (এই সমস্ত D877F783D5D3EF8C) MTProto-এর বার্তাগুলির মতোই (শুধুমাত্র এই ক্ষেত্রে সংস্করণ 1.0), যেমন প্রথমে মেসেজ কী, তারপর ডাটা নিজেই (এবং কোথাও প্রধান বড় auth_key 256 বাইট, যা ছাড়া msg_key অকেজো)। সুতরাং, সমস্যাটি বড় ফাইলগুলিতে লক্ষণীয় হয়ে ওঠে। যথা, আপনাকে ডেটার দুটি কপি রাখতে হবে - এনক্রিপ্ট করা এবং ডিক্রিপ্ট করা। এবং যদি মেগাবাইট, বা স্ট্রিমিং ভিডিও থাকে, উদাহরণস্বরূপ?... সাইফারটেক্সট পরে MAC সহ ক্লাসিক স্কিমগুলি আপনাকে এটি স্ট্রিম পড়তে দেয়, অবিলম্বে এটি প্রেরণ করে। কিন্তু MTProto এর সাথে আপনাকে করতে হবে প্রথমে সম্পূর্ণ বার্তাটি এনক্রিপ্ট বা ডিক্রিপ্ট করুন, শুধুমাত্র তারপর এটি নেটওয়ার্ক বা ডিস্কে স্থানান্তর করুন। তাই টেলিগ্রাম ডেস্কটপের সর্বশেষ সংস্করণে ক্যাশে ইন user_data CTR মোডে AES সহ অন্য একটি বিন্যাসও ব্যবহৃত হয়।

Vasily, [21.06.18 01:27] ওহ, আমি আইজিই কী তা খুঁজে পেয়েছি: আইজিই ছিল একটি "প্রমাণিত এনক্রিপশন মোড" এর প্রথম প্রচেষ্টা, মূলত কারবারোসের জন্য। এটি একটি ব্যর্থ প্রচেষ্টা ছিল (এটি অখণ্ডতা সুরক্ষা প্রদান করে না), এবং অপসারণ করতে হয়েছিল। এটি একটি প্রমাণীকরণকারী এনক্রিপশন মোডের জন্য 20 বছরের অনুসন্ধানের সূচনা যা কাজ করে, যা সম্প্রতি OCB এবং GCM-এর মতো মোডে পরিণত হয়েছে৷

এবং এখন কার্ট পাশ থেকে আর্গুমেন্ট:

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

এটা মজার. নিম্ন স্তরে দুই বছর

অথবা আপনি শুধু tls নিতে পারেন

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

ভ্যাসিলি, [25.06.18 18:46] সংযোগ শুরু করে এবং ব্যবহারকারীর ডিভাইস এবং অ্যাপ্লিকেশনে তথ্য সংরক্ষণ করে।

এটি app_id, device_model, system_version, app_version এবং lang_code গ্রহণ করে।

এবং কিছু প্রশ্ন

বরাবরের মতো ডকুমেন্টেশন। ওপেন সোর্স অধ্যয়ন নির্দ্বিধায়

invokeWithLayer এর সাথে যদি সবকিছু প্রায় পরিষ্কার হয়, তাহলে এখানে কি ভুল? দেখা যাচ্ছে, ধরা যাক আমাদের কাছে আছে - ক্লায়েন্টের ইতিমধ্যেই সার্ভারকে জিজ্ঞাসা করার কিছু ছিল - একটি অনুরোধ রয়েছে যা আমরা পাঠাতে চেয়েছিলাম:

ভ্যাসিলি, [25.06.18 19:13] কোড দ্বারা বিচার করলে, প্রথম কলটি এই বাজেভাবে মোড়ানো হয়, এবং ক্র্যাপটি নিজেই ইনভোক উইথলেয়ারে মোড়ানো হয়

কেন initConnection একটি পৃথক কল হতে পারে না, কিন্তু একটি মোড়ক হতে হবে? হ্যাঁ, যেমনটি দেখা গেছে, এটি অবশ্যই প্রতিটি সেশনের শুরুতে প্রতিবার করা উচিত, এবং একবার নয়, প্রধান কীটির মতো। কিন্তু! এটি একটি অননুমোদিত ব্যবহারকারী দ্বারা কল করা যাবে না! এখন আমরা সেই পর্যায়ে পৌঁছেছি যেখানে এটি প্রযোজ্য এই এক ডকুমেন্টেশন পৃষ্ঠা - এবং এটি আমাদের বলে যে ...

API পদ্ধতির শুধুমাত্র একটি ছোট অংশ অননুমোদিত ব্যবহারকারীদের জন্য উপলব্ধ:

• auth.sendCode
• auth.resendCode
• account.getPassword
• auth.checkPassword
• auth.checkPhone
• auth.signUp
• auth.signIn
• auth.importAuthorization
• help.getConfig
• help.getNearestDc
• help.getAppUpdate
• help.getCdnConfig
• langpack.getLangPack
• langpack.getStrings
• langpack.getDifference
• langpack.getLanguages
• langpack.getLanguage

তাদের মধ্যে প্রথমটি, auth.sendCode, এবং সেই লালিত প্রথম অনুরোধে আমরা api_id এবং api_hash পাঠাই এবং তারপরে আমরা একটি কোড সহ একটি SMS পাই। এবং যদি আমরা ভুল ডিসিতে থাকি (উদাহরণস্বরূপ, এই দেশে টেলিফোন নম্বরগুলি অন্য দ্বারা পরিবেশিত হয়), তবে আমরা পছন্দসই ডিসির নম্বর সহ একটি ত্রুটি পাব। ডিসি নম্বর দ্বারা কোন আইপি ঠিকানায় আপনাকে সংযোগ করতে হবে তা খুঁজে বের করতে, আমাদের সাহায্য করুন help.getConfig. এক সময়ে মাত্র 5টি এন্ট্রি ছিল, কিন্তু 2018 সালের বিখ্যাত ইভেন্টগুলির পরে, সংখ্যাটি উল্লেখযোগ্যভাবে বৃদ্ধি পেয়েছে।

এখন মনে রাখবেন যে আমরা বেনামে সার্ভারে এই পর্যায়ে এসেছি। শুধু একটি আইপি ঠিকানা পেতে এটি খুব ব্যয়বহুল নয়? এমটিপ্রোটোর এনক্রিপ্ট করা অংশে কেন এটি এবং অন্যান্য ক্রিয়াকলাপগুলি করবেন না? আমি আপত্তি শুনছি: "আমরা কীভাবে নিশ্চিত করব যে এটি আরকেএন নয় যে মিথ্যা ঠিকানা দিয়ে প্রতিক্রিয়া জানাবে?" এই আমরা মনে রাখবেন যে, সাধারণভাবে, অফিসিয়াল ক্লায়েন্ট RSA কী এমবেড করা আছে, অর্থাৎ তুমি কি শুধু চিহ্ন এই তথ্য. প্রকৃতপক্ষে, এটি ইতিমধ্যেই বাইপাস ব্লকিং সংক্রান্ত তথ্যের জন্য করা হচ্ছে যা ক্লায়েন্টরা অন্যান্য চ্যানেলের মাধ্যমে গ্রহণ করে (যৌক্তিকভাবে, এটি এমটিপ্রোটোতে করা যায় না; আপনাকে কোথায় সংযোগ করতে হবে তাও জানতে হবে)।

ঠিক আছে. ক্লায়েন্ট অনুমোদনের এই পর্যায়ে, আমরা এখনও অনুমোদিত নই এবং আমাদের আবেদন নিবন্ধন করিনি। আমরা এখন দেখতে চাই যে সার্ভারটি অননুমোদিত ব্যবহারকারীর কাছে উপলব্ধ পদ্ধতিতে কী প্রতিক্রিয়া জানায়৷ এবং এখানে…

ভ্যাসিলি, [10.07.18 14:45] https://core.telegram.org/method/help.getConfig

config#7dae33e0 [...] = Config;
help.getConfig#c4f9186b = Config;

https://core.telegram.org/api/datacenter

config#232d5905 [...] = Config;
help.getConfig#c4f9186b = Config;

স্কিমে, প্রথম আসে দ্বিতীয়

tdesktop স্কিমায় তৃতীয় মান হল

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

...আপনি লক্ষ্য করেছেন যে আমরা ইতিমধ্যেই একরকম API-এ চলে এসেছি, যেমন পরবর্তী স্তরে, এবং MTProto বিষয়ে কিছু মিস করেছেন? আকর্ষণ নেই:

ভ্যাসিলি, [28.06.18 02:04] মিম, তারা e2e-তে কিছু অ্যালগরিদমের মাধ্যমে গুঞ্জন করছে

Mtproto উভয় ডোমেনের জন্য এনক্রিপশন অ্যালগরিদম এবং কী সংজ্ঞায়িত করে, সেইসাথে কিছুটা মোড়ক গঠন

কিন্তু তারা ক্রমাগত স্ট্যাকের বিভিন্ন স্তর মিশ্রিত করে, তাই mtproto কোথায় শেষ হয়েছে এবং পরবর্তী স্তর শুরু হয়েছে তা সর্বদা পরিষ্কার নয়

তারা কিভাবে মিশ্রিত? ঠিক আছে, এখানে PFS-এর জন্য একই অস্থায়ী কী রয়েছে, উদাহরণস্বরূপ (প্রসঙ্গক্রমে, টেলিগ্রাম ডেস্কটপ এটি করতে পারে না)। এটি একটি API অনুরোধ দ্বারা কার্যকর করা হয় auth.bindTempAuthKey, অর্থাৎ উপরের স্তর থেকে। তবে একই সময়ে এটি নিম্ন স্তরে এনক্রিপশনে হস্তক্ষেপ করে - এর পরে, উদাহরণস্বরূপ, আপনাকে এটি আবার করতে হবে initConnection ইত্যাদি, এটা না মাত্র স্বাভাবিক অনুরোধ। এছাড়াও বিশেষত্ব হল যে আপনার কাছে প্রতি ডিসিতে শুধুমাত্র একটি অস্থায়ী কী থাকতে পারে, যদিও ক্ষেত্রটি auth_key_id প্রতিটি বার্তায় আপনাকে অন্তত প্রতিটি বার্তার কী পরিবর্তন করতে দেয় এবং সার্ভারের যে কোনো সময় অস্থায়ী কীটি "ভুলে যাওয়ার" অধিকার রয়েছে - ডকুমেন্টেশন এই ক্ষেত্রে কী করতে হবে তা বলে না... আচ্ছা, কেন পারে না ভবিষ্যত লবণের সেটের মতো আপনার কাছে বেশ কয়েকটি কী নেই, এবং? ..

MTProto থিম সম্পর্কে লক্ষণীয় আরও কয়েকটি বিষয় রয়েছে।

বার্তা বার্তা, msg_id, msg_seqno, নিশ্চিতকরণ, ভুল দিকে পিং এবং অন্যান্য বৈচিত্র্য

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

• লবণ - int64
• session_id - int64
• message_id — int64
• seq_no - int32

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

সার্ভারটিকে সেশনগুলি সম্পূর্ণভাবে ড্রপ করার অনুমতি দেওয়া হয় এবং অনেক কারণে এইভাবে প্রতিক্রিয়া জানানো হয়। আসলে, ক্লায়েন্ট পক্ষ থেকে একটি MTProto সেশন কি? এই দুটি সংখ্যা session_id и seq_no এই অধিবেশনের মধ্যে বার্তা. ভাল, এবং অন্তর্নিহিত TCP সংযোগ, অবশ্যই। ধরা যাক আমাদের ক্লায়েন্ট এখনও জানে না কিভাবে অনেক কিছু করতে হয়, সে সংযোগ বিচ্ছিন্ন করে আবার সংযোগ করেছে। যদি এটি দ্রুত ঘটে থাকে - নতুন টিসিপি সংযোগে পুরানো সেশন অব্যাহত থাকে, বৃদ্ধি করুন seq_no আরও যদি এটি একটি দীর্ঘ সময় নেয়, সার্ভার এটি মুছে ফেলতে পারে, কারণ এটির পাশে এটি একটি সারি, যেমন আমরা খুঁজে পেয়েছি।

এটা কি হওয়া উচিত seq_no? ওহ, এটি একটি চতুর প্রশ্ন. কি বোঝানো হয়েছিল তা সৎভাবে বোঝার চেষ্টা করুন:

বিষয়বস্তু-সম্পর্কিত বার্তা

একটি বার্তা যাতে একটি স্পষ্ট স্বীকৃতির প্রয়োজন হয়৷ এর মধ্যে সমস্ত ব্যবহারকারী এবং অনেক পরিষেবা বার্তা অন্তর্ভুক্ত রয়েছে, কার্যত সমস্ত কন্টেইনার এবং স্বীকৃতি ব্যতীত।

বার্তা ক্রম নম্বর (msg_seqno)

একটি 32-বিট সংখ্যা "সামগ্রী-সম্পর্কিত" বার্তাগুলির দ্বিগুণ সংখ্যার সমান (যার জন্য স্বীকৃতির প্রয়োজন, এবং বিশেষ করে যেগুলি ধারক নয়) এই বার্তার আগে প্রেরক দ্বারা তৈরি করা হয়েছে এবং পরবর্তীতে একটি দ্বারা বৃদ্ধি করা হয়েছে যদি বর্তমান বার্তাটি হয় বিষয়বস্তু-সম্পর্কিত বার্তা। একটি ধারক সর্বদা তার সম্পূর্ণ বিষয়বস্তুর পরে উত্পন্ন হয়; সুতরাং, এর ক্রম সংখ্যা এটিতে থাকা বার্তাগুলির ক্রম সংখ্যার চেয়ে বড় বা সমান।

এটি 1 দ্বারা বৃদ্ধির সাথে এবং তারপরে 2 দ্বারা অন্য একটি সার্কাস?... আমি সন্দেহ করি যে তারা প্রাথমিকভাবে "ACK-এর জন্য সর্বনিম্ন উল্লেখযোগ্য বিট, বাকিগুলি একটি সংখ্যা" বোঝাতে চেয়েছিল, কিন্তু ফলাফলটি সম্পূর্ণ একই নয় - বিশেষ করে, এটি বেরিয়ে আসে, পাঠানো যেতে পারে বিভিন্ন নিশ্চিতকরণ একই থাকার seq_no! কিভাবে? ঠিক আছে, উদাহরণস্বরূপ, সার্ভার আমাদের কিছু পাঠায়, এটি পাঠায় এবং আমরা নিজেরাই নীরব থাকি, শুধুমাত্র পরিষেবা বার্তাগুলির সাথে তার বার্তাগুলির প্রাপ্তি নিশ্চিত করে। এই ক্ষেত্রে, আমাদের বহির্গামী নিশ্চিতকরণ একই বহির্গামী নম্বর থাকবে। আপনি যদি TCP এর সাথে পরিচিত হন এবং মনে করেন যে এটি একরকম বন্য শোনাচ্ছে, তবে এটি খুব বন্য বলে মনে হচ্ছে না, কারণ TCP-তে seq_no পরিবর্তন হয় না, কিন্তু নিশ্চিতকরণ যায় seq_no অন্য দিকে, আমি তোমাকে বিরক্ত করতে তাড়াতাড়ি করব। নিশ্চিতকরণ MTProto প্রদান করা হয় না এ seq_no, TCP এর মত, কিন্তু দ্বারা msg_id !

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

এবং তাই, msg_id জন্য প্রয়োজন...

RPC: অনুরোধ, প্রতিক্রিয়া, ত্রুটি। নিশ্চিতকরণ

আপনি হয়তো লক্ষ্য করেছেন, ডায়াগ্রামে কোথাও কোনো বিশেষ "একটি RPC অনুরোধ করুন" টাইপ বা ফাংশন নেই, যদিও উত্তর আছে। সব পরে, আমরা বিষয়বস্তু সম্পর্কিত বার্তা আছে! এটাই, কোন বার্তা একটি অনুরোধ হতে পারে! বা হতে হবে না. সর্বোপরি, প্রতিটি হল msg_id. কিন্তু উত্তর আছে:

rpc_result#f35c6d01 req_msg_id:long result:Object = RpcResult;

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

হ্যাঁ?.. আর যদি ভাবো? সব পরে, RPC প্রতিক্রিয়া নিজেই একটি ক্ষেত্র আছে msg_id! আমাদের কি সার্ভারে চিৎকার করা দরকার "আপনি আমার উত্তরের উত্তর দিচ্ছেন না!"? এবং হ্যাঁ, নিশ্চিতকরণ সম্পর্কে কি ছিল? পৃষ্ঠা সম্পর্কে বার্তা সম্পর্কে বার্তা আমাদের বলেন কি

msgs_ack#62d6b459 msg_ids:Vector long = MsgsAck;

এবং এটা প্রতিটি পক্ষ দ্বারা করা আবশ্যক. তবে সব সময় নয়! আপনি যদি একটি RpcResult পেয়ে থাকেন তবে এটি নিজেই একটি নিশ্চিতকরণ হিসাবে কাজ করে। অর্থাৎ, সার্ভার MsgsAck-এর মাধ্যমে আপনার অনুরোধের জবাব দিতে পারে - যেমন, "আমি এটি পেয়েছি।" RpcResult অবিলম্বে প্রতিক্রিয়া জানাতে পারে। এটা উভয় হতে পারে.

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

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

rpc_error#2144ca19 error_code:int error_message:string = RpcError;

ওহ, কেউ চিৎকার করবে, এখানে আরও মানবিক বিন্যাস - একটি লাইন আছে! আপনার সময় নিন. এখানে ত্রুটির তালিকা, কিন্তু অবশ্যই সম্পূর্ণ নয়। এটি থেকে আমরা শিখেছি যে কোডটি কিছুটা এইরকম HTTP ত্রুটিগুলি (ভাল, অবশ্যই, প্রতিক্রিয়াগুলির শব্দার্থকে সম্মান করা হয় না, কিছু জায়গায় এগুলি কোডগুলির মধ্যে এলোমেলোভাবে বিতরণ করা হয়), এবং লাইনটি এমন দেখাচ্ছে CAPITAL_LETTERS_AND_NUMBERS. উদাহরণস্বরূপ, PHONE_NUMBER_OCCUPIED বা FILE_PART_Х_MISSING৷ ওয়েল, যে, আপনি এখনও এই লাইন প্রয়োজন হবে পার্স। উদাহরণস্বরূপ FLOOD_WAIT_3600 আপনি এক ঘন্টা অপেক্ষা করতে হবে মানে, এবং PHONE_MIGRATE_5, এই উপসর্গ সহ একটি টেলিফোন নম্বর অবশ্যই 5 তম ডিসিতে নিবন্ধিত হতে হবে৷ আমরা একটি টাইপ ভাষা আছে, তাই না? আমাদের একটি স্ট্রিং থেকে একটি যুক্তির প্রয়োজন নেই, নিয়মিত তারা করবে, ঠিক আছে।

আবার, এটি পরিষেবা বার্তা পৃষ্ঠায় নয়, তবে, এই প্রকল্পের সাথে ইতিমধ্যে স্বাভাবিক হিসাবে, তথ্য পাওয়া যেতে পারে অন্য ডকুমেন্টেশন পৃষ্ঠায়। অথবা সন্দেহ করা. প্রথমত, দেখুন, টাইপিং/লেয়ার লঙ্ঘন - RpcError মধ্যে নেস্ট করা যেতে পারে RpcResult. বাইরে নয় কেন? আমরা কী আমলে নিলাম না?... সেই অনুযায়ী, সেই গ্যারান্টি কোথায়? RpcError এম্বেড করা যাবে না RpcResult, কিন্তু সরাসরি বা অন্য ধরনের নেস্টেড হতে হবে?.. এবং যদি এটি না পারে, কেন এটি শীর্ষ স্তরে নয়, যেমন এটা নাই req_msg_id ? ..

কিন্তু এর পরিষেবা বার্তা সম্পর্কে অবিরত করা যাক. ক্লায়েন্ট মনে করতে পারে যে সার্ভারটি দীর্ঘ সময়ের জন্য চিন্তা করছে এবং এই দুর্দান্ত অনুরোধটি করতে পারে:

rpc_drop_answer#58e4a740 req_msg_id:long = RpcDropAnswer;

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

মাদকাসক্তি: বার্তা স্ট্যাটাস

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

এটা নির্দোষভাবে শুরু হয়, নিশ্চিতকরণের সাথে। পরবর্তী তারা সম্পর্কে আমাদের বলুন

bad_msg_notification#a7eff811 bad_msg_id:long bad_msg_seqno:int error_code:int = BadMsgNotification;
bad_server_salt#edab447b bad_msg_id:long bad_msg_seqno:int error_code:int new_server_salt:long = BadMsgNotification;

ঠিক আছে, যারা MTProto এর সাথে কাজ শুরু করে তাদের সাথে "সংশোধিত - পুনরায় সংকলিত - চালু" চক্রের সাথে মোকাবিলা করতে হবে, সংখ্যার ত্রুটি বা লবণ যা সম্পাদনা করার সময় খারাপ হতে পারে তা একটি সাধারণ বিষয়। যাইহোক, এখানে দুটি পয়েন্ট আছে:

1. এর মানে মূল বার্তা হারিয়ে গেছে। আমাদের কিছু সারি তৈরি করতে হবে, আমরা পরে দেখব।
2. এই অদ্ভুত ত্রুটি সংখ্যা কি? 16, 17, 18, 19, 20, 32, 33, 34, 35, 48, 64... অন্য সংখ্যাগুলো কোথায়, টমি?

ডকুমেন্টেশন বলে:

উদ্দেশ্য হল যে error_code মানগুলিকে গোষ্ঠীবদ্ধ করা হয়েছে (error_code >> 4): উদাহরণস্বরূপ, 0x40 — 0x4f কোডগুলি কন্টেইনার পচনের ত্রুটিগুলির সাথে মিলে যায়৷

কিন্তু, প্রথমত, অন্য দিকে একটি স্থানান্তর, এবং দ্বিতীয়ত, এটি কোন ব্যাপার না, অন্যান্য কোডগুলি কোথায়? লেখকের মাথায়?.. যাইহোক, এগুলো তুচ্ছ কথা।

বার্তা স্থিতি এবং বার্তা কপি সম্পর্কে বার্তাগুলিতে আসক্তি শুরু হয়:

• বার্তা স্থিতি তথ্যের জন্য অনুরোধ
  যদি উভয় পক্ষ কিছু সময়ের জন্য তার বহির্গামী বার্তাগুলির স্থিতি সম্পর্কে তথ্য না পায় তবে এটি স্পষ্টভাবে অন্য পক্ষের কাছ থেকে অনুরোধ করতে পারে:
  msgs_state_req#da69fb52 msg_ids:Vector long = MsgsStateReq;
• বার্তার স্থিতি সম্পর্কিত তথ্যমূলক বার্তা
  msgs_state_info#04deb57d req_msg_id:long info:string = MsgsStateInfo;
  এখানে, info একটি স্ট্রিং যা ইনকামিং msg_ids তালিকা থেকে প্রতিটি বার্তার জন্য বার্তা স্থিতির ঠিক এক বাইট ধারণ করে:
  • 1 = বার্তা সম্পর্কে কিছুই জানা নেই (msg_id খুব কম, অন্য পক্ষ এটি ভুলে যেতে পারে)
  • 2 = বার্তা গৃহীত হয়নি (msg_id সংরক্ষিত শনাক্তকারীর সীমার মধ্যে পড়ে; তবে, অন্য পক্ষ অবশ্যই এরকম একটি বার্তা পায়নি)
  • 3 = বার্তা গৃহীত হয়নি (msg_id খুব বেশি; তবে, অন্য পক্ষ অবশ্যই এটি এখনও গ্রহণ করেনি)
  • 4 = বার্তা গৃহীত (মনে রাখবেন যে এই প্রতিক্রিয়াটি একই সময়ে একটি রসিদ স্বীকৃতি)
  • +8 = বার্তা ইতিমধ্যেই স্বীকৃত
  • +16 = বার্তার স্বীকৃতির প্রয়োজন নেই
  • +32 = বার্তার মধ্যে থাকা RPC ক্যোয়ারী প্রক্রিয়া করা হচ্ছে বা প্রক্রিয়াকরণ ইতিমধ্যেই সম্পূর্ণ
  • +64 = ইতিমধ্যে তৈরি করা বার্তার বিষয়বস্তু-সম্পর্কিত প্রতিক্রিয়া
  • +128 = অন্য পক্ষ জানে যে বার্তা ইতিমধ্যেই গৃহীত হয়েছে
    এই প্রতিক্রিয়া একটি স্বীকৃতি প্রয়োজন হয় না. এটি প্রাসঙ্গিক msgs_state_req-এর একটি স্বীকৃতি, এবং নিজেই।
    মনে রাখবেন যে যদি হঠাৎ দেখা যায় যে অন্য পক্ষের কাছে এমন কোনও বার্তা নেই যা দেখে মনে হচ্ছে এটি তাকে পাঠানো হয়েছে, বার্তাটি আবার পাঠানো যেতে পারে। এমনকি যদি অন্য পক্ষ একই সময়ে বার্তাটির দুটি অনুলিপি গ্রহণ করে তবে নকলটি উপেক্ষা করা হবে। (যদি খুব বেশি সময় চলে যায়, এবং আসল msg_id আর বৈধ না থাকে, তাহলে বার্তাটি msg_copy এ মোড়ানো হবে)।
• বার্তার স্থিতির স্বেচ্ছাসেবী যোগাযোগ
  উভয় পক্ষ স্বেচ্ছায় অন্য পক্ষকে অন্য পক্ষের দ্বারা প্রেরিত বার্তাগুলির অবস্থা সম্পর্কে অবহিত করতে পারে।
  msgs_all_info#8cc0d131 msg_ids:Vector long info:string = MsgsAllInfo
• এক বার্তার স্থিতির সম্প্রসারিত স্বেচ্ছাসেবী যোগাযোগ
  ...
  msg_detailed_info#276d3ec6 msg_id:long answer_msg_id:long bytes:int status:int = MsgDetailedInfo;
msg_new_detailed_info#809db6df answer_msg_id:long bytes:int status:int = MsgDetailedInfo;
• বার্তা পুনরায় পাঠাতে সুস্পষ্ট অনুরোধ
  msg_resend_req#7d861a08 msg_ids:Vector long = MsgResendReq;
  রিমোট পার্টি অবিলম্বে অনুরোধ করা বার্তাগুলি পুনরায় প্রেরণ করে প্রতিক্রিয়া জানায় […]
• উত্তর পুনরায় পাঠাতে সুস্পষ্ট অনুরোধ
  msg_resend_ans_req#8610baeb msg_ids:Vector long = MsgResendReq;
  রিমোট পার্টি অবিলম্বে পুনরায় পাঠানোর মাধ্যমে সাড়া দেয় উত্তর অনুরোধ করা বার্তাগুলিতে […]
• বার্তা অনুলিপি
  কিছু পরিস্থিতিতে, একটি msg_id সহ একটি পুরানো বার্তা যা আর বৈধ নয় আবার পাঠানোর প্রয়োজন৷ তারপর, এটি একটি অনুলিপি পাত্রে মোড়ানো হয়:
  msg_copy#e06046b2 orig_message:Message = MessageCopy;
  একবার প্রাপ্ত হলে, বার্তাটি এমনভাবে প্রক্রিয়া করা হয় যেন মোড়কটি সেখানে নেই। যাইহোক, যদি নিশ্চিতভাবে জানা যায় যে orig_message.msg_id বার্তাটি গৃহীত হয়েছে, তাহলে নতুন বার্তাটি প্রক্রিয়া করা হয় না (যদিও একই সময়ে, এটি এবং orig_message.msg_id স্বীকার করা হয়)। orig_message.msg_id-এর মান কন্টেইনারের msg_id থেকে কম হতে হবে।

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

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

পিং এবং সময়. সারি।

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

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

ইহা কি জন্য ঘটিতেছে? সম্ভবত, সার্ভার প্রোগ্রামাররা ক্লাস্টারের মধ্যে নির্ভরযোগ্যতা নিশ্চিত করতে পারেনি, এমনকি সামনের ব্যালেন্সারে বাফারিং করতে পারেনি এবং এই সমস্যাটি ক্লায়েন্টের কাছে স্থানান্তর করেছে। হতাশা থেকে, ভ্যাসিলি একটি বিকল্প বিকল্প বাস্তবায়ন করার চেষ্টা করেছিলেন, শুধুমাত্র দুটি সারি দিয়ে, TCP থেকে অ্যালগরিদম ব্যবহার করে - সার্ভারে RTT পরিমাপ করা এবং অনিশ্চিত অনুরোধের সংখ্যার উপর নির্ভর করে "উইন্ডো" (বার্তাগুলিতে) এর আকার সামঞ্জস্য করা। অর্থাৎ, সার্ভারের লোডের মূল্যায়নের জন্য এই ধরনের একটি মোটামুটি হিউরিস্টিক হল আমাদের কতগুলি অনুরোধ একই সময়ে চিবানো যায় এবং হারানো যায় না।

আচ্ছা, যে, বুঝতে পারছেন, তাই না? যদি আপনাকে টিসিপির উপরে চলমান একটি প্রোটোকলের উপরে আবার টিসিপি প্রয়োগ করতে হয় তবে এটি একটি খুব খারাপভাবে ডিজাইন করা প্রোটোকল নির্দেশ করে।

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

1. এটি একটি সারিতে রয়েছে এবং এনক্রিপশনের জন্য অপেক্ষা করছে৷
2. নিযুক্ত msg_id এবং বার্তাটি অন্য সারিতে চলে গেছে - সম্ভাব্য ফরওয়ার্ডিং; সকেটে পাঠান।
3. ক) সার্ভারটি MsgsAck এর প্রতিক্রিয়া জানিয়েছে - বার্তাটি বিতরণ করা হয়েছিল, আমরা এটিকে "অন্যান্য সারি" থেকে মুছে ফেলি৷
   খ) অথবা বিপরীতভাবে, তিনি কিছু পছন্দ করেননি, তিনি ব্যাডএমএসজি-এর উত্তর দিয়েছেন - "অন্য সারি" থেকে আবার পাঠান
   গ) কিছুই জানা নেই, বার্তাটি অন্য সারি থেকে রিসেন্ট করতে হবে - তবে কখন তা সঠিকভাবে জানা যায়নি।
4. সার্ভার অবশেষে প্রতিক্রিয়া RpcResult - প্রকৃত প্রতিক্রিয়া (বা ত্রুটি) - শুধুমাত্র বিতরণ করা হয় না, কিন্তু প্রক্রিয়া করা হয়।

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

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

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

একটি সার্ভার সাধারণত একটি RPC প্রতিক্রিয়া ব্যবহার করে একটি ক্লায়েন্ট (সাধারণত, একটি RPC ক্যোয়ারী) থেকে একটি বার্তার প্রাপ্তি স্বীকার করে। যদি একটি প্রতিক্রিয়া দীর্ঘ সময়ের জন্য আসে, একটি সার্ভার প্রথমে একটি রসিদ স্বীকৃতি পাঠাতে পারে, এবং কিছুটা পরে, RPC প্রতিক্রিয়া নিজেই।

একটি ক্লায়েন্ট সাধারণত একটি সার্ভার থেকে একটি বার্তার প্রাপ্তি স্বীকার করে (সাধারণত, একটি RPC প্রতিক্রিয়া) পরবর্তী RPC কোয়েরিতে একটি স্বীকৃতি যোগ করে যদি এটি খুব দেরি না হয় (যদি এটি তৈরি করা হয়, বলুন, প্রাপ্তির 60-120 সেকেন্ড পরে) সার্ভার থেকে একটি বার্তার)। যাইহোক, যদি দীর্ঘ সময়ের জন্য সার্ভারে বার্তা পাঠানোর কোন কারণ না থাকে বা সার্ভার থেকে প্রচুর পরিমাণে অস্বীকৃত বার্তা থাকে (বলুন, 16-এর বেশি), ক্লায়েন্ট একটি স্বতন্ত্র স্বীকৃতি প্রেরণ করে।

... আমি অনুবাদ করি: আমরা নিজেরাই জানি না যে আমাদের এটি কতটা এবং কীভাবে প্রয়োজন, তাই ধরে নিই যে এটি এমন হতে দিন।

এবং পিংস সম্পর্কে:

পিং বার্তা (PING/PONG)

ping#7abe77ec ping_id:long = Pong;

একটি প্রতিক্রিয়া সাধারণত একই সংযোগে ফিরে আসে:

pong#347773c5 msg_id:long ping_id:long = Pong;

এই বার্তাগুলির স্বীকৃতির প্রয়োজন নেই। একটি পং শুধুমাত্র একটি পিং এর প্রতিক্রিয়া হিসাবে প্রেরণ করা হয় যখন একটি পিং উভয় পক্ষের দ্বারা শুরু করা যেতে পারে।

বিলম্বিত সংযোগ বন্ধ + PING

ping_delay_disconnect#f3427b8c ping_id:long disconnect_delay:int = Pong;

পিং এর মত কাজ করে। উপরন্তু, এটি প্রাপ্তির পরে, সার্ভারটি একটি টাইমার শুরু করে যা বর্তমান সংযোগটি বন্ধ করে দেবে বিচ্ছিন্ন_বিচ্ছেদ সেকেন্ড পরে যদি না এটি একই ধরণের একটি নতুন বার্তা না পায় যা স্বয়ংক্রিয়ভাবে পূর্ববর্তী সমস্ত টাইমার পুনরায় সেট করে। যদি ক্লায়েন্ট প্রতি 60 সেকেন্ডে একবার এই পিংগুলি পাঠায়, উদাহরণস্বরূপ, এটি 75 সেকেন্ডের সমান disconnect_delay সেট করতে পারে।

তুমি কি পাগল?! 60 সেকেন্ডের মধ্যে, ট্রেনটি স্টেশনে প্রবেশ করবে, নামবে এবং যাত্রীদের তুলে নেবে এবং আবার টানেলে যোগাযোগ হারিয়ে ফেলবে। 120 সেকেন্ডের মধ্যে, যখন আপনি এটি শুনতে পাবেন, এটি অন্য একটিতে পৌঁছাবে এবং সম্ভবত সংযোগটি ভেঙে যাবে। ঠিক আছে, এটা স্পষ্ট যে পা কোথা থেকে আসছে - "আমি একটি রিং শুনেছি, কিন্তু জানি না এটি কোথায়", সেখানে Nagl এর অ্যালগরিদম এবং TCP_NODELAY বিকল্প রয়েছে, ইন্টারেক্টিভ কাজের উদ্দেশ্যে। কিন্তু, ক্ষমা করবেন, এর ডিফল্ট মান - 200 ধরে রাখুন মিল্লিসেকেন্ড আপনি যদি সত্যিই অনুরূপ কিছু চিত্রিত করতে চান এবং সম্ভাব্য কয়েকটি প্যাকেটে সংরক্ষণ করতে চান, তাহলে এটি 5 সেকেন্ডের জন্য বন্ধ রাখুন, বা "ব্যবহারকারী টাইপ করছেন..." মেসেজ টাইমআউট এখন। কিন্তু আর না.

এবং অবশেষে, pings. অর্থাৎ, TCP সংযোগের জীবন্ততা পরীক্ষা করা হচ্ছে। এটা মজার, কিন্তু প্রায় 10 বছর আগে আমি আমাদের অনুষদের ডর্মের মেসেঞ্জার সম্পর্কে একটি সমালোচনামূলক পাঠ্য লিখেছিলাম - সেখানকার লেখকরাও ক্লায়েন্ট থেকে সার্ভারটি পিং করেছেন, এবং বিপরীতে নয়। কিন্তু 3য় বর্ষের শিক্ষার্থীরা এক জিনিস, এবং একটি আন্তর্জাতিক অফিস অন্য জিনিস, তাই না?

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

চ্যাট/আইএম সিস্টেমগুলি একটি অতিরিক্ত কারণে দ্বিতীয় ক্ষেত্রে পড়ে - অনলাইন স্ট্যাটাস৷ ব্যবহারকারী যদি "পড়ে পড়ে" তবে আপনাকে তার কথোপকথনকে এ সম্পর্কে অবহিত করতে হবে। অন্যথায়, আপনি একটি ভুলের সাথে শেষ হবেন যা জাব্বারের নির্মাতারা করেছেন (এবং 20 বছর ধরে সংশোধন করেছেন) - ব্যবহারকারী সংযোগ বিচ্ছিন্ন করেছে, কিন্তু তারা তাকে বার্তা লিখতে থাকে, এই বিশ্বাস করে যে সে অনলাইনে রয়েছে (এগুলিও সম্পূর্ণভাবে হারিয়ে গেছে) সংযোগ বিচ্ছিন্ন হওয়ার কয়েক মিনিট আগে)। না, TCP_KEEPALIVE বিকল্পটি, যা অনেক লোক বুঝতে পারে না যে TCP টাইমারগুলি কীভাবে এলোমেলোভাবে কাজ করে (সেকেন্ডের দশের মতো বন্য মান সেট করে), এখানে সাহায্য করবে না - আপনাকে নিশ্চিত করতে হবে যে শুধুমাত্র OS কার্নেল নয় ব্যবহারকারীর মেশিনটি জীবিত, কিন্তু স্বাভাবিকভাবে কাজ করে, প্রতিক্রিয়া জানাতে সক্ষম এবং অ্যাপ্লিকেশনটি নিজেই (আপনি কি মনে করেন এটি হিমায়িত হতে পারে না? উবুন্টু 18.04-এ টেলিগ্রাম ডেস্কটপ আমার জন্য একাধিকবার নিথর হয়ে গেছে)।

এজন্য আপনাকে পিং করতে হবে সার্ভার ক্লায়েন্ট, এবং তদ্বিপরীত না - যদি ক্লায়েন্ট এটি করে, যদি সংযোগটি ভেঙে যায়, পিং বিতরণ করা হবে না, লক্ষ্য অর্জন করা হবে না।

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

এটা কিভাবে ডিজাইন করা উচিত ছিল?

আমি বিশ্বাস করি যে উপরের তথ্যগুলি স্পষ্টভাবে নির্দেশ করে যে টেলিগ্রাম/ভিকন্টাক্টে টিম কম্পিউটার নেটওয়ার্কের পরিবহণ (এবং নিম্নতর) স্তরের ক্ষেত্রে এবং প্রাসঙ্গিক বিষয়ে তাদের নিম্ন যোগ্যতার ক্ষেত্রে খুব বেশি দক্ষ নয়।

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

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

1. ক্লায়েন্টের সাথে TCP সংযোগ ধারণকারী সার্ভার দায়িত্ব নেয় - যদি এটি সকেট থেকে পড়ে থাকে, তাহলে অনুগ্রহ করে স্বীকার করুন, প্রক্রিয়া করুন বা একটি ত্রুটি ফেরত দিন, কোন ক্ষতি হবে না। তারপর নিশ্চিতকরণটি আইডিগুলির একটি ভেক্টর নয়, তবে কেবলমাত্র "শেষ প্রাপ্ত seq_no" - শুধু একটি সংখ্যা, যেমন TCP (দুটি সংখ্যা - আপনার seq এবং নিশ্চিত হওয়া)। আমরা সবসময় অধিবেশনের মধ্যে থাকি, তাই না?
2. রিপ্লে আক্রমণ প্রতিরোধের টাইমস্ট্যাম্প একটি পৃথক ক্ষেত্র হয়ে যায়, একটি লা ননসে। এটি পরীক্ষা করা হয়, কিন্তু অন্য কিছু প্রভাবিত করে না। যথেষ্ট এবং uint32 - যদি আমাদের লবণ অন্তত প্রতি অর্ধেক দিনে পরিবর্তিত হয়, আমরা বর্তমান সময়ের একটি পূর্ণসংখ্যা অংশের লো-অর্ডার বিটগুলিতে 16 বিট বরাদ্দ করতে পারি, বাকিগুলি - সেকেন্ডের একটি ভগ্নাংশে (এখনকার মতো)।
3. সরানো হয়েছে msg_id মোটেও - ব্যাকএন্ডে অনুরোধগুলিকে আলাদা করার দৃষ্টিকোণ থেকে, প্রথমত, ক্লায়েন্ট আইডি এবং দ্বিতীয়ত, সেশন আইডি, সেগুলিকে সংযুক্ত করুন৷ সেই অনুযায়ী, অনুরোধ শনাক্তকারী হিসাবে শুধুমাত্র একটি জিনিসই যথেষ্ট seq_no.

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

এপিআই?

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

মনোযোগ, এখন নিবন্ধে পার্লের একমাত্র উদাহরণ থাকবে! (যারা সিনট্যাক্সের সাথে পরিচিত নয় তাদের জন্য, আশীর্বাদের প্রথম যুক্তিটি হল বস্তুর ডেটা কাঠামো, দ্বিতীয়টি হল এর শ্রেণী):

2019.10.24 12:00:51 $1 = {
'cb' => 'TeleUpd::__ANON__',
'out' => bless( {
'filter' => bless( {}, 'Telegram::ChannelMessagesFilterEmpty' ),
'channel' => bless( {
'access_hash' => '-6698103710539760874',
'channel_id' => '1380524958'
}, 'Telegram::InputPeerChannel' ),
'pts' => '158503',
'flags' => 0,
'limit' => 0
}, 'Telegram::Updates::GetChannelDifference' ),
'req_id' => '6751291954012037292'
};
2019.10.24 12:00:51 $1 = {
'in' => bless( {
'req_msg_id' => '6751291954012037292',
'result' => bless( {
'pts' => 158508,
'flags' => 3,
'final' => 1,
'new_messages' => [],
'users' => [],
'chats' => [
bless( {
'title' => 'Хулиномика',
'username' => 'hoolinomics',
'flags' => 8288,
'id' => 1380524958,
'access_hash' => '-6698103710539760874',
'broadcast' => 1,
'version' => 0,
'photo' => bless( {
'photo_small' => bless( {
'volume_id' => 246933270,
'file_reference' => '
'secret' => '1854156056801727328',
'local_id' => 228648,
'dc_id' => 2
}, 'Telegram::FileLocation' ),
'photo_big' => bless( {
'dc_id' => 2,
'local_id' => 228650,
'file_reference' => '
'secret' => '1275570353387113110',
'volume_id' => 246933270
}, 'Telegram::FileLocation' )
}, 'Telegram::ChatPhoto' ),
'date' => 1531221081
}, 'Telegram::Channel' )
],
'timeout' => 300,
'other_updates' => [
bless( {
'pts_count' => 0,
'message' => bless( {
'post' => 1,
'id' => 852,
'flags' => 50368,
'views' => 8013,
'entities' => [
bless( {
'length' => 20,
'offset' => 0
}, 'Telegram::MessageEntityBold' ),
bless( {
'length' => 18,
'offset' => 480,
'url' => 'https://alexeymarkov.livejournal.com/[url_вырезан].html'
}, 'Telegram::MessageEntityTextUrl' )
],
'reply_markup' => bless( {
'rows' => [
bless( {
'buttons' => [
bless( {
'text' => '???? 165',
'data' => 'send_reaction_0'
}, 'Telegram::KeyboardButtonCallback' ),
bless( {
'data' => 'send_reaction_1',
'text' => '???? 9'
}, 'Telegram::KeyboardButtonCallback' )
]
}, 'Telegram::KeyboardButtonRow' )
]
}, 'Telegram::ReplyInlineMarkup' ),
'message' => 'А вот и новая книга! 
// [текст сообщения вырезан чтоб не нарушать правил Хабра о рекламе]
напечатаю.',
'to_id' => bless( {
'channel_id' => 1380524958
}, 'Telegram::PeerChannel' ),
'date' => 1571724559,
'edit_date' => 1571907562
}, 'Telegram::Message' ),
'pts' => 158508
}, 'Telegram::UpdateEditChannelMessage' ),
bless( {
'pts' => 158508,
'message' => bless( {
'edit_date' => 1571907589,
'to_id' => bless( {
'channel_id' => 1380524958
}, 'Telegram::PeerChannel' ),
'date' => 1571807301,
'message' => 'Почему Вы считаете Facebook плохой компанией? Можете прокомментировать? По-моему, это шикарная компания. Без долгов, с хорошей прибылью, а если решат дивы платить, то и еще могут нехило подорожать.
Для меня ответ совершенно очевиден: потому что Facebook делает ужасный по качеству продукт. Да, у него монопольное положение и да, им пользуется огромное количество людей. Но мир не стоит на месте. Когда-то владельцам Нокии было смешно от первого Айфона. Они думали, что лучше Нокии ничего быть не может и она навсегда останется самым удобным, красивым и твёрдым телефоном - и доля рынка это красноречиво демонстрировала. Теперь им не смешно.
Конечно, рептилоиды сопротивляются напору молодых гениев: так Цукербергом был пожран Whatsapp, потом Instagram. Но всё им не пожрать, Паша Дуров не продаётся!
Так будет и с Фейсбуком. Нельзя всё время делать говно. Кто-то когда-то сделает хороший продукт, куда всё и уйдут.
#соцсети #facebook #акции #рептилоиды',
'reply_markup' => bless( {
'rows' => [
bless( {
'buttons' => [
bless( {
'data' => 'send_reaction_0',
'text' => '???? 452'
}, 'Telegram::KeyboardButtonCallback' ),
bless( {
'text' => '???? 21',
'data' => 'send_reaction_1'
}, 'Telegram::KeyboardButtonCallback' )
]
}, 'Telegram::KeyboardButtonRow' )
]
}, 'Telegram::ReplyInlineMarkup' ),
'entities' => [
bless( {
'length' => 199,
'offset' => 0
}, 'Telegram::MessageEntityBold' ),
bless( {
'length' => 8,
'offset' => 919
}, 'Telegram::MessageEntityHashtag' ),
bless( {
'offset' => 928,
'length' => 9
}, 'Telegram::MessageEntityHashtag' ),
bless( {
'length' => 6,
'offset' => 938
}, 'Telegram::MessageEntityHashtag' ),
bless( {
'length' => 11,
'offset' => 945
}, 'Telegram::MessageEntityHashtag' )
],
'views' => 6964,
'flags' => 50368,
'id' => 854,
'post' => 1
}, 'Telegram::Message' ),
'pts_count' => 0
}, 'Telegram::UpdateEditChannelMessage' ),
bless( {
'message' => bless( {
'reply_markup' => bless( {
'rows' => [
bless( {
'buttons' => [
bless( {
'data' => 'send_reaction_0',
'text' => '???? 213'
}, 'Telegram::KeyboardButtonCallback' ),
bless( {
'data' => 'send_reaction_1',
'text' => '???? 8'
}, 'Telegram::KeyboardButtonCallback' )
]
}, 'Telegram::KeyboardButtonRow' )
]
}, 'Telegram::ReplyInlineMarkup' ),
'views' => 2940,
'entities' => [
bless( {
'length' => 609,
'offset' => 348
}, 'Telegram::MessageEntityItalic' )
],
'flags' => 50368,
'post' => 1,
'id' => 857,
'edit_date' => 1571907636,
'date' => 1571902479,
'to_id' => bless( {
'channel_id' => 1380524958
}, 'Telegram::PeerChannel' ),
'message' => 'Пост про 1С вызвал бурную полемику. Человек 10 (видимо, 1с-программистов) единодушно написали:
// [текст сообщения вырезан чтоб не нарушать правил Хабра о рекламе]
Я бы добавил, что блестящая у 1С дистрибуция, а маркетинг... ну, такое.'
}, 'Telegram::Message' ),
'pts_count' => 0,
'pts' => 158508
}, 'Telegram::UpdateEditChannelMessage' ),
bless( {
'pts' => 158508,
'pts_count' => 0,
'message' => bless( {
'message' => 'Здравствуйте, расскажите, пожалуйста, чем вредит экономике 1С?
// [текст сообщения вырезан чтоб не нарушать правил Хабра о рекламе]
#софт #it #экономика',
'edit_date' => 1571907650,
'date' => 1571893707,
'to_id' => bless( {
'channel_id' => 1380524958
}, 'Telegram::PeerChannel' ),
'flags' => 50368,
'post' => 1,
'id' => 856,
'reply_markup' => bless( {
'rows' => [
bless( {
'buttons' => [
bless( {
'data' => 'send_reaction_0',
'text' => '???? 360'
}, 'Telegram::KeyboardButtonCallback' ),
bless( {
'data' => 'send_reaction_1',
'text' => '???? 32'
}, 'Telegram::KeyboardButtonCallback' )
]
}, 'Telegram::KeyboardButtonRow' )
]
}, 'Telegram::ReplyInlineMarkup' ),
'views' => 4416,
'entities' => [
bless( {
'offset' => 0,
'length' => 64
}, 'Telegram::MessageEntityBold' ),
bless( {
'offset' => 1551,
'length' => 5
}, 'Telegram::MessageEntityHashtag' ),
bless( {
'length' => 3,
'offset' => 1557
}, 'Telegram::MessageEntityHashtag' ),
bless( {
'offset' => 1561,
'length' => 10
}, 'Telegram::MessageEntityHashtag' )
]
}, 'Telegram::Message' )
}, 'Telegram::UpdateEditChannelMessage' )
]
}, 'Telegram::Updates::ChannelDifference' )
}, 'MTProto::RpcResult' )
};
2019.10.24 12:00:51 $1 = {
'in' => bless( {
'update' => bless( {
'user_id' => 2507460,
'status' => bless( {
'was_online' => 1571907651
}, 'Telegram::UserStatusOffline' )
}, 'Telegram::UpdateUserStatus' ),
'date' => 1571907650
}, 'Telegram::UpdateShort' )
};
2019.10.24 12:05:46 $1 = {
'in' => bless( {
'chats' => [],
'date' => 1571907946,
'seq' => 0,
'updates' => [
bless( {
'max_id' => 141719,
'channel_id' => 1295963795
}, 'Telegram::UpdateReadChannelInbox' )
],
'users' => []
}, 'Telegram::Updates' )
};
2019.10.24 13:01:23 $1 = {
'in' => bless( {
'server_salt' => '4914425622822907323',
'unique_id' => '5297282355827493819',
'first_msg_id' => '6751307555044380692'
}, 'MTProto::NewSessionCreated' )
};
2019.10.24 13:24:21 $1 = {
'in' => bless( {
'chats' => [
bless( {
'username' => 'freebsd_ru',
'version' => 0,
'flags' => 5440,
'title' => 'freebsd_ru',
'min' => 1,
'photo' => bless( {
'photo_small' => bless( {
'local_id' => 328733,
'volume_id' => 235140688,
'dc_id' => 2,
'file_reference' => '
'secret' => '4426006807282303416'
}, 'Telegram::FileLocation' ),
'photo_big' => bless( {
'dc_id' => 2,
'file_reference' => '
'volume_id' => 235140688,
'local_id' => 328735,
'secret' => '71251192991540083'
}, 'Telegram::FileLocation' )
}, 'Telegram::ChatPhoto' ),
'date' => 1461248502,
'id' => 1038300508,
'democracy' => 1,
'megagroup' => 1
}, 'Telegram::Channel' )
],
'users' => [
bless( {
'last_name' => 'Panov',
'flags' => 1048646,
'min' => 1,
'id' => 82234609,
'status' => bless( {}, 'Telegram::UserStatusRecently' ),
'first_name' => 'Dima'
}, 'Telegram::User' )
],
'seq' => 0,
'date' => 1571912647,
'updates' => [
bless( {
'pts' => 137596,
'message' => bless( {
'flags' => 256,
'message' => 'Создать джейл с именем покороче ??',
'to_id' => bless( {
'channel_id' => 1038300508
}, 'Telegram::PeerChannel' ),
'id' => 119634,
'date' => 1571912647,
'from_id' => 82234609
}, 'Telegram::Message' ),
'pts_count' => 1
}, 'Telegram::UpdateNewChannelMessage' )
]
}, 'Telegram::Updates' )
};

হ্যাঁ, উদ্দেশ্যমূলকভাবে একটি স্পয়লার নয় - আপনি যদি এটি এখনও না পড়ে থাকেন তবে এগিয়ে যান এবং এটি করুন!

ওহ, ওয়াই~~... এটা কেমন দেখাচ্ছে? খুব পরিচিত কিছু... হতে পারে এটি JSON-এর একটি সাধারণ ওয়েব API-এর ডেটা স্ট্রাকচার, ব্যতীত ক্লাসগুলিও অবজেক্টের সাথে সংযুক্ত থাকে?...

তাহলে এইভাবে দেখা যাচ্ছে... কমরেডরা, এটা কিসের?... এত প্রচেষ্টা - এবং আমরা যেখানে ওয়েব প্রোগ্রামাররা সেখানে বিশ্রাম নিতে থামলাম। সবেমাত্র শুরু হইতেছে?..HTTPS এর উপর JSON কি সহজ হবে না?! বিনিময়ে আমরা কী পেলাম? প্রচেষ্টা এটা মূল্য ছিল?

আসুন মূল্যায়ন করি যে TL+MTProto আমাদের কী দিয়েছে এবং কী বিকল্পগুলি সম্ভব। ভাল, HTTP, যা অনুরোধ-প্রতিক্রিয়া মডেলের উপর ফোকাস করে, এটি একটি খারাপ ফিট, তবে অন্তত টিএলএসের উপরে কিছু?

কমপ্যাক্ট সিরিয়ালাইজেশন। এই ডাটা স্ট্রাকচার দেখে, JSON এর মতো, আমার মনে আছে এর বাইনারি ভার্সন আছে। আসুন MsgPack কে অপর্যাপ্তভাবে এক্সটেনসিবল হিসাবে চিহ্নিত করি, তবে সেখানে, উদাহরণস্বরূপ, CBOR - যাইহোক, একটি মান বর্ণিত আছে RFC 7049. এটি সংজ্ঞায়িত করার জন্য এটি উল্লেখযোগ্য ট্যাগ, একটি সম্প্রসারণ প্রক্রিয়া হিসাবে, এবং মধ্যে ইতিমধ্যে মানসম্মত সেখানে:

• 25 + 256 - লাইন নম্বরের রেফারেন্স সহ বারবার লাইন প্রতিস্থাপন করা, যেমন একটি সস্তা কম্প্রেশন পদ্ধতি
• 26 - ক্লাসের নাম এবং কনস্ট্রাক্টর আর্গুমেন্ট সহ ক্রমিক পার্ল অবজেক্ট
• 27 - টাইপ নাম এবং কনস্ট্রাক্টর আর্গুমেন্ট সহ ক্রমিক ভাষা-স্বাধীন বস্তু

ঠিক আছে, আমি স্ট্রিং এবং অবজেক্ট প্যাকিং সক্ষম করে TL এবং CBOR-এ একই ডেটা সিরিয়ালাইজ করার চেষ্টা করেছি। ফলাফল একটি মেগাবাইট থেকে কোথাও CBOR এর পক্ষে পরিবর্তিত হতে শুরু করে:

cborlen=1039673 tl_len=1095092

এবং তাই, উপসংহার: তুলনামূলক দক্ষতার সাথে সিঙ্ক্রোনাইজেশন ব্যর্থতা বা অজানা শনাক্তকারীর সমস্যা সাপেক্ষে নয় এমন যথেষ্ট সহজ বিন্যাস রয়েছে।

দ্রুত সংযোগ স্থাপন. এর অর্থ হল পুনঃসংযোগের পরে শূন্য RTT (যখন কীটি ইতিমধ্যেই একবার তৈরি করা হয়েছে) - প্রথম MTProto বার্তা থেকে প্রযোজ্য, কিন্তু কিছু সংরক্ষণের সাথে - একই লবণে আঘাত করুন, সেশনটি পচা হয় না ইত্যাদি। TLS এর পরিবর্তে আমাদের কী অফার করে? বিষয়ে উদ্ধৃতি:

TLS-এ PFS ব্যবহার করার সময়, TLS সেশনের টিকিট (RFC 5077) কী পুনরায় আলোচনা না করে এবং সার্ভারে মূল তথ্য সংরক্ষণ না করে একটি এনক্রিপ্ট করা সেশন পুনরায় শুরু করতে। প্রথম সংযোগ খোলার এবং কী তৈরি করার সময়, সার্ভার সংযোগের অবস্থা এনক্রিপ্ট করে এবং এটি ক্লায়েন্টের কাছে প্রেরণ করে (একটি সেশন টিকিটের আকারে)। তদনুসারে, সংযোগ পুনরায় চালু হলে, ক্লায়েন্ট একটি সেশন টিকিট পাঠায়, সেশন কী সহ, সার্ভারে ফেরত পাঠায়। টিকিট নিজেই একটি অস্থায়ী কী (সেশন টিকিট কী) দিয়ে এনক্রিপ্ট করা হয়, যা সার্ভারে সংরক্ষিত থাকে এবং গুচ্ছ সমাধানে SSL প্রক্রিয়াকরণকারী সমস্ত ফ্রন্টএন্ড সার্ভারের মধ্যে বিতরণ করা আবশ্যক।[10]। এইভাবে, একটি সেশন টিকিটের প্রবর্তন PFS লঙ্ঘন করতে পারে যদি অস্থায়ী সার্ভার কীগুলি আপোস করা হয়, উদাহরণস্বরূপ, যখন সেগুলি দীর্ঘ সময়ের জন্য সংরক্ষণ করা হয় (OpenSSL, nginx, Apache এগুলি প্রোগ্রামের পুরো সময়কালের জন্য ডিফল্টরূপে সংরক্ষণ করে; জনপ্রিয় সাইটগুলি ব্যবহার করে কয়েক ঘন্টার জন্য চাবি, দিন পর্যন্ত)।

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

অন্য কিছু ভুলে গেছেন? কমেন্টে লিখুন।

চলবে!

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

তৃতীয় অংশ প্রযুক্তিগত উপাদান / উন্নয়ন অভিজ্ঞতা বিশ্লেষণ চালিয়ে যাবে. আপনি শিখবেন, বিশেষ করে:

• বিভিন্ন ধরণের TL সহ মহামারীর ধারাবাহিকতা
• চ্যানেল এবং সুপারগ্রুপ সম্পর্কে অজানা জিনিস
• কেন ডায়ালগ রোস্টারের চেয়ে খারাপ
• পরম বনাম আপেক্ষিক বার্তা ঠিকানা সম্পর্কে
• ছবি এবং ছবির মধ্যে পার্থক্য কি?
• ইমোজি কীভাবে ইটালিক টেক্সটে হস্তক্ষেপ করে

এবং অন্যান্য ক্রাচ! সাথে থাকুন!

উত্স: www.habr.com