Peer-to-Peer & Ubiquitous Computing

1P2P รุ่นที่ 1: Unstructured Overlay

2P2P รุ่นที่ 2: Structured Overlay และ DHT

Chord: ตัวอย่าง DHT คลาสสิก

Ring keyspace: 0 ... 2^m - 1

Node 0 ---- Node 8 ---- Node 21 ---- Node 32 ---- (วนกลับ Node 0)

key ที่ hash ได้ 25 -> เก็บที่ node 32 (node แรกที่ ID >= 25 ตามเข็มนาฬิกา)

3BitTorrent: กลยุทธ์ P2P ที่ต่างออกไป

4Mobile Computing และ Ubiquitous Computing

5ทันสมัย: จาก P2P/Ubiquitous ยุคแรกสู่ Edge, IoT และ Web3

6P2P คือบทบาท ไม่ใช่แค่รูปร่างเครือข่าย

คำว่า peer-to-peer ไม่ได้แปลว่าไม่มี server ใดเลย แต่หมายถึง node ปลายทางหลายตัวแบ่งบทบาททั้งผู้ใช้และผู้ให้ทรัพยากร ระบบจริงมักเป็น hybrid: ใช้ server ช่วย login, signaling หรือค้นหา peer แล้วให้ข้อมูลวิ่งตรงระหว่าง peer การมีส่วนกลางบางชิ้นจึงไม่ทำลายความเป็น P2P หากงานหลักยังถูกแบ่งไปที่สมาชิก

7Overlay Network: แผนที่ตรรกะซ้อนบนถนนจริง

Peer เชื่อมกันเป็น overlay ซึ่งเป็นกราฟตรรกะบนเครือข่าย IP อีกชั้น Neighbor ใน overlay อาจอยู่คนละทวีป แม้ packet จริงต้องผ่าน router หลายสิบตัว ดังนั้นจำนวน overlay hop ต่ำไม่ได้แปลว่า latency ต่ำเสมอ เรียกว่า topology mismatch

• Underlay — เครือข่ายจริง เช่น IP route, Wi-Fi, fiber และ mobile network
• Overlay — ความสัมพันธ์ที่ application สร้าง เช่น finger ใน Chord หรือ routing table ใน Kademlia
• Bootstrap — peer ใหม่ต้องรู้จักสมาชิกอย่างน้อยหนึ่งตัวก่อน จึงค่อยค้นพบเครือข่ายส่วนที่เหลือ
• Maintenance — ต้องตรวจ neighbor, ซ่อม routing table และย้ายข้อมูลเมื่อสมาชิกเปลี่ยน

ระบบ “ไร้ศูนย์กลาง” จึงมักยังมี bootstrap node, DNS seed หรือรายการ peer เริ่มต้น ไม่เช่นนั้น peer ใหม่ไม่มีทางรู้ว่าจะส่งข้อความแรกไปหาใคร

8Unstructured Search: Flooding, Random Walk และ Supernode

Flooding กระจาย query ไปเพื่อนบ้านทุกทิศเหมือนถามคนทั้งตลาดพร้อมกัน หาไฟล์หายากได้ดีในเครือข่ายเล็ก แต่จำนวนข้อความโตเร็วและข้อมูลซ้ำมาก TTL จำกัดวงการค้นหาแต่ก็ทำให้พลาดของที่อยู่ไกล

Random walk ส่ง query ไปเพียงบางเส้นทาง ลด traffic แต่หาเจอช้าลงและอาจเดินหลง Supernode ให้ peer ที่มีทรัพยากรสูงช่วยเก็บดัชนีของกลุ่ม ลดต้นทุนค้นหาแต่เพิ่มความไม่สมมาตร ระบบจึงเลือกระหว่างความกระจายศูนย์กับประสิทธิภาพ ไม่ได้มีคำตอบเดียว

9Chord แบบค่อย ๆ เดินบนวงแหวน

Chord hash ทั้ง node ID และ key ลง keyspace เดียวกัน Key เป็นของ successor ตัวแรกตามเข็มนาฬิกา ถ้ารู้เพียง successor เราเดินทีละ node ใช้ O(N) hops Finger table เพิ่มทางลัดที่ระยะ 1, 2, 4, 8... ทำให้แต่ละก้าวเข้าใกล้เป้าหมายแบบลดระยะที่เหลือคร่าว ๆ ครึ่งหนึ่ง จึงได้ O(log N)

เมื่อ node เข้าและออก

1. Node ใหม่หา successor ของ ID ตนผ่าน bootstrap peer
2. รับผิดชอบ key ในช่วงระหว่าง predecessor เดิมกับ ID ของตน
3. ย้าย key เฉพาะช่วงที่เกี่ยวข้อง ไม่ต้อง remap ทั้งระบบ
4. กระบวนการ stabilize ตรวจ successor และปรับ pointer เป็นระยะ
5. เก็บ successor list หลายตัวเพื่อทน node ข้างหน้าล่ม

นี่คือข้อดีของ consistent hashing: การเปลี่ยนสมาชิกหนึ่งตัวกระทบข้อมูลเพียงบางช่วง แต่คำว่า “consistent” ในที่นี้หมายถึงการ remap น้อย ไม่ใช่ consistency model ของการอ่านเขียนข้อมูล

10Kademlia: ระยะทางแบบ XOR

Kademlia นิยามระยะทางระหว่าง ID สองตัวด้วย XOR ค่าใกล้ศูนย์หมายถึง prefix เหมือนกันมาก Routing table แบ่ง peer เป็น k-bucket ตามช่วงระยะทาง ทำให้รู้จัก node ทั้งใกล้และไกลอย่างเป็นระบบ Lookup ถามหลาย peer แบบขนาน แล้วขยับไปหากลุ่มที่ใกล้ key มากขึ้น

Kademlia มักเก็บ node ที่เห็นมานานไว้ก่อน เพราะในเครือข่ายจริง peer ที่อยู่มานานมีแนวโน้มอยู่ต่อ ช่วยรับมือ churn ได้ดีขึ้น แนวคิดนี้พบใน BitTorrent DHT และระบบ content-addressed หลายชนิด

11Replication บน DHT และปัญหา Churn

ถ้า key เก็บเพียง node เดียว เมื่อ peer ปิดเครื่องข้อมูลหายทันที DHT จึง replicate ไป node ใกล้ key หลายตัวหรือเก็บสำเนาตาม successor list แต่สมาชิก P2P เข้าออกตลอดเวลา เรียกว่า churn ระบบต้องซ่อมสำเนาและ routing table อย่างต่อเนื่อง

• Replication factor สูงขึ้นเพิ่ม durability แต่กินพื้นที่และ traffic ซ่อมข้อมูล
• Refresh interval สั้นตอบสนองต่อ churn เร็ว แต่เปลืองแบตเตอรี่และ bandwidth
• ข้อมูลต้องมี expiration/TTL ไม่เช่นนั้นสำเนาที่ไม่มีเจ้าของอาจค้างตลอดไป
• Node identity ต้องป้องกันผู้โจมตีสร้าง ID จำนวนมากเพื่อยึดช่วง keyspace

12BitTorrent: การร่วมมือที่ออกแบบแรงจูงใจ

BitTorrent แบ่งไฟล์เป็น pieces และแต่ละ piece เป็น blocks Peer ดาวน์โหลดหลายชิ้นแบบขนานจากหลายคน แล้วตรวจ hash เพื่อจับข้อมูลเสีย กลยุทธ์ rarest first เลือกชิ้นที่มีสำเนาน้อยก่อน ป้องกัน swarm เหลือชิ้นหายากเพียงชิ้นเดียวจนทุกคนติดค้าง

Tit-for-tat โดยประมาณให้ upload กับ peer ที่ตอบแทนดี พร้อม optimistic unchoking เป็นครั้งคราวเพื่อค้นหาคู่ค้าที่ดีกว่าและเปิดโอกาสให้ peer ใหม่ เริ่มต้นได้ ระบบจึงไม่ได้พึ่งความใจดีล้วน ๆ แต่สร้างแรงจูงใจให้การแบ่งปันเป็นพฤติกรรมที่คุ้ม

13NAT, Firewall และการเชื่อมต่อ Peer โดยตรง

อุปกรณ์จำนวนมากอยู่หลัง NAT และไม่มี public address ที่รับ connection ได้ตรง ๆ การรู้ IP ของอีกฝ่ายจึงยังไม่พอ ต้องค้นว่า packet ภายนอกจะผ่าน mapping ใดเข้ามา

• STUN ช่วยให้ client รู้ public endpoint ที่ NAT แสดงต่อภายนอก
• Hole punching ให้ peer ทั้งสองเริ่มส่งออกเพื่อสร้าง NAT mapping แล้วพยายามคุยกันตรง
• TURN relay traffic ผ่าน server เมื่อเชื่อมตรงไม่ได้ แลก bandwidth cost กับความสำเร็จในการเชื่อมต่อ
• Signaling แลก offer, answer และ candidate ผ่านช่องทางกลางก่อน media/data path จะเป็น P2P

14Content Addressing: ชื่อที่ผูกกับเนื้อหา

ระบบทั่วไปอ้างไฟล์ด้วยตำแหน่ง เช่น URL บอก server และ path แต่ content addressing ใช้ hash ของเนื้อหาเป็นชื่อ ถ้า byte เปลี่ยน hash ก็เปลี่ยน ทำให้ตรวจ integrity และ deduplicate ได้โดยธรรมชาติ คำถามเปลี่ยนจาก “ขอไฟล์จากเครื่องนี้” เป็น “ใครมีเนื้อหาที่ hash นี้”

อย่างไรก็ตาม hash ไม่บอกว่าเนื้อหาเชื่อถือได้หรือควรตีความอย่างไร ผู้โจมตีส่งเนื้อหาอื่นที่ hash ไม่ตรงไม่ได้ง่าย แต่ยังหลอกให้เราเชื่อ hash ของข้อมูลอันตรายได้ จึงต้องมี signature, provenance และ naming layer ที่ชี้จากชื่อมนุษย์ไปยัง content ID

15Security ของ P2P: เมื่อใครก็เข้าร่วมได้

ระบบเปิดต้องคิด identity และแรงจูงใจพร้อม routing algorithm เพราะ algorithm ที่ถูกต้องภายใต้ node ซื่อสัตย์อาจถูกบิดได้เมื่อผู้เข้าร่วมเลือก ID หรือส่งข้อมูลเท็จอย่างจงใจ

16Mobile Computing: การเคลื่อนที่เปลี่ยนสมมติฐาน

อุปกรณ์เคลื่อนที่ไม่ได้เป็น server ขนาดเล็ก มันเปลี่ยนเครือข่าย สลับ Wi-Fi กับ cellular เข้าสู่ sleep mode และมีพลังงานจำกัด Connection ที่ผูกกับ IP/port จึงขาดได้แม้ผู้ใช้ยังอยู่ใน session เดิม ระบบควรแยก identity ของงานออกจาก connection ชั่วคราวและรองรับ resume

• Intermittent connectivity — ต้อง queue งานในเครื่องและ sync ภายหลัง
• Variable bandwidth — ปรับคุณภาพ media, batch งาน และใช้ delta sync
• Energy awareness — ลด wake-up, polling และการเปิดวิทยุถี่เกินไป
• Location change — endpoint และ latency เปลี่ยนระหว่าง session
• Small trust boundary — อุปกรณ์สูญหายได้ ต้องเข้ารหัสและ revoke credential

17Offline-First และการประสานข้อมูลภายหลัง

Offline-first ไม่ใช่เพียงเปิด cache ให้หน้าเก่ายังอ่านได้ แต่ให้ผู้ใช้สร้างการเปลี่ยนแปลงระหว่างออฟไลน์แล้วนำไป reconcile เมื่อกลับมาออนไลน์ จึงต้องเก็บ operation log, stable local ID และสถานะ sync ที่ผู้ใช้เข้าใจได้

18Ubiquitous Computing และ Context Awareness

Ubiquitous computing ตั้งเป้าให้การประมวลผลกลมกลืนกับกิจกรรม ผู้ใช้ไม่ได้เปิด “โปรแกรมห้องประชุม” แต่ไฟ อุณหภูมิ และจอปรับตามสถานการณ์ ปัญหาคือ context ไม่ใช่ความจริงที่สมบูรณ์ Sensor มี noise, ตำแหน่งคลาดเคลื่อน และกิจกรรมมนุษย์ตีความได้หลายแบบ

1. Sensing รับสัญญาณจาก sensor หลายชนิด
2. Inference รวมข้อมูลเพื่อคาดบริบท เช่น มีคนอยู่ในห้อง
3. Policy ตัดสินว่า context แบบใดอนุญาต action ใด
4. Actuation สั่งอุปกรณ์และเฝ้าดูผลย้อนกลับ

ระบบต้องสื่อสารความไม่แน่นอน เช่น confidence score และควรมีทางให้มนุษย์ override เพราะ automation ที่แน่ใจผิดอาจน่ารำคาญหรืออันตรายกว่าระบบที่ไม่ทำอะไรเลย

19Privacy: Context ที่สะดวกก็คือข้อมูลเฝ้าติดตาม

ตำแหน่ง รูปแบบการเดิน อัตราการเต้นหัวใจ และอุปกรณ์ใกล้เคียงช่วยให้ระบบฉลาดขึ้น แต่เมื่อนำมารวมกันสามารถอนุมานชีวิตส่วนตัวได้มากกว่าที่ผู้ใช้ตั้งใจให้ข้อมูล การขอ consent หนึ่งครั้งตอนติดตั้งจึงไม่พอ

• เก็บข้อมูลเท่าที่จำเป็นและประมวลผลบนอุปกรณ์เมื่อทำได้
• แยก identity ออกจาก telemetry และกำหนด retention ที่สั้น
• บอกผู้ใช้ว่า sensor ใดกำลังทำงานและ action ใดเกิดจากข้อมูลใด
• ให้สิทธิ์หยุด ลบ ส่งออก และแก้ inference ที่ผิด
• ออกแบบ fallback เมื่อ cloud หรือ account ใช้ไม่ได้ เพื่อไม่ให้อุปกรณ์พื้นฐานกลายเป็นของใช้ไม่ได้

20Edge Computing: ใกล้ขึ้นไม่ได้แปลว่าง่ายขึ้น

Edge ย้าย compute ใกล้แหล่งข้อมูลเพื่อลด latency ลด bandwidth ขึ้น cloud และทำงานต่อเมื่อ uplink ขาด แต่ edge node มีจำนวนมาก กระจายตามพื้นที่ และดูแลยากกว่า data center การ deploy, observability, security patch และ data governance จึงซับซ้อนขึ้น

สถาปัตยกรรมที่ดีมักเป็น continuum ไม่ใช่เลือก edge หรือ cloud ข้างเดียว งานเร่งด่วนอยู่ใกล้ sensor ส่วนงานรวมภาพใหญ่และจัดการระยะยาวอยู่ส่วนกลาง

21IoT Messaging และ Digital Twin

อุปกรณ์ IoT มักส่ง telemetry ผ่าน broker เพื่อแยกผู้ส่งจากผู้รับ QoS ของ messaging ไม่ได้ทำให้ business action exactly-once โดยอัตโนมัติ เพราะ device อาจ retry และ consumer อาจประมวลผลก่อน crash จึงต้องมี sequence number, deduplication และ device identity

Digital twin คือแบบจำลองสถานะของสิ่งจริงในระบบดิจิทัล แต่ค่าบนหน้าจอเป็นเพียงสิ่งที่ระบบ “เชื่อ” จาก message ล่าสุด ไม่ใช่สิ่งจริงเสมอ ต้องแสดง timestamp, freshness และสถานะ connection มิฉะนั้น operator อาจตัดสินใจจาก sensor ที่หยุดส่งมาหลายชั่วโมง

22กรณีศึกษา: แอปภาคสนามที่ออฟไลน์ได้

1. เจ้าหน้าที่สร้างแบบสำรวจพร้อม local UUID โดยไม่รอ server
2. รูปและข้อมูลเก็บเข้ารหัสในเครื่อง พร้อม operation log
3. เมื่อมีเครือข่าย client ส่งแบบ resumable และใช้ idempotency key
4. Server ตอบ version ใหม่ Client จึงทำเครื่องหมายว่า synced
5. ถ้ามีการแก้รายการเดียวกันสองที่ ระบบ merge ช่องที่อิสระและให้คนเลือกเฉพาะ conflict ที่ตัดสินอัตโนมัติไม่ได้
6. UI แสดง pending, synced, conflict และ failed แยกกัน ไม่ใช้คำว่า “บันทึกแล้ว” แบบกำกวม

23แล็บและแบบฝึกที่แนะนำ

• จำลอง Chord 32 ตำแหน่ง เพิ่ม/ลบ node แล้วนับจำนวน key ที่ย้ายและจำนวน hop ก่อน–หลังมี finger table
• สร้าง mini DHT ที่มี PUT/GET, replication factor 3 และทดลอง kill node ระหว่าง lookup
• จับ WebRTC candidate เพื่อแยก host, server-reflexive และ relay candidate แล้วสังเกตว่าเมื่อใดต้องใช้ TURN
• ทำ offline note app ที่มี operation queue จากนั้นแก้เอกสารเดียวกันสองเครื่องแล้วออกแบบ merge rule
• จำลอง sensor ขาดช่วงและบังคับ dashboard แสดง freshness แทนการค้างค่าล่าสุดเหมือนยังเป็นปัจจุบัน

24คำถามตรวจงานออกแบบ

• ระบบกระจายศูนย์ส่วนใด และยังพึ่งศูนย์กลางเรื่อง bootstrap, identity หรือ policy ตรงไหน
• Peer เข้าออกเร็วเพียงใด Routing table และ replica ซ่อมทันหรือไม่
• อยู่หลัง NAT แบบใด เชื่อมตรงไม่ได้แล้วมี relay และงบ bandwidth หรือยัง
• ข้อมูลออฟไลน์ merge อย่างไร ผู้ใช้เห็น conflict และสถานะ pending หรือไม่
• ถ้า sensor เงียบ ระบบแยก “ค่าเดิม” จาก “ค่าปัจจุบัน” ได้หรือไม่
• ผู้โจมตีสร้าง identity จำนวนมากหรือเลือก ID ใกล้ key เป้าหมายได้หรือไม่

25จากวิชาสู่ระบบจริง

เมื่อนำ P2P, edge หรือ offline-first ไปใช้จริง ควรเริ่มจาก failure diary: จดว่า node เข้าออกเมื่อใด ข้อมูลรุ่นใดอยู่ที่ใคร และผู้ใช้เห็นสถานะอะไรในแต่ละช่วง แล้วค่อยพิจารณา algorithm เพราะประโยคว่า “ระบบ sync เอง” มักซ่อนคำถามสำคัญที่สุดไว้ทั้งหมด ทั้งเวลาในการลู่เข้า conflict ที่แก้ไม่ได้ ค่า relay และข้อมูลส่วนตัวที่ถูกเก็บระหว่างทาง

26สรุปและขั้นตอนถัดไป

P2P กระจายทั้งทรัพยากรและความรับผิดชอบออกจากศูนย์กลาง แต่ต้องแลกกับ membership ที่ไม่นิ่ง การค้นหา การซ่อมสำเนา NAT และผู้เข้าร่วมที่อาจไม่ร่วมมือ ส่วน mobile และ ubiquitous computing ทำให้ความไม่แน่นอนเข้ามาใกล้ผู้ใช้มากขึ้น ทั้งเครือข่ายขาด แบตเตอรี่จำกัด sensor คลาดเคลื่อน และ privacy

บทนี้เป็นปลายทางของรายวิชา แต่ไม่ใช่ปลายทางของเนื้อหา ขั้นตอนถัดไปที่เหมาะคือทดลองสร้างระบบขนาดเล็กแล้วฉีด failure จริง จากนั้นนำกรอบจาก DS 1–11 กลับมาถามว่า สมมติฐานใดพัง ระบบรักษาสัญญาอะไรไว้ได้ และ trade-off ที่เราเลือกยังสมเหตุสมผลหรือไม่ครับ