เซิร์ฟเวอร์ซ็อกเก็ตและเซิร์ฟเวอร์เกมควรแยกกระบวนการหรือไม่

สมมติว่าเกมไคลเอนต์ / เซิร์ฟเวอร์มาตรฐานที่เรียบง่าย สำหรับเซิร์ฟเวอร์มันคุ้มค่าหรือไม่ที่จะมีกระบวนการแยกต่างหากที่รับฟังการเชื่อมต่อและข้อความจากไคลเอนต์และส่งข้อมูลผ่านซ็อกเก็ตท้องถิ่นหรือ stdin ไปยังกระบวนการอื่นที่รันเซิร์ฟเวอร์เกมจริง

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

ฉันสงสัยว่าทรัพยากรพิเศษที่จะแยก "กิจกรรม" สองรายการนั้นคุ้มค่าหรือไม่ ฉันควรตัดสินใจอย่างไร ฉันต้องการได้ยินข้อดี / ข้อเสียใด ๆ

จากมุมมองการออกแบบ API เมื่อตัดสินใจว่าจะสร้างโปรแกรมการสื่อสารแยกกันหลายรายการหรือเพียงรายการเดียวคำถามคือ: แต่ละโปรแกรมสามารถทำงานอย่างมีความหมายได้หรือไม่ คำตอบจะแตกต่างกันไปตามโครงการและการตั้งค่าของคุณ

หากพวกเขาทำไม่ได้มันก็ไม่คุ้มค่าที่จะคิด เห็นได้ชัดว่ามันเชื่อมโยงกันอย่างหนักจนไม่ได้แยกกระบวนการจริงๆ

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

มันจะช่วยได้มากน้อยแค่ไหนขึ้นอยู่กับเทคโนโลยีที่เหลืออยู่ของคุณ ตัวอย่างเช่นErlangภายในจำลองสิ่งต่าง ๆ เป็นกระบวนการอยู่แล้วดังนั้นคุณจะไม่ได้รับประโยชน์ทางแนวคิดมากนักจากการแยกมันออกเป็นกระบวนการของระบบปฏิบัติการ ถ้าคุณไม่คิดว่าจะเขียนส่วนเหล่านั้นของเซิร์ฟเวอร์ในภาษาอื่น ส่วนประกอบภายในของโปรแกรม C ++ มักจะมีความแน่นมากขึ้นและยากที่จะสลับออกไปดังนั้นการแยกพวกมันออกเป็นกระบวนการต่าง ๆ ของระบบปฏิบัติการจะช่วยให้คุณประหยัดในภายหลังถ้าคุณสามารถคาดการณ์การจัดเรียงใหม่ได้

มันคุ้มค่าหรือไม่ที่จะมีกระบวนการแยกต่างหากที่คอยรับฟังการเชื่อมต่อและข้อความจากไคลเอนต์และส่งข้อมูลผ่านซ็อกเก็ตท้องถิ่นหรือ stdin ไปยังกระบวนการอื่นที่รันเซิร์ฟเวอร์เกมจริง

ในการตอบว่าคุ้มค่าหรือไม่คุณต้องถามตัวเองก่อนว่าอะไรคือปัญหาที่คุณพยายามแก้ไขด้วยการเพิ่มบริการจัดคิวโดยเฉพาะ ถ้ามันแก้ปัญหานั้นมันก็คุ้มค่า ถ้ามันไม่ได้แก้ปัญหาหรือถ้าคุณไม่มีปัญหาในการแก้ปัญหาที่จะเริ่มต้นด้วยมันอาจจะไม่

มาดูสาเหตุบางประการที่เซิร์ฟเวอร์บางเครื่องใช้สถาปัตยกรรมหลายระดับ:

1. โหลดบาลานซ์ - โหลดบาลานซ์ดูสมเหตุสมผลถ้าคุณต้องการกระจายเวิร์กโหลดของคุณไปยังเครื่องจักรหลายเครื่อง หากโปรแกรมของคุณมีปัญหาคอขวดที่คุณต้องการแก้ไขเพียงแค่มีกระบวนการทำงานหลายอย่างพร้อมกันบนเครื่องเดียวกันก็เป็นวิธีที่ดีที่สุดในระยะยาวในการแก้ปัญหาคอขวดจริง ๆ แต่เป็นวิธีแก้ปัญหาระยะสั้น
2. การแยกสิทธิพิเศษ - บางทีคุณอาจไม่ต้องการให้ช่องโหว่ด้านความปลอดภัยลงในเซิร์ฟเวอร์แชทของคุณเพื่อเข้าถึงเซิร์ฟเวอร์เกมของคุณโดยอัตโนมัติหรือในทางกลับกัน หากเซิร์ฟเวอร์เกมของคุณแยกจากเซิร์ฟเวอร์แชทในเกมคุณสามารถกำหนดค่าเซิร์ฟเวอร์เกมและเซิร์ฟเวอร์แชทของคุณให้อยู่ในโดเมนความปลอดภัยแยกต่างหาก (เช่นทำงานเป็นผู้ใช้อื่นด้วยสิทธิ์การเข้าถึงที่แตกต่างกันข้อ จำกัด กระบวนการที่แตกต่าง ฯลฯ )
3. การอัพเกรด Zero downtime - หากคุณต้องการให้การอัพเกรด downtime เป็นศูนย์คุณต้องมีหลายเทียร์และกำหนดค่าระบบเช่นเมื่อคุณลงเซิร์ฟเวอร์เพื่อให้บริการคำขอของมันจะถูกเปลี่ยนเส้นทางไปยังเซิร์ฟเวอร์อื่นในระดับเดียวกันเพื่อให้แน่ใจว่าต่อเนื่อง บริการ.
4. ข้อ จำกัด การทำลาย - หากคุณมีข้อ จำกัด ถึงซ็อกเก็ตขีด จำกัด ตัวอธิบายไฟล์การล็อคล่ามทั่วโลก ฯลฯ คุณอาจสามารถหลีกเลี่ยงข้อ จำกัด นั้นได้ด้วยการรันหลายกระบวนการ อีกวิธีหนึ่งในการแก้ไขปัญหานี้คือเปลี่ยนขีด จำกัด แต่นั่นอาจไม่ใช่เรื่องง่ายเสมอไปเนื่องจากคุณอาจต้องคอมไพล์เคอร์เนลใหม่หรืออาจมีความปลอดภัยหรือประสิทธิภาพที่เกี่ยวข้อง
5. การ จำกัด การรั่วไหลของทรัพยากร - คุณต้องการเขียนซอฟต์แวร์ที่ไม่รั่วไหลของทรัพยากร แต่แม้ในภาษาที่ได้รับการจัดการอย่างเต็มรูปแบบนี่เป็นเรื่องยากมากในกระบวนการที่มีอายุการใช้งานยาวนานและที่แย่กว่านั้นคือการทำซ้ำในสภาพแวดล้อม สถาปัตยกรรมแบบหลายเทียร์ทำให้คุณสามารถฆ่าและตอบสนองต่อเซิร์ฟเวอร์เกมหลังจากระยะเวลาหรือจำนวนครั้งที่ร้องขอเพื่อจำกัดความเสียหายจากการรั่วไหลของทรัพยากรโดยไม่รบกวนบริการ

ฉันเห็นด้วยกับวงล้อประหลาด ตราบใดที่คุณมีเซิร์ฟเวอร์เกมเดียวก็ไม่คุ้มกับปัญหา

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

แต่เมื่อคุณไม่แน่ใจว่าคุณจะต้องการสิ่งนี้มาก่อนมีความเป็นไปได้สูงที่จะพัฒนาแอพพลิเคชั่นเซิร์ฟเวอร์แยกกันสองจุดในตอนนี้

อาจไม่เป็นเช่นนั้นภาษาส่วนใหญ่มีซ็อกเก็ตแบบอะซิงโครนัสที่ช่วยให้คุณใช้การเชื่อมต่อหลายครั้งพร้อมกันโดยไม่ปิดกั้นขณะที่กำลังรอข้อมูล สิ่งนี้จะเลื่อนส่วน "ซ็อกเก็ตเซิร์ฟเวอร์" ไปเป็น OS / เคอร์เนล

ด้วยซ็อกเก็ตเซิร์ฟเวอร์ที่ชัดเจนคุณจะต้องเสียค่าใช้จ่ายเพิ่มเติมอีกสองสามสำเนาเมื่อคุณส่งข้อมูลผ่านซ็อกเก็ตท้องถิ่น สิ่งหนึ่งที่จะฆ่า scalability คือสำเนาพิเศษที่คุณไม่ต้องการ