Segue.

Bom pessoal, eu to vendo um pouco de opnioes a respeito dos recursos novos que foram implementados, entao vamos la por partes pra voces entenderem exatamente o que acontece (apesar de nao poder dar detalhes):

O controle de QoS com pipes nao é so um controle de QoS com pipes. Ele é uma possibilidade completamente nova que implementamos que possibilita que um aplicativo fora do kernel crie diversar "marcas" em soquetes DE FORA do kernel.

O controle de QoS foi um simples recurso que implementamos pra colocar em producao esse motor novo (no kernel), e checar sua estabilidade. A vantagem fundamental desse novo sistema é que ele permite que um novo soquete TCP, ao ser criado, ja possa ser marcado com diversas caracteristicas que serao utilizadas depois, para diversos fins, dentro do kernel.

A maior vantagem disso é que podemos fazer em velocidades incriveis, pois nao temos a "penalidade" de ter que criar copias de memoria inter-anel, movimentando buffer entre ring0 e ring3. Os soquetes ja vem com as suas "marcas de interesse" logo que sao criados em ring3.

Todo um subsistema novo foi criado, e apesar de todos os cuidados, kernel code sempre é complexo e o programador, sujeito a falhas.

Alem disso, codigo de kernel novo tem esse outro inconveniente: quando falha, nao é como um daemon que so zera o uptime e volta.. as falhas sempre levam a halts ou reboots.

Acredito que ja estabilizamos na RC12.1, e que nao existe mais nenhum problema no engine.

Ele vai permitir a criacao de recursos que ainda nao existem na maioria das ferramentas que temos acesso, e posso citar como exemplo mais simples o balanceamento de carga em layer7, criando por exemplo um mecanismo de balanceamento HTTP utilizando cookies como tecnica de persistencia, ao inves de simples tabelas de IP.

travou denovo por aqui!

Nos precisamos de apoio desses novos recursos para implementar tambem o que esta no plugin 62.

Esse é o motor novo que gera assinaturas dinamicas. Caso voces nao tenham observado, é um dos importantes novos recursos, e esta habilitando apenas nesse plugin por enquanto.

O que ele faz é identificar o objeto utilizando MD5 de microblocos de conteudo (e outras coisas mais que nao posso entrar em detalhes), e ele vai ser capaz de dar hit num arquivo,
esteja ele em qualquer servidor, com qualquer nome.

Por outro lado, este mesmo motor é capaz de identificar que um arquivo diferentes, ainda que esteja com o mesmo nome, no mesmo servidor, nao é o mesmo objeto.


Observem por exemplo o link

http://download.speedbit.com/ffmpeg.zip

Ele gera sempre a assinatura:

dynasig://[application/x-zip-compressed]:5775185/9A6246AF934ABCA669C139554FEC1974


Se alguem subir esse arquivo pra outro servidor, mudar o nome dele, e baixar ele e observar a marcacao de tag nos objetos pendentes, vera que eh a mesma assinatura.

Gente pra facilitar nossa vida, quem ta reportando travamento ta realmente na RC12.1??

Confirmem por favor.

Fiz a instalacao da nova versao.. ainda continua o mesmo problema no FTP utilizando tproxy... estou usando o speedr no modo bridge uma placa com wantproxy e outra lantproxy e bridge sem nenhuma e marcado a opcao de interceptar trafego FTP.. mesmo problema de permissao de pasta.. sem marcar essa opcao funciona apenas os FTP que tem acesso leitura anonymous...ex: ftp.unicamp.br.
Vejo que estao tentando corrigir os BUG fico a disposicao para ajudar.
Obrigado.

O meu travou...

Tava tranquilo desde cedo...

Cerca de 7 horas de uptime.

Fabio, voce continua tendo problemas nos FTPs com senha?

travou denovo por aqui!

E eu falando que é o QOS que esta travando o SpeedR. O buraco é mais embaixo.

http://www.youtube.com/watch?v=2ZBYtJq6zLc