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