แนวคิดการประยุกต์ใช้ TCP/IP Socket 18 September 2006 11:42 pm
บันทึกโดย Mr. PeeTai ใน : การสร้างซอฟต์แวร์ , ตรวจย้อนกลับหลังจากผมเพิ่มหัวข้องานนิพนธ์และหนังสือเก่าขึ้นมา ผมก็วุ่นวายกับการหาข้อมูลสำหรับสองหัวข้อดังกล่าวอยู่พอสมควรครับ และยังต้องพัฒนาซอฟต์แวร์ตัวใหม่เพื่อเพิ่มในห้องแล็ป เพราะเห็นว่ามีแค่ 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 ของคุณก็ได้ 
ความคิดเห็น»
ไม่มีความคิดเห็นอ่ะ - อยากเป็นคนแรกมั้ย?