Serialization ও Binary Format — In-memory থেকে Byte পর্যন্ত

একটা single node সরাসরি পাঠানো নিরর্থক, আর পুরো chain-ও এভাবে সম্ভব না।

next field একটা pointer — একটা virtual memory address, যেটা শুধু sender process-এর নিজের address space-এর মধ্যেই অর্থবহ। এই address raw byte হিসেবে receiver-কে পাঠালে receiver-এর কাছে সেটা একটা “সংখ্যা” মাত্র — receiver-এর নিজের address space-এ সেই address-এ হয়তো সম্পূর্ণ ভিন্ন কিছু আছে (অন্য কোনো variable, বা কিছুই না, বা invalid memory যেটাতে access করলে segmentation fault)।

এমনকি একই মেশিনে, প্রোগ্রামটা দ্বিতীয়বার চালালেও একই address কাজ করবে না — ASLR (Address Space Layout Randomization) প্রতিবার প্রোগ্রামের memory layout randomize করে, নিরাপত্তার জন্য (buffer overflow আক্রমণ কঠিন করতে)।

পুরো chain পাঠানোর সঠিক উপায়: pointer-ভিত্তিক structure-কে traverse করে প্রতিটা node-এর value সংগ্রহ করে একটা linear sequence বানাতে হবে — pointer বাদ দিয়ে, শুধু data:

def serialize_list(head):
    values = []
    node = head
    while node is not None:
        values.append(node.value)
        node = node.next
    # শুধু values-এর একটা list serialize করি, কোনো pointer ছাড়াই
    return serialize_int_array(values)

Receiver পাশে deserialize করার সময় নতুন করে node তৈরি করে, নিজস্ব memory address দিয়ে, আর সেই নতুন address দিয়েই নিজের next link বসায় — সংখ্যাগুলো (value) একই থাকে, কিন্তু structure পুনর্গঠিত হয় প্রতিটা প্রান্তে স্বাধীনভাবে, pointer কখনো wire-এ যায় না।

সাধারণ নীতি: serialization-এ কখনো raw pointer/memory address পাঠানো হয় না — যা পাঠানো হয় তা হলো সম্পর্ক (কোনটা কোনটার সাথে যুক্ত, index বা nesting দিয়ে প্রকাশ করা) এবং মান (আসল data), pointer নিজে না।

মূল struct-এর হিসাব:

• flag (1 byte) → address 0
• value (double, ৮-byte alignment দরকার) → পরবর্তী ৮-এর গুণিতক address 8, তাই address 1-7 (৭ byte) padding
• value শেষ হয় address 16-এ
• count (short, ২-byte alignment) → address 16 ইতিমধ্যে ২-এর গুণিতক, তাই কোনো padding লাগে না, address 16-17
• id (int, ৪-byte alignment) → পরবর্তী ৪-এর গুণিতক address 20, address 18-19 (২ byte) padding
• id শেষ হয় address 24-এ
• Struct-এর নিজস্ব alignment = সবচেয়ে বড় member-এর alignment = ৮ (double-এর জন্য) → total size ৮-এর গুণিতকে round up, 24 ইতিমধ্যে ৮-এর গুণিতক

sizeof(struct Original) = 24

মোট padding: 7 + 2 = 9 byte। দরকারি data: 1+8+2+4 = 15 byte। মোট 24-এর মধ্যে ৯ byte (৩৭.৫%) নষ্ট।

Reorder — বড় থেকে ছোট:

struct Reordered {
    double value;   // 8 byte, address 0
    int    id;      // 4 byte, address 8
    short  count;   // 2 byte, address 12
    char   flag;    // 1 byte, address 14
};

• value → address 0-7, কোনো padding লাগে না (৮-এর গুণিতক থেকেই শুরু)
• id → address 8, ইতিমধ্যে ৪-এর গুণিতক, কোনো padding নেই, শেষ 12
• count → address 12, ইতিমধ্যে ২-এর গুণিতক, কোনো padding নেই, শেষ 14
• flag → address 14, শেষ 15
• Struct alignment ৮ (এখনও double আছে) → 15-কে ৮-এর গুণিতকে round up করলে 16

sizeof(struct Reordered) = 16

24 থেকে 16 — ৩৩% সাশ্রয়, কোনো data না হারিয়ে। মূল ২৪ byte-এর মধ্যে মাত্র ১ byte trailing padding (address 15) অবশিষ্ট থাকে, যেটা এড়ানো অসম্ভব কারণ struct-এর নিজস্ব ৮-byte alignment মানতেই হবে।

Chain-টা ধাপে ধাপে:

১. একটা struct/buffer allocate করা হয় (stack-এ local variable, বা heap-এ malloc) — এই মেমরি শূন্য দিয়ে initialize হয় না by default (calloc ছাড়া) — যা আগে সেই memory address-এ ছিল (আগের কোনো function call-এর data, আগের কোনো heap allocation-এর অবশিষ্টাংশ) তাই থেকে যায়।

২. প্রোগ্রামার struct-এর কিছু field explicit ভাবে set করে (যেমন p.type = 5;), কিন্তু padding byte (compiler-এর বসানো filler, প্রোগ্রামারের কাছে অদৃশ্য) কখনো touch করে না।

৩. পুরো struct/buffer একবারে send()/fwrite()/memcpy() দিয়ে পাঠানো হয় — sizeof(struct) byte, যার মধ্যে padding byte-ও আছে।

৪. Receiver (বা network-এ বসে থাকা আক্রমণকারী, packet capture করে) সেই raw byte পায় — যার মধ্যে “legitimate” field আর “leaked padding garbage” মেশানো, কোনো marker ছাড়াই আলাদা করা যায় না বাইরে থেকে।

৫. যদি এই প্যাটার্নটা বারবার ঘটে (প্রতিটা নতুন packet-এ নতুন, ভিন্ন padding garbage — কারণ প্রতিবার memory-র ভিন্ন অংশ reuse হচ্ছে), আক্রমণকারী অনেক packet জড়ো করে ধীরে ধীরে kernel/heap memory-র বড় অংশ পুনর্গঠন করতে পারে — সেই মেমরিতে যদি sensitive তথ্য (আগের কোনো connection-এর data, key material) থেকে থাকে, সেটাও leak হয়।

কেন টেস্টিং-এ ধরা পড়ে না:

• Functional test সাধারণত শুধু যা প্রোগ্রামার ইচ্ছাকৃতভাবে set করেছে সেই field-গুলো check করে (assert p.type == 5) — padding byte-এর মান test-এর আওতার বাইরেই থাকে, কারণ কেউ padding byte নিয়ে assertion লেখে না
• Memory-তে প্রায়ই কাকতালীয়ভাবে শূন্য থাকে (fresh process, প্রথমবার allocate হওয়া page প্রায়ই OS দ্বারা আগে থেকে zero করা — নিরাপত্তার জন্যই OS এটা করে নতুন page-এর জন্য), তাই development/test পরিবেশে padding-এ প্রায়ই 0x00 দেখা যায় — কোনো visible symptom নেই
• সমস্যাটা প্রকাশ পায় শুধু নির্দিষ্ট memory reuse pattern-এ (আগের allocation-এর “নোংরা” মেমরি reuse হলে) — production-এর দীর্ঘ-চলা process-এ এটা টেস্ট পরিবেশের চেয়ে অনেক বেশি সম্ভাবনা, কারণ memory বহুবার allocate-free-reallocate হয়েছে

প্রতিকার: allocation-এর পরপরই পুরো buffer memset(&buf, 0, sizeof(buf)) দিয়ে শূন্য করা, অথবা (আরও ভালো ও নির্ভরযোগ্য) কখনো raw struct সরাসরি না পাঠিয়ে field-by-field explicit serialization ব্যবহার করা — যেখানে “padding” ধারণাটাই অস্তিত্বহীন, কারণ প্রতিটা byte সচেতনভাবে লেখা।

এটা একটা classical forward/backward compatibility সমস্যা — protobuf-এর সমাধান করা ঠিক এই সমস্যাই, কিন্তু IoT-তে bandwidth/power constraint-ও যোগ হয়।

সিদ্ধান্ত ১ — Tag-length-value (TLV) কাঠামো বেছে নিন, fixed positional layout না।

প্রতিটা field-কে [tag: 1 byte][length: 1 byte][value: length byte] হিসেবে এনকোড করুন, positional (nth byte = nth field) ধরে না নিয়ে। এভাবে —

• পুরনো firmware একটা অচেনা tag পেলে তার length পড়ে সেটা skip করতে পারে, বাকি message পার্স করা চালিয়ে যেতে পারে — সম্পূর্ণ message বাতিল করতে হয় না
• নতুন field যোগ করা মানে শুধু একটা নতুন tag ব্যবহার করা — পুরনো tag-গুলোর অবস্থান/অর্থ অপরিবর্তিত থাকে

সিদ্ধান্ত ২ — একটা version/capability byte প্রতিটা message-এর শুরুতে।

Message-এর প্রথম byte-ই ঘোষণা করুক protocol version। Receiver (device বা central hub) version দেখে জানতে পারে কী কী tag আশা করা উচিত — আর version না চিনলেও, TLV কাঠামো থাকায় অন্তত পরিচিত tag-গুলো পড়তে পারবে।

সিদ্ধান্ত ৩ — tag number কখনো reuse করবেন না, deprecated tag “reserved” রাখুন।

একটা tag একবার একটা অর্থে ব্যবহৃত হলে, সেই sensor type বাতিল হয়ে গেলেও সেই tag number ভবিষ্যতে অন্য কোনো field-এর জন্য পুনর্ব্যবহার করবেন না — পুরনো device (যদি কখনো সেই পুরনো tag পাঠায়, firmware আপডেট না হওয়ায়) নতুন hub-কে বিভ্রান্ত করতে পারে যদি hub সেই tag-কে নতুন অর্থে ধরে নেয়।

সিদ্ধান্ত ৪ — bandwidth-সচেতন হলে varint/compact encoding বিবেচনা করুন, কিন্তু simplicity-র সাথে balance করুন।

IoT device-এ CPU/power সীমিত, তাই protobuf-এর মতো জটিল varint parsing হয়তো ভারী। একটা সরল compromise: fixed-size tag/length field (যেমন tag = 1 byte, length = 1 byte, তাই field ২৫৫ byte পর্যন্ত) — parsing logic খুবই সরল (কোনো variable-length integer decode লাগে না), অথচ TLV-এর extensibility সুবিধা বজায় থাকে।

যা এড়াবেন: positional fixed-offset format (আমাদের “বিপজ্জনক উপায়”-এর মতো) — কারণ সেখানে নতুন field মানেই সব offset শিফট হয়ে যাওয়া, পুরনো firmware সম্পূর্ণ ভুল জায়গা থেকে data পড়বে, কোনো graceful degradation ছাড়াই। TLV-তে “অচেনা tag skip করো” এই একটা সাধারণ নিয়মই পুরনো device-কে আংশিকভাবে হলেও কার্যকর রাখে — এটাই মূল trade-off যেটা এই design সমাধান করছে।

আমাদের লেআউট: [4B id][8B score][4B name_len][name_len B utf8 name], তাই fixed header সবসময় 4 + 8 + 4 = 16 byte, আর তার সাথে যোগ হয় name-এর UTF-8 byte length।

"কম্পিউটার"-এর UTF-8 byte length বের করা:

Unicode/UTF-8 লেসনে আমরা শিখেছি একটা “visual অক্ষর” (grapheme) আর একটা Unicode code point এক জিনিস না — বাংলা conjunct/matra-তে একাধিক code point মিলে একটা visual glyph তৈরি হতে পারে। "কম্পিউটার" শব্দটা ভাঙলে code point-গুলো:

ক  (U+0995)
ম  (U+09AE)
্  (U+09CD  — hasant/virama)
প  (U+09AA)
ি  (U+09BF  — vowel sign I)
উ  (U+0989)
ট  (U+099F)
া  (U+09BE  — vowel sign AA)
র  (U+09B0)

৯টা code point। প্রতিটাই Bengali Unicode block-এ (U+0980–U+09FF), আর UTF-8 encoding-এর নিয়ম অনুযায়ী U+0800–U+FFFF রেঞ্জের প্রতিটা code point ৩ byte নেয় (Unicode/UTF-8 লেসনে দেখা UTF-8-এর length-prefix bit pattern অনুযায়ী)।

$9 \text{ code point} \times 3 \text{ byte/code point} = 27 \text{ byte}$

সম্পূর্ণ record-এর সাইজ:

$\underbrace{4}_{\text{id}} + \underbrace{8}_{\text{score}} + \underbrace{4}_{\text{name\_len}} + \underbrace{27}_{\text{name UTF-8}} = 43 \text{ byte}$

উত্তর: ৪৩ byte।

এই হিসাবটা এই পুরো module-এর সংশ্লেষণ — id (unsigned integer লেসন), score (IEEE 754 লেসন), byte order (endianness লেসন), আর name-এর দৈর্ঘ্য (Unicode/UTF-8 লেসন) — প্রতিটা আগের লেসনের একটা নির্দিষ্ট সিদ্ধান্ত এই একটা সংখ্যায় (৪৩) মিশে আছে। যদি নামটা ইংরেজি হতো (যেমন "Computer", ৮টা ASCII অক্ষর, প্রতিটা ১ byte), মোট size হতো 16 + 8 = 24 byte — একই “৮-৯ অক্ষরের শব্দ” হলেও script-ভেদে byte size প্রায় দ্বিগুণ পার্থক্য, যেটা UTF-8-এর variable-length প্রকৃতির একটা সরাসরি ফলাফল।