Broker HTTP

Browser

Todas as abas de um mesmo browser vão para o mesmo slave, porque o broker usa um cookie no browser para amarrar o browser com o slave.

Ao abrir um Chrome e um Firefox e utilizar o mesmo broker para ambos, todas as conexões de smart client HTML (via broker) do Chrome irão para o mesmo slave, e todas as conexões de smart client HTML (via broker) do Firefox irão para o mesmo slave, que pode ser diferente do slave que atende o Chrome.

O browser tem um limite de abas (normalmente 6) que ele pode abrir ao mesmo para uma url, no caso a url do broker ou de um slave.
Então um browser pode ter no máximo 6 abas abertas com o mesmo broker.

Broker - balanceamento pode ser por número de sessões, ou por método round robin.

Broker - Sessões (Conexões no Protheus)

O broker vai distribuir os smart clients pelos slaves, sempre mandando para o slave com menos conexões.

O broker não faz distinção por máquina física, mas por endpoint: (ip/nome + porta).

Se no ini do broker os slaves forem agrupados por máquina física, então inicialmente o broker vai distribuir as conexões pelos slaves da primeira máquina física, depois pela segunda máquina física, etc.

O que se pode fazer é deixar intercalados no ini os slaves de máquinas físicas diferentes, assim no início o broker vai distribuir as conexões por máquinas diferentes.
Exemplo:
     REMOTE_SERVER_01 = maquina1 porta1
     REMOTE_SERVER_02 = maquina2 porta1
     REMOTE_SERVER_03 = maquina3 porta1
     REMOTE_SERVER_04 = maquina1 porta2
     REMOTE_SERVER_05 = maquina2 porta2
     REMOTE_SERVER_06 = maquina3 porta2
     REMOTE_SERVER_07 = maquina1 porta1
     REMOTE_SERVER_08 = maquina2 porta2
     REMOTE_SERVER_08 = maquina3 porta3

Broker - Round Robin

Colocar no ini do broker:
   SORT_METHOD = ROUND_ROBIN 

O broker vai distribuir os smart clients pelos slaves, seguindo a ordem que aparecem no ini do broker, sem fazer contagem de sessões/conexões.

O broker não faz distinção por máquina física, mas pelo endpoint (ip + port).

Se no ini do broker os slaves forem agrupados por máquina física, então sempre o broker vai distribuir as conexões pelos slaves da primeira máquina física, depois pela segunda máquina física, etc!

O que se pode fazer é deixar intercalados no ini os slaves de máquinas físicas diferentes, assim sempre o broker vai distribuir as conexões por máquinas diferentes.
Exemplo:
     REMOTE_SERVER_01 = maquina1 porta1
     REMOTE_SERVER_02 = maquina2 porta1
     REMOTE_SERVER_03 = maquina3 porta1
     REMOTE_SERVER_04 = maquina1 porta2
     REMOTE_SERVER_05 = maquina2 porta2
     REMOTE_SERVER_06 = maquina3 porta2
     REMOTE_SERVER_07 = maquina1 porta1
     REMOTE_SERVER_08 = maquina2 porta2
     REMOTE_SERVER_08 = maquina3 porta3

OBSERVAÇÃO: o método de balanceamento round robin é muito pouco usado em campo, então antes de ser usado sugere-se que seja feita uma homologação antes de ser colocado em produção.


Log do broker

No log do broker é fácil de ver o processo de balanceamento.

Smart client que não está na tabela do broker:
180322_111802 313C SHC0146 W x 01 ctx:008 o0r0R0s0S0 key CFC2D4ADDE2516488B46835DEBC0D345 not associated with a server // c:127.0.0.1:16722
180322_111802 313C BAL1111 N ctx:8 found available server 127.0.0.1:50004 association count:0
180322_111802 313C BAL0850 N associating key CFC2D4ADDE2516488B46835DEBC0D345 to server 127.0.0.1:50004 q0 (nAssoc: 0->1) (cli: 127.0.0.1:16722)

Smart client que já está na tabela do broker:
180322_111803 313C SHC0131 N x 01 ctx:009 o0r0R0s0S0 ok, server 127.0.0.1:50004 with key=[CFC2D4ADDE2516488B46835DEBC0D345] is available // c:127.0.0.1:16724
180322_111803 313C SHC0131 N x 01 ctx:007 o0r0R0s0S0 ok, server 127.0.0.1:50004 with key=[CFC2D4ADDE2516488B46835DEBC0D345] is available // c:127.0.0.1:16725
180322_111803 313C SHC0131 N x 01 ctx:011 o0r0R0s0S0 ok, server 127.0.0.1:50004 with key=[CFC2D4ADDE2516488B46835DEBC0D345] is available // c:127.0.0.1:16727
180322_111803 313C SHC0131 N x 01 ctx:010 o0r0R0s0S0 ok, server 127.0.0.1:50004 with key=[CFC2D4ADDE2516488B46835DEBC0D345] is available // c:127.0.0.1:16728

outro smart client que não está na tabela do broker:
180322_111810 313C SHC0146 W x 01 ctx:014 o0r0R0s0S0 key F3D0B8F106035D4CB48D4BB973F849AA not associated with a server // c:127.0.0.1:16733
180322_111810 313C BAL1111 N ctx:14 found available server 127.0.0.1:50003 association count:0
180322_111810 313C BAL0850 N associating key F3D0B8F106035D4CB48D4BB973F849AA to server 127.0.0.1:50003 q0 (nAssoc: 0->1) (cli: 127.0.0.1:16733)

etc

O broker HTTP pode ser usado como para receber conexões SSL vindas do cliente, e abrir conexões não-SSL com o servidor (appserver).

É importante ter em mente que não é possível garantir o funcionamento do broker com toda e qualquer aplicação web que use conexões criptografadas com o browser, por causa da enorme variedade de técnicas que podem ser utilizadas para escrever aplicações web.

Em outras palavras, antes de fazer o deployment de uma solução web neste cenário é preciso que a solução seja validada em laboratório com o broker configurado para aceitar conexões SSL.

Um outro ponto a considerar é que a solução precisa ser validada com browsers específicos (p. ex: Chrome e Firefox) devido ao fato de que diferentes browsers apresentam diferentes comportamentos, dependendo dos recursos utilizados ao escrever a aplicação web.

A configuração do broker para receber conexões SSL necessita das seguintes chaves no arquivo de configuração appserver.ini:

...
...
SSL_METHOD=SSL/TLS
SSL_CERTIFICATE=<nome do arquivo que contem o certificado>
SSL_KEY=<nome do arquivo que contem a chave a chave privada>
SSL_PASSPHRASE=<senha de proteção da chave privada>

; opcional
USING_SECURE_COOKIES = 1
...
...

A chave SSL_METHOD=SSL/TLS indica que o broker vai aceitar qualquer método escolhido pelo cliente.
A chave USING_SECURE_COOKIES indica ao broker se o cookie de sessão do broker vai ser criado como "secure cookie" (com atributos "secure" e "HttpOnly").