หลังจากผมเพิ่มหัวข้องานนิพนธ์และหนังสือเก่าขึ้นมา ผมก็วุ่นวายกับการหาข้อมูลสำหรับสองหัวข้อดังกล่าวอยู่พอสมควรครับ และยังต้องพัฒนาซอฟต์แวร์ตัวใหม่เพื่อเพิ่มในห้องแล็ป เพราะเห็นว่ามีแค่ PeeTai Nominal และ PeeTai Metrology มันยังน้อยเกินไปครับ คิดว่าจะสร้างขึ้นมาเรื่อย ๆ ตามแนวคิด Software as a Service ก็เลยเพิ่งได้มีโอกาสกลับมาต่อบทความวันนี้เอง
กลับมาต่อจากหัวข้อที่แล้วดีกว่าครับ ผมคุยค้างเอาไว้เรื่องการเชื่อมโยงข้อมูลกันในระบบ Enterprise และเคยให้ดาวน์โหลด E-Book Network Programming For Microsoft Windows ไปแล้ว วันนี้ก็จะมาเล่าต่อว่า แนวคิดการเชื่อมโยงระบบซอฟต์แวร์แต่ล่ะระบบด้วย TCP/IP Socket นั้นจริง ๆ มีมานานแล้ว แต่ส่วนใหญ่จะเน้นไปทางด้านระบบเครือข่ายเป็นหลัก เน้นทางด้านการ Handshaking เพิ่งจะมาพักหลังนี่เอง ที่นักพัฒนาซอฟต์แวร์ รวมถึงนักอุตสาหกรรมคอมพิวเตอร์และนักวิทยาศาสตร์คอมพิวเตอร์ จะให้ความสำคัญกับโครงสร้างข้อมูลที่ส่งไปมาบนเครือข่าย
ดังนั้นแนวคิดเรื่อง Message Protocol ในระดับ Application Layer จึงได้เกิดขึ้นอย่างที่คราวที่แล้วเคยว่าไว้ ทีนี้คราวที่แล้วผมเคยเล่าถึง Message Protocol ระดับโลก แล้วทิ้งท้ายไว้ว่า ถ้าเราจะทำเองบ้าง เราจะทำได้มั้ย คำตอบก็คือ ทำได้อยู่แล้วครับ โดยการลอกเลียนจาก Message Protocol ระดับโลกนั่นแหล่ะ เพียงแต่ตัดบางกลไกที่ไม่จำเป็นทิ้งไป
จริง ๆ แล้วการออกแบบ Message Protocol สำหรับให้เราใช้งานกันเองเป็นเรื่องง่ายครับ เอาไว้ผมจะออกแบบให้ดูเต็ม ๆ ในภายหลัง แต่วันนี้จะขอคุยถึงแนวคิดในการออกแบบจุดต่อเชื่อมระหว่างระบบซอฟต์แวร์ก่อนดีกว่า
ผมเชื่อว่านักพัฒนาซอฟต์แวร์ส่วนใหญ่จะให้ความสำคัญกับข้อมูลนำเข้าที่ส่งผ่านมาทาง แป้นพิมพ์, เมาส์, ไฟล์ และตารางข้อมูลในฐานข้อมูลเป็นหลัก และให้ความสำคัญกับผลลัพท์ที่ส่งออกไปทางจอภาพ, เครื่องพิมพ์, ไฟล์ และตารางข้อมูลในฐานข้อมูล แต่ไม่ค่อยมีใครพัฒนาให้ระบบซอฟต์แวร์ของตนเอง มีการเปิดพอร์ต TCP/IP Socket เพื่อทำตัวเป็น Server สำหรับให้ซอฟต์แวร์อื่นมาต่อเชื่อมด้วย ใช่มั้ยล่ะ?
โดยปรกติแล้ว ถ้าซอฟต์แวร์ที่ผมต้องมอบหมายให้ผู้ร่วมงานทำเป็นซอฟต์แวร์ระบบ ที่มีแนวโน้มต้องต่อเชื่อมหรือถูกต่อเชื่อมโดยซอฟต์แวร์ตัวอื่น ผมจะต้องร่าง Functional Specification ขึ้นมาสองฉบับ โดยฉบับแรกอธิบายกลไกการทำงานของซอฟต์แวร์ตัวนั้น และฉบับที่สองอธิบายกลไกการรับการต่อเชื่อมของซอฟต์แวร์ตัวนั้น
ฉบับที่สองเนี่ยแหล่ะสำคัญ เพราะจะบอกให้โปรแกรมเมอร์ทราบว่า ซอฟต์แวร์ที่ต้องพัฒนาขึ้นถูกกำหนดให้เปิดพอร์ตหมายเลขใดบ้าง และแต่ล่ะพอร์ตสื่อสารกันด้วย Message Protocol ใดบ้าง โดยแนวคิดเรื่องการเปิดพอร์ตจะมีสองแบบครับ
- แบบแรก ออกแบบให้ซอฟต์แวร์ของเราเปิดพอร์ตแค่หมายเลขเดียวเพื่อรับการต่อเชื่อม แล้วใช้ Message Protocol ที่ส่งเข้ามา เป็นตัวบอกวัตถุประสงค์ในการสื่อสารครับ ซึ่งหมายความว่าเราเปิดพอร์ตเดียว แต่รับข้อมูลข่าวสารได้หลาย ๆ แบบ
- แบบที่สอง ออกแบบให้ซอฟต์แวร์ของเราเปิดพอร์ตให้เท่ากับความต้องการที่จะใช้ และให้แต่ล่ะพอร์ต สื่อสารกันด้วย Message Protocol แต่ล่ะแบบกัน
ทั้งสองวิธีล้วนมีข้อดีข้อเสียที่แตกต่างกันครับ โดยแบบแรกไม่เปลืองพอร์ตครับ ผมชอบ แต่ลำบากตอนโปรแกรมเมอร์เขียนโปรแกรม เพราะจะต้องฝังชุดคำสั่งจัดการ Message Protocol ทั้งหมดเอาไว้กับพอร์ตหมายเลขเดียว ส่วนแบบที่สองเปลืองพอร์ตครับ แต่น่าจะดีสำหรับการทำงานของซอฟต์แวร์ เพราะเราสามารถแยกชุดคำสั่งสำหรับจัดการ Message Protocol แต่ล่ะแบบ ไว้กับพอร์ตแต่ล่ะตัวได้
ทริกสำหรับมือใหม่นะครับ จะบอกว่า ถ้าคุณสร้างซอฟต์แวร์ที่มีกลไกการเปิดพอร์ต หรือต่อเชื่อมกับพอร์ต แล้วคุณอยากรู้ว่าโปรแกรมของคุณทำงานอย่างถูกต้องหรือเปล่า ให้พิมพ์คำสั่ง netstat -an|more ดังภาพครับ
แถมให้นิดนึง State=Listening หมายความว่าเครื่องของคุณเปิดพอร์ตหมายเลขอะไรอยู่ และ State=ESTABLISHED หมายความว่าเครื่องของคุณใช้พอร์ตหมายเลขใดต่อเชื่อมกับคนอื่นอยู่ และคนอื่นที่ว่าต่อเข้ามาหาเครื่องคุณด้วย IP ใด และพอร์ตหมายเลขใด ให้จำไว้นะครับ Local Address น่ะเครื่องคุณ ส่วน Foreign Address น่ะเครื่องของคนอื่น
แต่อาจเป็นได้นะที่ Local Address จะเป็นเบอร์เดียวกับ Foreign Address เพราะคุณอาจจะเปิดซอฟต์แวร์สองตัวในเครื่องเดียวกัน แล้วตัวนึงทำตัวเป็น Server ส่วนอีกตัวทำตัวเป็น Client แล้วต่อเข้ากับ Software ที่เป็น Server ของคุณก็ได้ 🙂
