Página 2 de 3 PrimeiroPrimeiro 123 ÚltimoÚltimo
+ Responder ao Tópico



  1. Não sei, de vocês mas acho que controlar P2P é falta de respeito com o cliente, já que ele contrata a velocidade por exemplo 500Kbps, e faz download em p2p a 15kbps, 5kbps.
    Primeiro acho isso ilegal, e segundo desrespeito para com o usuario.
    Se estamos provendo o serviço nada melhor do que prover o serviço com qualidade. entrega a banda do cara ele que se exploda se não conseguir navegar e ligar enchendo o saco, ae fala para ele desligar, o P2P.
    Mas veja bem isso em para quem controla P2P em provedor, não para uma empresa que tem sua banda limitada e tem usuarios detonando a rede com p2p, nesse caso só a favor até do bloqueio do P2P.

    Bom essa é minha opnião. e acho que isso vai dar uma discussão boa.

  2. O caso nao é bloqueio de p2p nem controlar a baixo do contratado, e sim limitar os sockets dos p2p para nao detonar com a rede.



  3. Citação Postado originalmente por GrayFox Ver Post
    O caso nao é bloqueio de p2p nem controlar a baixo do contratado, e sim limitar os sockets dos p2p para nao detonar com a rede.
    Justamente, e esse é o grande problema. O tráfego P2P é um veneno para qualquer rede, tanto que se o contrário fosse não existira ninguém trabalhando em ferramentas para contê-los.

    O que o Patrick mencionou sobre o SFQ é uma opção uma vez que requer pouco uso da CPU e RAM, além dos algorítimos estocásticos usados na política SFQ priorizarem os pacotes de acordo com configurações, descartando, assim, os demais no caso de saturação no roteador.

  4. Se não controlar o p2p, é humanamente impossível trabalhar em redes wireless. Não se trata de bloquear, mas de manter o p2p e a rede funcionando com qualidade.



  5. Seguinte pessoal, eu andei monitorando aqui o tráfego da minha rede, e notei que o access log do meu squid começou a mostrar uma quantidade muito grande de: " error:unsupported-request-method"....

    Fui atrás e percebi que isso tava acontecendo porque os softwares de p2p criptografados estava tentando a conexão pela porta 80, porém os headers dos pacotes não eram compatíveis com o protocolo HTTP, que é o que o squid espera e o cliente não consegue conectar na rede p2p, tendo que desconfigurar a opção de criptografia. Assim, então, voltam a sofrer o traffic shapping através do layer7 e do ipp2p.

    Quanto ao SFQ, seu objetivo é trabalhar na alocação/distribuição da banda de forma justa...mas a maneira como ele é implementado a distribuição da banda ainda se torna "unfair", visto que clientes com um número maior de requisições / conexões conseguem ter mais banda alocada do que clientes com poucas conexões.

    Para solucionar esse problema, foi criado um patch para o kernel e para o iproute, chamado ESFQ (Enhanced SFQ), onde se faz a alocação de banda por IP, e não por conexão.

    ESFQ for Linux 2.6

    Eu compilei e tô usando ele aqui...a diferença é muito grande...melhore e muito na equalização do compartilhamento da banda...






Tópicos Similares

  1. VOIP - Um novo golpe?
    Por muraro no fórum Servidores de Rede
    Respostas: 10
    Último Post: 13-01-2006, 15:24
  2. Montando um novo provedor
    Por daniel_tux no fórum Redes
    Respostas: 14
    Último Post: 01-12-2005, 14:08
  3. incluindo um novo gerenciador de janelas na tela de login
    Por major505 no fórum Servidores de Rede
    Respostas: 0
    Último Post: 26-07-2005, 16:26
  4. Wireless - Sempre um novo problema
    Por andrequiri no fórum Redes
    Respostas: 27
    Último Post: 23-12-2004, 00:51
  5. NOVO DESAFIO - FIREWALL
    Por 1c3m4n no fórum Servidores de Rede
    Respostas: 4
    Último Post: 03-10-2002, 12:56

Visite: BR-Linux ·  VivaOLinux ·  Dicas-L