P� ! Eu realemente me apliquei na documenta��o !
Tanto � que descobri que existe um
net.inet.ip.fw.dyn_udp_lifetime (conte�do dessa vari�vel � em segundos)
e isso � usado exclusivamenta para regras din�micas, portanto obrigatoriamente utilizando o keep-state/check-state. Mas eu concordo, UDP � stateless sim. Agora, como explicar isso existir E funcionar no ipfw (1 e 2, com o mesmo comportamento) eu n�o sei.
Eu realmente n�o havia atentado para o fato de que a sintaxe de um pipe pode ter duplo sentido, ou seja, todos estarem compartilanhdo o mesmo pipe, muito embora eu acho que n�o seja verdade pelo seguinte:
o comando ipfw pipe list (para ipfw2) ou ipfw pipe show (para ipfw1) mostra realmente um pipe para cada conex�o !
Vejamos:
00010: 40.000 Kbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail
mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
0 udp 10.249.61.85/2863 200.174.147.10/27015 10 426 0 0 0
00020: 40.000 Kbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail
mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
0 udp 200.174.147.10/27015 24.126.211.218/3680 25945 3699591 0 0 694
Ao qu eme parece os pipes est�o l�, din�micos (eles REALMENTE desaparecem depois de algum tempo), mas � estranho que tenha esses "solu�os" de conex�o, *E* tamb�m, porque diabos ele diz que est� fazendo a limita��o a 40.000 Kbits/s ? Ou ser� que eu estou interpretando errado ?
Ainda em tempo: O jogo em quest�o � o Counter-Strike, e a performance de rede tem que ser muito limpa.
At 10:05 PM 12/15/2002, you wrote:
On Sun, 15 Dec 2002 20:45:22 -0300
Capriotti <[EMAIL PROTECTED]> wrote:
> Pois �, gente...
>
> Que fiasco essas regras de controle de velocidade, para mim...
>
> Por algum motivo as regras, do jeito que est�o descritas a� embaixo, ficam
> interrompendo a conex�o, e a performance final � deplor�vel, para quem
> depende de conex�o est�vel e flu�da (para jogo).
>
> >
> > ${fwcmd} add check-state
> >
> > # create a 5.5Kbps limit for CS gammers
> > ${fwcmd} add pipe 10 udp from any to me 27015 keep-state
> > ${fwcmd} add pipe 20 udp from me 27015 to any keep-state
> >
> > ${fwcmd} pipe 10 config bw 5Kbytes/s
> > ${fwcmd} pipe 20 config bw 5Kbytes/s
> >
> >O objetivo ;e criar uma regra din�mica para cada pessoa que se conecta
> >para que cada um s� possa usar 5 Kbytes/s de banda, mas n�o sei at� que
> >ponto est� realmente funcionando... Tenho uns resultados estranhos, com
> >banda ABAIXO do especificado, dentre outros...
> >
> >Fiz algo de errado ou algu�m sabe tem algum bug mesmo ?
parefraseando Maxell Smart (agente 86) :
"O velho truque da documenta��o do ipfw..."
-----
(tirado do man ipfw)
The pipe and queue configuration commands are the following:
pipe number config pipe-configuration
-----
note: "number" � o n�mero *do pipe* e n�o *de pipes*
Somente olhando as regras (sem ter realmente acompanhado as mensagens anteriores):
voce criou regras para que *todas* as conex�es na porta 27015 compartilhem 5kbps !!!
voce s� tem 2 pipes: 1 de entrada e 1 de saida
n�o sei que jogo �, mas qualquer jogo rodando "em um unico modem de 4800bps" deve realmente ficar lento.
*se* a ideia � ter *um pipe por conex�o* as regras deveriam ser muito diferentes:
1 - definir o numero maximo de conex�es simult�neas
2 - criar 1 pipe para cada conex�o possivel
3 - (aqui est� o problema) identificar o IP de cada conex�o e criar uma regra para ele.
acho que para fazer isso, somente as regras do ipfw *n�o s�o suficientes*; provavelmente vai ser necessario um script que fique acrescentando e removendo regras.
Mais uma nota: UDP, por defini��o, � 'stateless' ; as op��es de 'check-state', 'keep-state' etc. , com UDP, s� servem para diminuir, muito pouco, o processamento do ipfw.
_______________________________________________________________ Sair da Lista: http://www2.fugspbr.org/mailman/listinfo/fugspbr Historico: http://www4.fugspbr.org/lista/html/FUG-BR/
