Hello Tous,
Je ne suis pas du tout un specialiste de la question, mais pour les besoins
de la prochaine reunion des membres de l'association France-IX, nous aurions
besoin d'une camera qui soit en mesure de fournir un flux multicast, que
nous allons balancer vers un serveur VLC, afin que tout les
Hello,
Pourquoi un flux multicast ?
Tu ne peux pas unicaster le flux caméra-serveur, simplement ?
Ensuite, de toute manière, les participations en remote seront
probablement regardées en unicast.
--
Clément
On Wed, 2010-11-24 at 11:16 +0100, Raphael Maunier wrote:
Hello Tous,
Je ne
Le 24/11/10, Clement Cavadoreclem...@cavadore.net a écrit :
Re,
On Wed, 2010-11-24 at 11:30 +0100, Raphael Maunier wrote:
Pour faire un peu le geek ? Genre fournir le flux dans le vlan
Multicast du France-IX ?
Ouais, bah a ce moment la, si tu tiens absolument a faire geek (mais
m'est
On Wed, 2010-11-24 at 11:46 +0100, Rémi Bouhl wrote:
Et dans ce cas ce n'est pas forcément la peine d'avoir une caméra IP:
une webcam de très bonne qualité, en USB, peut suffire, non? En la
branchant directement sur le serveur qui fait tourner VLC.
Tout à fait. Ou une caméra classique avec une
On Wed, 24 Nov 2010 12:13:27 +0100, Clement Cavadore
clem...@cavadore.net wrote:
Tout à fait. Ou une caméra classique avec une carte d'acquisition
video
quelconque.
Je confirme. Configuration déjà testée :
webcam -USB- vieux laptop -ethernet- serveur qui encode et diffuse
en
2010/11/24 Pierre Chapuis catw...@archlinux.us
On Wed, 24 Nov 2010 12:13:27 +0100, Clement Cavadore clem...@cavadore.net
wrote:
Tout à fait. Ou une caméra classique avec une carte d'acquisition video
quelconque.
Je confirme. Configuration déjà testée :
webcam -USB- vieux laptop
Merci,
J'ai pas mal de proposition et je pense que on va avoir une ou plus version
du flux.
Des solutions normale et des solutions geeks :)
on pourra meme faire un comparatif bien geek sur via un Mac, via une Debian
et via une solution proprio ...
Raphael
2010/11/24 Raphael Maunier
http://www.networkworld.com/community/node/68781
Les commentaires complètent.
J'espère que cela répondra à une certaine attente sur cette liste.
Mohsen.
---
Liste de diffusion du FRnOG
http://www.frnog.org/
Bonjour,
Ce que tu cherches, n'est-il pas du filtrage de niv 7 ?
L'idée est de déterminée selon un pattern le flux, de le tagger et
ensuite appliquer les régles que tu souhaites (filtrages, QoS ...).
Cordialement,
Mathias
Le mercredi 24 novembre 2010 à 14:51 +0100, Rémy Sanchez a écrit :
On Wed, 24 Nov 2010 14:57:56 +0100, Mathias WMN
m.wo...@wm-networks.fr wrote:
Bonjour,
Ce que tu cherches, n'est-il pas du filtrage de niv 7 ?
L'idée est de déterminée selon un pattern le flux, de le tagger et
ensuite appliquer les régles que tu souhaites (filtrages, QoS ...).
Cordialement,
Si nous etiames vendreday, j'irions plus loin...
Après la concentration de tous les protocoles au dessus de TCP (ce qui était
deja une hérésie), puis de HTTP (n'en parlons pas)... Bienvenue vers la
concentration vers deux fqdn : www.google.com et www.facebook.com
Je remarque en effet, que
1/
Ce qui me gêne un peu plus c'est que c'est une des briques du grand
firewall Chinois/Iranien/Français (inutile de rayer la mention inutile :
la Loi LOPSSI nous prépare des choses sympa dans ce domaine...).
Pas besoin d'aller si loin, tous votre trafic http sur mobile passe par un
Firewall
Le 24/11/10, Rémy Sanchezremy.sanc...@hyperthese.net a écrit :
Après, vu à quel point les numéros de contorsioniste par HTTP se
démocratisent, laisser le HTTP sans aucun filtrage donne l'impression de
laisser tous les ports ouvert.
Il y a 10 ans:
Laisser les ports ouverts en sortie sans
On Wed, 2010-11-24 at 15:55 +0100, Rémi Bouhl wrote:
Prépare-toi, dans 10 ans, à devoir lutter contre les accès HTTP qui
font semblant d'être du vrai surf mais en fait si on met un quad-core
pour faire du DPI on se rend compte que c'est du VPN encapsulé dans
des pseudo-pages Web.
pas la
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Le 24/11/2010 15:47, guillaume.monne...@free.fr a écrit :
Après la concentration de tous les protocoles au dessus de TCP (ce qui était
deja une hérésie)
Sur ce point j'aimerais que tu développe un peu, je ne comprend pas bien.
C'est peut-être dû
On Wed, 2010-11-24 at 16:10 +0100, Rémy Sanchez wrote:
Pour situer mon contexte et l'origine de mon idée : je m'occupe du
réseau dans une résidence étudiante, avec un débit très limité par
rapport au nombre d'utilisateurs.
ne faudrait il pas commencer par la ? genre, augmenter le débit
Pour situer mon contexte et l'origine de mon idée : je m'occupe du réseau
dans une résidence étudiante, avec un débit très limité par rapport au
nombre d'utilisateurs. Et on ne peut pas dire que tout soit bloqué sur le
réseau, on ouvre les ports à la demande. Seulement, j'aimerais que le
On Wed, 24 Nov 2010 16:13:36 +0100, Raphaël Jacquot sxp...@sxpert.org
wrote:
On Wed, 2010-11-24 at 16:10 +0100, Rémy Sanchez wrote:
Pour situer mon contexte et l'origine de mon idée : je m'occupe du
réseau dans une résidence étudiante, avec un débit très limité par
rapport au nombre
Le constat est que tout passe dans un énorme tuyau qu'est le HTTP et que
peut être qu'il faudrait y mettre plus de contrôle à l'intérieur, avec des
nouveaux outils plus adaptés que ce qu'on a aujourd'hui.
http://en.wikipedia.org/wiki/Multilayer_switch
Et ça fait aussi avec des linux
On Wed, 24 Nov 2010 15:47:48 +0100 (CET), guillaume.monne...@free.fr
wrote:
Si nous etiames vendreday, j'irions plus loin...
Après la concentration de tous les protocoles au dessus de TCP (ce
qui était deja une hérésie), puis de HTTP (n'en parlons pas)...
Bienvenue vers la concentration
Le 24 novembre 2010 16:10, Rémy Sanchez remy.sanc...@hyperthese.net a
écrit :
Pour situer mon contexte et l'origine de mon idée : je m'occupe du réseau
dans une résidence étudiante, avec un débit très limité par rapport au
nombre d'utilisateurs. Et on ne peut pas dire que tout soit bloqué sur
Le 24/11/10, David Ramahefasonr...@netfacile.net a écrit :
Si ton problème est juste d'avoir assez de BP pour tous tout le temps,
et non de savoir exactement ce que font tes usagers,
qu'ils utilisent HTTP ou non, pourquoi ne pas mettre en place des
règles de Qos/Shaping qui brident le fou de
On Wed, 2010-11-24 at 16:59 +0100, Rémi Bouhl wrote:
Le 24/11/10, David Ramahefasonr...@netfacile.net a écrit :
Si ton problème est juste d'avoir assez de BP pour tous tout le temps,
et non de savoir exactement ce que font tes usagers,
qu'ils utilisent HTTP ou non, pourquoi ne pas mettre
On Wed, 24 Nov 2010 16:57:50 +0100, Julien Richer jul...@ywigo.fr
wrote:
Le 24 novembre 2010 16:10, Rémy Sanchez a écrit :
Pour situer mon contexte et l'origine de mon idée : je m'occupe du
réseau dans une résidence étudiante, avec un débit très limité
par rapport au nombre d'utilisateurs.
On Wed, 24 Nov 2010 16:59:47 +0100, Rémi Bouhl remibo...@gmail.com
wrote:
Je plussoie l'idée.
Inutile d'aller chercher au niveau de la couche 7 ce que les gens
font
vraiment (et, à tout prendre, ce n'est pas à l'admin de décider de ce
qui est prioritaire, même en faisant preuve de bon sens).
Rémi Bouhl
Du coup je propose la solution couillue: ouvrir les vannes sur
les autres ports. Laisser sortir ce qui était encapsulé en HTTP,
afin qu'HTTP redevienne ce qu'il n'aurait pas du cesser d'être.
Oyez braves utilisateurs, vous pouvez sortir en SSH, en VPN et
en RDP, inutile de faire
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Le 24/11/2010 17:23, Rémy Sanchez a écrit :
Je ne parle pas de décider que tel ou tel site soit plus important, mais
on a bien inventé la QoS pour une raison non ? Par exemple, pour que de
la VoIP passe plus vite qu'un gros fichier qui passe en
Le 24/11/10, Rémy Sanchezremy.sanc...@hyperthese.net a écrit :
Je ne parle pas de décider que tel ou tel site soit plus important,
mais on a bien inventé la QoS pour une raison non ? Par exemple, pour
que de la VoIP passe plus vite qu'un gros fichier qui passe en FTP. Bon
maintenant si la
Salut,
Je ne parle pas de décider que tel ou tel site soit plus important,
mais on a bien inventé la QoS pour une raison non ? Par exemple, pour
que de la VoIP passe plus vite qu'un gros fichier qui passe en FTP.
Ben ouais la QoS c'est pour ça, mais pas besoin de monter au niveau 7
pour
On Wed, 24 Nov 2010 08:25:14 -0800, Michel Py
mic...@arneill-py.sacramento.ca.us wrote:
Rémi Bouhl
Du coup je propose la solution couillue: ouvrir les vannes sur
les autres ports. Laisser sortir ce qui était encapsulé en HTTP,
afin qu'HTTP redevienne ce qu'il n'aurait pas du cesser d'être.
Le 24/11/2010 17:23, Rémy Sanchez a écrit :
Mes utilisateurs vont être content avec leur 100kbps par personne
tiens :)
S'il utilisent tous le tuyau en même temps, c'est normal. Après c'est
plus la taille du tuyau, le problème, pas la QoS.
Je ne parle pas de décider que tel ou tel site soit
On Wed, 2010-11-24 at 17:26 +0100, Simon Morvan wrote:
Le 24/11/2010 17:23, Rémy Sanchez a écrit :
Mes utilisateurs vont être content avec leur 100kbps par personne
tiens :)
S'il utilisent tous le tuyau en même temps, c'est normal. Après c'est
plus la taille du tuyau, le problème, pas
On Wed, November 24, 2010 16:59, Rémi Bouhl wrote:
Le 24/11/10, David Ramahefasonr...@netfacile.net a écrit :
Si ton problÚme est juste d'avoir assez de BP pour tous tout le temps,
et non de savoir exactement ce que font tes usagers, qu'ils utilisent
HTTP ou non, pourquoi ne pas mettre
On Wed, 2010-11-24 at 17:35 +0100, Stephen wrote:
Virgin Media (câble opérateur UK) a un système différent qui me semble pas
trop bête : pendant les périodes de forte activité réseau, la quantité de
données échangée par utilisateur est comptabilisée et si un dépassement de
quota est constaté
On Wed, 24 Nov 2010 17:29:37 +0100, Mehdi AMINI joker@gmail.com
wrote:
Salut,
Je ne parle pas de décider que tel ou tel site soit plus important,
mais on a bien inventé la QoS pour une raison non ? Par exemple, pour
que de la VoIP passe plus vite qu'un gros fichier qui passe en FTP.
Le 24 novembre 2010 17:15, Rémy Sanchez remy.sanc...@hyperthese.net a écrit :
Mais encore une fois, j'aimerais ne pas parler de ce problème en
particulier. Plutôt, je viens ici pour savoir si quelqu'un voit une utilité
ou une cohérence quelconque à un outil capable de comprendre le HTTP et les
On Wed, 24 Nov 2010 16:26:22 +0100, Rémy Sanchez
remy.sanc...@hyperthese.net said:
Le constat est que tout passe dans un énorme tuyau qu'est le HTTP et
que peut être qu'il faudrait y mettre plus de contrôle à l'intérieur,
avec des nouveaux outils plus adaptés que ce qu'on a aujourd'hui.
Radu-Adrian Feurdean a écrit:
et certains elus moins cons contre cette loi.
A rajouter dans la lettre au Père Noël, définitivement.
Des politiciens moins cons que leurs prédécesseurs!
:-D
Michel.
---
Liste de diffusion du FRnOG
http://www.frnog.org/
On Wed, 24 Nov 2010 17:23:37 +0100, Rémy Sanchez
remy.sanc...@hyperthese.net said:
que de la VoIP passe plus vite qu'un gros fichier qui passe en FTP. Bon
maintenant si la VoIP et le gros fichier passent tous les deux par le
Ca ca marche en entreprise, ou la prioritisation de tel ou tel
On Wed, 24 Nov 2010 17:25:44 +0100, Rémy Sanchez
remy.sanc...@hyperthese.net said:
Attention piège : on a un proxy donc c'est uniquement lui que la
passerelle va voir. Et limiter le nombre de connexions par IP au niveau
du proxy c'est pas possible à cause des long polls précédemment
On Wed, 24 Nov 2010 17:33:16 +0100, Rémy Sanchez
remy.sanc...@hyperthese.net said:
Mais le fait est que là 95% du flux de données passe par du HTTP, et
qu'on commence vraiment à avoir des types d'applications variées qui se
distingues. Comme ce qu'on avait en TCP/UDP avant, mais remonté
On 11/24/2010 07:04 PM, Radu-Adrian Feurdean wrote:
Pourquoi ?
Pour qu'un service qui a besoin d'une bonne réactivité mais de peu de
débit ne soit pas pénalisé par un service qui se fiche de la réactivité
mais mange du débit à fond ?
On a pas encore appris les lecons du controle au nieveaux 3
On 11/24/2010 07:19 PM, Radu-Adrian Feurdean wrote:
Tu peux aussi revoir legerement ton architecture.
Tu suggères ?
--
Rémy Sanchez
http://hyperthese.net
signature.asc
Description: OpenPGP digital signature
On 11/24/2010 07:26 PM, Radu-Adrian Feurdean wrote:
Pour la n-ieme fois, le rappel (en anglais cette fois):
We're network admins. To us, data is just a protocol-overhead.
Oublie tout ce qui depasse le niveau 3 !!!
Tu peux encore faire du QoS nu niveau 3, faut juste revoir ton facon de
2010/11/24 Rémy Sanchez remy.sanc...@hyperthese.net:
Moi j'veux bien faire du DiffServ, mais à un moment faut qu'on me mette
les champs à la bonne valeur. À ma connaissance, les navigateurs ne
savent pas faire ça, et il n'existe pas d'outil (libre, vu que dans le
commerce ça a l'air d'exister)
Le 24/11/2010 17:47, Raphaël Jacquot a écrit :
On Wed, 2010-11-24 at 17:35 +0100, Stephen wrote:
Virgin Media (câble opérateur UK) a un système différent qui me semble pas
trop bête : pendant les périodes de forte activité réseau, la quantité de
données échangée par utilisateur est
Salut Rémy,
(...)
Le 24 nov. 2010 à 17:56, Rémy Sanchez a écrit :
En somme, pourquoi l'accès à un traitement de texte en ligne devrait être
traité avec la même priorité qu'un téléchargement de masse ? Ce sont deux
services totalement différents, avec des besoins totalement différents aussi.
On 11/24/2010 09:05 PM, Mattieu Baptiste wrote:
2010/11/24 Rémy Sanchez remy.sanc...@hyperthese.net:
Moi j'veux bien faire du DiffServ, mais à un moment faut qu'on me mette
les champs à la bonne valeur. À ma connaissance, les navigateurs ne
savent pas faire ça, et il n'existe pas d'outil
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bonjour,
Le 24/11/2010 19:39, Rémy Sanchez a écrit :
On 11/24/2010 07:04 PM, Radu-Adrian Feurdean wrote:
Pourquoi ?
Pour qu'un service qui a besoin d'une bonne réactivité mais de peu
de débit ne soit pas pénalisé par un service qui se fiche de
On Wed, 24 Nov 2010 22:02:08 +0100, Rémy Sanchez
remy.sanc...@hyperthese.net said:
par ce que je sais très bien que les problèmes viennent de la bande
passante, et tu sais comme moi à quel point on n'a pas de budget. Donc
T'as un probleme de bande passante, t'as de utilisateurs qui veulent de
On Wed, 24 Nov 2010 22:31:16 +0100, Antoine MUSSO amu...@free.fr
said:
En revanche j'ai au moins deux problèmes avec le /127 :
- le routeur qui a pour masque par défaut un /64 et l'annonce au
backbone aspirant ainsi toutes tes intercos.
- l'impossibilité d'intercaler un équipement
On 11/24/2010 11:05 PM, Radu-Adrian Feurdean wrote:
On Wed, 24 Nov 2010 22:02:08 +0100, Rémy Sanchez
remy.sanc...@hyperthese.net said:
par ce que je sais très bien que les problèmes viennent de la bande
passante, et tu sais comme moi à quel point on n'a pas de budget. Donc
T'as un
Le 24 novembre 2010 23:19, Rémy Sanchez remy.sanc...@hyperthese.net a écrit :
Mais s'il vous plaît, est-ce qu'on pourrait arrêter de parler de cette
résidence ? Même si c'est un problème rencontré là bas qui m'a poussé à
me poser la question, le but du jeu n'était pas de trouver un moyen
Le 25/11/10, Rémy Sanchezremy.sanc...@hyperthese.net a écrit :
J'ai enfin réussi à bien expliquer ma question ? J'peux recommencer
sinon j'suis plus à ça près -_-
Tout le monde a compris le problème (plein de gens, font des trucs
très différents en HTTP, pas assez de BP pour tous).
C'est
On 25/11/10 00:04, Rémy Sanchez wrote:
snip
La question porte donc sur les capacités des logiciels actuels en L7 :
sont-ils capable de différencier les différentes applications et de
prendre en compte leurs spécificités ?
J'ai vu quelques produits capables de différencier les parties
55 matches
Mail list logo
