Một máy chủ ổ cắm và máy chủ trò chơi nên được xử lý riêng biệt?

Giả sử một trò chơi máy khách / máy chủ tiêu chuẩn đơn giản. Đối với máy chủ, có đáng để có một quy trình riêng biệt lắng nghe các kết nối và tin nhắn từ khách hàng và gửi dữ liệu qua ổ cắm cục bộ hoặc stdin đến một quy trình khác chạy máy chủ trò chơi thực tế không?

Tùy chọn khác là có cả hai việc được thực hiện trong một quy trình duy nhất. Xếp hàng các tin nhắn đến và thực hiện chúng theo đúng thứ tự sẽ không có vấn đề tạm dừng.

Tôi tự hỏi nếu các nguồn lực bổ sung để tách hai "hoạt động" có thực sự xứng đáng hay không. Tôi nên quyết định như thế nào? Tôi muốn nghe bất kỳ ưu / nhược điểm.

Từ góc độ thiết kế API, khi quyết định thực hiện nhiều chương trình giao tiếp riêng biệt hay chỉ một chương trình, câu hỏi đặt ra là: mỗi chương trình có thể hoạt động một cách có ý nghĩa mà không cần các chương trình khác không? Câu trả lời sẽ thay đổi dựa trên dự án và sở thích của bạn.

Nếu họ không thể , nó không đáng suy nghĩ. Rõ ràng là chúng được liên kết rất nhiều đến nỗi chúng không thực sự là các quá trình riêng biệt.

Nếu họ có thể , và bạn có thể thấy mình muốn thả các thành phần khác nhau để thay thế chúng trong tương lai, thì một sự trừu tượng hóa quy trình do hệ điều hành cung cấp có thể giúp ích.

Nó giúp được bao nhiêu tùy thuộc vào phần còn lại của ngăn xếp công nghệ của bạn. Ví dụ, Erlang nội bộ mô hình hóa mọi thứ như các quy trình, vì vậy bạn sẽ không nhận được nhiều lợi ích về mặt khái niệm từ việc chia nó thành các quy trình HĐH. Trừ khi bạn nghĩ đến việc có thể viết lại những phần đó của máy chủ bằng một ngôn ngữ khác. Các thành phần bên trong của chương trình C ++ thường được ghép nối chặt chẽ hơn nhiều và do đó khó trao đổi hơn, do đó việc chia chúng thành các quy trình HĐH khác nhau có thể giúp bạn tiết kiệm công việc sau này nếu bạn có thể thấy trước các sắp xếp lại như vậy.

Có đáng để có một quy trình riêng biệt lắng nghe các kết nối và tin nhắn từ khách hàng và gửi dữ liệu qua ổ cắm cục bộ hoặc stdin đến một quy trình khác chạy máy chủ trò chơi thực tế không?

Để trả lời liệu nó có đáng hay không, trước tiên bạn phải tự hỏi, vấn đề bạn đang cố gắng giải quyết là gì bằng cách thêm một dịch vụ xếp hàng chuyên dụng. Nếu nó giải quyết được vấn đề đó, thì nó đáng giá; nếu nó không giải quyết được vấn đề hoặc nếu bạn không có vấn đề gì cần giải quyết thì có lẽ không phải vậy.

Chúng ta hãy xem một số lý do tại sao một số máy chủ sử dụng kiến ​​trúc nhiều tầng:

1. Cân bằng tải - cân bằng tải có ý nghĩa nếu bạn muốn phân bổ khối lượng công việc của mình cho nhiều máy công nhân. Nếu chương trình của bạn có các tắc nghẽn mà bạn muốn giải quyết đơn giản bằng cách có nhiều quy trình nhân viên đồng thời trên cùng một máy, thì tốt nhất về lâu dài để thực sự giải quyết tắc nghẽn, nhưng như một cách giải quyết ngắn hạn, các quy trình nhân viên sinh sản có thể là thực tế.
2. Phân tách đặc quyền - Có thể bạn không muốn vi phạm bảo mật vào máy chủ trò chuyện của mình để tự động truy cập máy chủ trò chơi của bạn hoặc ngược lại. Nếu máy chủ trò chơi của bạn tách biệt với máy chủ trò chuyện trong trò chơi, bạn có thể định cấu hình máy chủ trò chơi và máy chủ trò chuyện của mình để sống trong miền bảo mật riêng biệt (ví dụ: chạy với tư cách người dùng khác nhau, với các đặc quyền truy cập khác nhau, giới hạn quy trình khác nhau, v.v.).
3. Nâng cấp thời gian chết bằng không - nếu bạn muốn đạt được nâng cấp thời gian chết bằng không, bạn cần có nhiều tầng và cấu hình hệ thống sao cho khi bạn gỡ xuống một máy chủ để phục vụ, các yêu cầu của nó sẽ được chuyển hướng đến các máy chủ khác trong cùng tầng để đảm bảo liên tục dịch vụ.
4. Phá vỡ giới hạn - nếu bạn đạt đến giới hạn ổ cắm, giới hạn mô tả tệp, khóa trình thông dịch toàn cầu, v.v., bạn có thể làm việc xung quanh giới hạn đó bằng cách chạy nhiều quy trình. Một cách khác để giải quyết vấn đề này là thay đổi giới hạn, nhưng điều đó không phải lúc nào cũng dễ dàng vì bạn có thể phải biên dịch lại kernel, hoặc có thể có những tác động về bảo mật hoặc hiệu năng.
5. Hạn chế rò rỉ tài nguyên - bạn muốn viết phần mềm không rò rỉ tài nguyên, nhưng ngay cả trong các ngôn ngữ được quản lý rác hoàn toàn, điều này cực kỳ khó khăn trong một quy trình tồn tại lâu và tệ hơn là điều này khó có thể sao chép trong môi trường phát triển. Một kiến ​​trúc đa nhiệm cho phép bạn tiêu diệt và hồi sinh các máy chủ trò chơi sau một số thời gian hoặc số lượng yêu cầu nhất định để hạn chế thiệt hại từ rò rỉ tài nguyên, mà không làm gián đoạn dịch vụ.

Tôi đồng ý với quái vật ratchet. Miễn là bạn có một máy chủ trò chơi duy nhất, nó không đáng để gặp rắc rối.

Tuy nhiên, kiến ​​trúc này có thể hữu ích khi bạn cần mở rộng theo chiều ngang. Khi một máy chủ trò chơi không còn đủ nữa và bạn cần phân phối trò chơi của mình trên nhiều máy chơi trò chơi vì lý do hiệu suất, kiến ​​trúc "máy chủ ổ cắm" có thể dễ dàng được điều chỉnh để biến máy chủ ổ cắm thành bộ cân bằng tải tự động định tuyến các kết nối đến một trong nhiều phụ trợ người phục vụ.

Nhưng khi bạn không chắc chắn mình sẽ cần điều này, có khả năng sẽ phát triển quá mức để phát triển hai ứng dụng máy chủ riêng biệt vào thời điểm này.

Có lẽ không, hầu hết các ngôn ngữ đều có ổ cắm không đồng bộ cho phép bạn sử dụng nhiều kết nối cùng một lúc mà không bị chặn trong khi dữ liệu đang chờ. Thao tác này sẽ chuyển phần "máy chủ ổ cắm" sang HĐH / kernel.

Với một máy chủ ổ cắm rõ ràng, bạn sẽ phải chịu chi phí của một vài bản sao bổ sung khi bạn truyền dữ liệu qua ổ cắm cục bộ; một thứ sẽ giết chết khả năng mở rộng là các bản sao bổ sung mà bạn không cần chúng.