Padrões de design para servidor de mensagens multi-threaded

5

Estou projetando um servidor de mensagens instantâneas como um exercício pessoal para melhorar meu entendimento e aplicação de padrões de multi-threading e design em Java. Eu ainda estou projetando, não há código ainda.

Meu objetivo é ter um servidor que faça uso efetivo de uma caixa com várias CPUs. Eu gostaria que o servidor fosse distribuído em várias caixas, mas me pergunto se isso está funcionando antes que eu possa andar.

Meus pensamentos iniciais são:

  • ClientConnectionManager tem ServerSocket objeto que aceita constantemente o cliente Socket conexões.
  • ClientConnectionManager tem um conjunto de encadeamentos que gera um novo objeto ClientProxy quando uma conexão de soquete do cliente é aceita, entregando o objeto Socket do cliente.
  • Os objetos ClientProxy representam o aplicativo cliente e manipulam o envio / recebimento de mensagens no fluxo Socket .

É correto que apenas um ServerSocket possa ser vinculado a uma porta? Eu entendo que não há como ter um pool de objetos aceitando conexões Socket?

Eu tenho duas ideias para passar mensagens entre ClientProxy objects. Entre os objetos ClientProxy que são "amigos" ou por meio de um objeto "Exchange" central ou, melhor ainda, um conjunto de objetos.

Quais são os prós / contras das duas abordagens? O Exchange se presta melhor a um aplicativo distribuído?

Os padrões de Observador e Mediador, respectivamente, seriam apropriados?

    
por retrodev 15.09.2013 / 16:53
fonte

1 resposta

3

Is it correct that only one ServerSocket may bind to a Port? I take it there's no way to have a pool of objects accepting Socket connections?

Correto. Apenas uma coisa pode se ligar a uma porta específica em uma determinada interface de rede por vez. Sempre que uma conexão é recebida, um novo soquete é criado automaticamente para o cliente em uma porta de roteamento diferido / internamente. É assim que um único ouvinte pode gerar qualquer número de manipuladores de clientes sem esperar que o anterior seja desconectado.

I have two ideas for passing messages between ClientProxy objects. Either directly between ClientProxy objects that are "buddies" or via a central "Exchange" object, or better yet, pool of objects.

Você pode fazer com que os clientes recebam um proxy nas filas de mensagens de seus amigos sempre que os amigos estiverem on-line. Eles podem, então, colocar mensagens diretamente entre si, evitando a necessidade de uma troca centralizada. O servidor manteria uma referência a todos os seus clientes on-line e notificaria as partes interessadas das conexões / desconexões de seus amigos por meio da fila.

Dimensionar isso para preencher uma única caixa se tornaria uma questão de adicionar interfaces de rede (ou usar um intervalo de portas na interface). Dimensionar isso em várias caixas exigiria a sincronização do servidor / passar proxies da fila de um lado para o outro ao acaso.

    
por 12.01.2014 / 21:13
fonte