Suponha um jogo simples de cliente / servidor padrão. Para o servidor, vale a pena ter um processo separado que escute conexões e mensagens de clientes e envie os dados por soquetes locais ou stdin para outro processo que execute o servidor de jogo real?
A outra opção seria fazer as duas coisas em um único processo. Enfileirar mensagens recebidas e executá-las na ordem correta, não deve haver um problema de interrupção.
Gostaria de saber se os recursos extras para separar as duas "atividades" realmente valem a pena. Como devo decidir? Eu gostaria de ouvir quaisquer prós / contras.
architecture
server
design-patterns
client-server
luleksde
fonte
fonte
Respostas:
Do ponto de vista do design da API, ao decidir fazer vários programas de comunicação separados ou apenas um, a questão é: cada programa pode funcionar significativamente sem os outros? A resposta variará de acordo com o seu projeto e preferências.
Se eles não puderem , não vale a pena pensar. Claramente, eles estão tão fortemente vinculados que não são realmente processos separados.
Se eles podem , e você puder ver vários componentes para substituí-los no futuro, uma abstração de processo fornecida pelo sistema operacional pode ajudar.
O quanto isso ajuda depende do resto da sua pilha de tecnologia. Por exemplo, Erlang já modela internamente as coisas como processos, para que você não obtenha muito benefício conceitual ao dividi-la em processos de SO também. A menos que você esteja pensando em reescrever essas partes do servidor em um idioma diferente. Os componentes internos de um programa C ++ são tipicamente acoplados muito mais apertados e, portanto, são mais difíceis de trocar, portanto, dividi-los em diferentes processos do sistema operacional pode poupar o trabalho mais tarde, se você puder prever esses rearranjos.
fonte
Para responder se vale a pena, você primeiro deve se perguntar qual é o problema que está tentando resolver, adicionando um serviço de fila dedicado. Se resolver esse problema, vale a pena; se não resolver um problema ou se você não tiver um problema para resolver, provavelmente não o será.
Vamos ver algumas razões pelas quais alguns servidores usam uma arquitetura de várias camadas:
fonte
Eu concordo com a catraca. Contanto que você tenha um único servidor de jogos, não vale a pena.
No entanto, essa arquitetura pode ser útil quando você precisar ampliar horizontalmente. Quando um servidor de jogos não é mais suficiente e você precisa distribuir seu jogo em vários servidores de jogos por motivos de desempenho, a arquitetura do "servidor de soquete" pode ser facilmente adaptada para transformar o servidor de soquete em um balanceador de carga que roteia automaticamente as conexões para um dos muitos back-end servidor.
Mas quando você não tem certeza de que precisará disso, é provável que o excesso de engenharia desenvolva dois aplicativos de servidor separados neste momento.
fonte
Provavelmente não, a maioria dos idiomas possui soquetes assíncronos que permitem o uso de várias conexões por vez sem bloquear enquanto os dados estão aguardando. Isso muda a parte "socket server" para o OS / kernel.
Com um servidor de soquete explícito, você terá o custo de algumas cópias extras ao passar os dados pelo soquete local; uma coisa que matará a escalabilidade é cópias extras onde você não precisa delas.
fonte