Re: EP4: Dúvida sobre o Bounded Buffer

[Francisco Reverbel <reverbel at ime.usp.br>]

On Mon, 2 Jul 2001, Tiago wrote:

>  Francisco Reverbel wrote:
> 
> > On Thu, 28 Jun 2001, Tiago wrote:
> >
> > > Francisco Reverbel wrote:
> > >
> > > > Não, é mais simples que isso (vide acima). Recusar pedidos de conexão é
> > > > fácil: basta não chamar socket.accept().
> > > >
> > > > Reverbel
> > >
> > > Só que aí o cliente acha que o servidor caiu.
> >
> > Isso depende do cliente. Um cliente java vai ver uma exceção
> >
> >    java.net.ConnectException: Connection refused
> 
> Verdade. Mas é uma recusa "passiva", não é? Aos olhos do cliente, quem recusou a
> conexão foi o host, não necessariamente o servidor. Entre as razões, pode ser
> porque o servidor "caiu", FHC decretou apagão, o cliente está tentando conectar
> ao host errado (www.microsotf.com), problemas de NAT, mil coisas. Ao passo que
> uma mensagem "Erro: servidor ocupado. Tente novamente mais tarde." é garantido
> (o que não quer dizer menos frustrante).

Correto. Mesmo assim, o sistema de recusa "passiva" é usado por várias 
aplicações: web server/browser, telnet, etc. Experimente apontar o seu web
browser para um host e port no qual não há web server esperando conexão:

    http://jaca.ime.usp.br:1999

(O netscape vai dizer que o servidor "pode estar ocupado").

> 
> > É só o cliente apanhar essa exceção e interpretá-la corretamente.
> 
> Acho que concordaremos que interpretá-la corretamente não é simples, né? ; )

Sim, _se_ for importante distinguir o caso "server busy" do caso "server
down". Só que isso complica o protocolo entre cliente e servidor. Com o
esquema de "recusa passiva", o cliente tenta abrir uma conexão com o
servidor e, se conseguir, sabe que pode "falar", que o servidor estará
"ouvindo". 

Com a mensagem de "server busy", o cliente que acabou de abrir uma conexão
com o servidor não sabe se pode falar ou não. Antes de falar ele deve
escutar um pouco (por quanto tempo?) para ver se o servidor diz "server
busy"...  A mensagem de "server busy" requer a definição desse time-out e
as modificações correspondentes nos clientes. E ainda podem sobrar
problemas... O que acontece se a mensagem "server busy" demorar muito a
chegar por causa de algum problema qualquer? 

Note também que esse time-out acabe sendo adicionado ao tempo de resposta
medido do lado do cliente.

> 
> > > Não é melhor responder "Server busy"??
> >
> > Não sei se entendi... O servidor mandaria para o cliente uma mensagem
> > "server busy"? Como ele faria isso _sem_ aceitar uma conexão com o
> > cliente?
> >
> > Reverbel
> 
> Bom, ele abre a conexão TCP, mas não usa uma das Threads do pool, que
> interpretam comandos, etc. Usa a "main" mesmo, responde e fecha.
> 
> Eu ia postar aqui um trecho que uma mensagem anterior que supostamente dava como
> indesejado esse comportamento (não chamar accept()), mas quando li de novo,
> percebi que não é isso o que está escrito.
> 
> Meu ep está assim, respondendo "Server Busy". Posso deixá-lo assim?

Pode, desde que os seus clientes estejam escritos de modo coerente com o
protocolo que você definiu. Mas quero deixar bem clara minha opinião: não
acho uma boa solução.

Reverbel