ข้อจำกัดของ Client / Server Online Meeting ตอนที่ 1

ระหว่างวันหยุดเทศกาลปีใหม่ 2553-2554 ผมมาพักผ่อนที่จังหวัดสุโขทัย ที่พักอยู่ห่างจากตัวจังหวัดไปไกลพอสมควร อากาศเย็นสบายดีมาก สงบ มีนักท่องเที่ยวต่างชาติมากกว่าคนไทย บังเอิญไปเห็นคนไทยกลุ่มหนึ่ง 2-3 คน นั่งทำงานกับเอกสารกองโต และีคอมพิวเตอร์โน๊ตบุคอยู่บนโต๊ะ ก็เลยสอบถามเจ้าหน้าที่ดูว่ามีบริการเชื่อมต่ออินเตอร์เน็ตด้วยหรือ ปรากฎว่ามี High speed Internet อย่างดีไว้บริการฟรีด้วย ก็เลยเอาคอมพิวเตอร์มาเขียนบทความเลยเพราะกำลังได้บรรยากาศดีมาก มองเห็นทุ่งนา ลมพัดเย็น ๆ เขียนไปได้สักพักก็เริ่มคิดได้ว่าอยากลองทำ conference ดู ก็ปรากฎใช้ได้ไม่มีปัญหา อะไรจะดีขนาดนี้ ชีวิตเราอาจไม่ต้องผูกติดอยู่กับจังหวัดใหญ่หรือในกรุงเทพ ฯ อีกต่อไปก็ได้นี่ ผมอยู่ริมทุ่งนา แต่ก็สามารถทำงานได้เหมือนกับอยู่กรุงเทพ ฯ ด้วยระบบสือสารผ่านอินเตอร์เน็ต (อินเตอร์เน็ตต่างจังหวัดหลุดน้อยกว่าในกรุงเทพ ฯ แถวบ้านผมอีก)

นี่อาจเป็นสิ่งที่แสดงแนวโน้มของการใช้ชิวิตร่วมกับการทำงานที่ผสมปนเปกันจนแยกไม่ออกว่าเวลาไหนเป็นเวลาไหนนั้นเป็นจริงได้แน่ด้วยอุปกรณ์การสื่อสารและระบบสื่อสารที่นับวันก็จะสะดวกมากขึ้นมีประสิทธิภาพมากขึ้น online meeting หรือ web conferencing ก็น่าจะมีบทบาทแทรกเข้าไปในชีวิตประจำวันของสังคมยุคใหม่ได้มากขึ้นตามไปด้วย

ถ้าทุกอย่างดูดีอย่างนี้แล้วอะไรที่เป็นตัวขวางทางปรากฎการณ์นี้อยู่ หลายคนอาจจะบอกว่า ราคา ซึ่งผมก็เห็นด้วย (เราถึงได้พยายามทำ low cost web conference ขึ้นมาไง) ประเด็นสำคัญอีกประเด็นหนึ่งที่ผมเคยเขียนเอาไว้เมื่อสองปีมาแล้วก็คือตัวสถาปัตยกรรมของ Web Conference เอง ซึ่งก็คือสถาปัตยกรรมแบบ Client/Server ที่อาศัย TCP package (ในตลาดมีระบบที่ไม่ใช้ TCP package เช่น SIP ให้บริการอยู่แล้ว)

ในสถาปัตยกรรมแบบ Client / Server จะอาศัยความสามารถในการประมวลของ Server ค่อนข้างมาก ข้อมูลภาพและเสียงจะถูกส่งจาก client ไปยัง Server เพื่อส่งต่อไปยัง client ตัวอื่น ๆ บทบาทของ Server จึงเปรียบเหมือนกับ Mixer ที่รวบเอาภาพและเสียงมาสร้างเป็น video แล้วส่งออกไป ถ้าหากมี client จำนวนมากขึ้น Server ก็ต้องทำการสร้าง video มากขึ้นตามไปด้วย จากรูปข้างล่างแสดงให้เห็นระบบที่มี client หรือผู้เข้าประชุม 3 ตำแหน่ง เส้นสีเขียวแทนข้อมูลจาก client ส่งไปยัง server เส้นสีน้ำเงินแทนข้อมูล video ส่งจาก server ไปยัง client เส้นสีน้ำเงินจะมากกว่าเพราะ server ต้องทำการสำเนาวิดีโอจาก client หนึ่งไปยังอีก 2 client ที่เหลือเสมอ

 

จำนวนวิดีโอที่ server ต้องทำสำเนาเป็น N x (N-1) เมื่อ N คือจำนวนผู้เข้าประชุม ในตัวอย่างนี้จะมีสำเนาวิดีโอในระบบทั้งหมด 6 สำเนาด้วยกัน (3 x [3 – 1] = 6) ทีนี้ลองนึกถึงระบบที่มีผู้เข้าร่วมประชุมจำนวนมากกว่านี้ซิครับจะเห็น work load ของ server อันมหาศาสทีเดียว ที่นี้เราก็จะเห็นได้ว่าประสิทธิภาพของวิดีโอที่ได้จะขึ่นกับการประมวลผลของ Server อย่างมาก (นอกเหนือจากระบบการ encode วิดีโอ) หากมีอะไรเกิดขึ้นกับ server หรือ server ไม่เก่งพอที่รับมือกับงานหนักได้ก็จะส่งผลต่อการประชุมแน่นอน

ที่กล่าวไปแล้วเป็นประเด็นเรื่องการประมวลผล ประเด็นต่อไปคือการสือสารข้อมูลด้วย TCP package ซึ่งถ้ากล่าวตามตำราเรื่อง Data Communication แล้วนับว่าเป็นเรื่องที่ดีเพราะการสื่อสารด้วย TCP package จะมีการรับประกันประสิทธิภาพการสื่อสาร หากการสื่อสารไม่สมบูรณ์ก็จะมีกระบวนการ re-transmit หรือ การส่งข้อมูลมาใหม่จนกว่าข้อมูลจะสมบูรณ์ กระบวนการนี้แม้จะดีแต่ก็เหมาะกับการสื่อสารแบบอื่นไม่ใช่แบบ real time เช่น การรับ-ส่ง ข้อมูลวิดีโอ เพราะว่าหากมีข้อมูลจำนวนมากขึ้น โอกาสที่จะมีข้อมูลเสียหายก็มากขึ้น และสิ่งที่ตามมาก็คือการ re-transmit ก็จะตามไปด้วย ผลสุดท้ายก็มาลงที่การหน่วงเวลา ซึ่งเราจะเห็นได้จากการกระตุกของภาพ การ delay ของภาพหรือเสียง การ freeze ของภาพ การไม่สมดุลระหว่างภาพและเสียง เป็นต้น ทางออกที่เหมาะสมก็คือการเปลี่ยนจากการใช้ TCP package ไปเป็น UDP package เพราะการใช้ UDP package หมายถึงการมองข้ามการ re-transmit ไปซึ่งก็หมายถึงการลดการหน่วงเวลาไปด้วยเช่นกัน แต่ว่าการใช้ UDP package ก็นำมาซึ่งปัญหาใหม่เช่นกัน (จะกล่าวต่อไป) ท่านที่ต้องการมีระบบ meeting online ก็ต้องศึกษาและชั่งนำหนักกันให้ดีต่อไป