C'est possible mais pas directement car, en soi, un port est indissociable de l'adresse à laquelle on va le chercher : le routage se fait avant tout en fonction des machines que tu cherches à joindre (donc par leur adresse). Tu peux en revanche écrire des règles de filtrage qui n'examinent que le numéro de port et appliquer un traitement en conséquence sur tes paquets.
Par contre si tu es relié à Internet d'une manière générale mais que ton VPN t'envoie vers un autre réseau depuis lequel tu peux également voir le Net en entier, typiquement si tu fais du Net au boulot et que tu disposes d'un VPN vers ta machine mais que les ports Bittorent sont filtrés par l'admin de ta boîte (je suppose que c'est le problème qui t'amène ici) alors il faut déclarer une passerelle supplémentaire en plus de la passerelle par défaut, passant par ton tunnel VPN et en activant le forwarding de l'autre côté. Tu peux aussi lui ajouter une métrique élevée et ajouter deux règles iptables pour interdire le trafic torrent via la passerelle par défaut et n'autoriser QUE le trafic torrent par l'autre.
Enfin, si tu n'as l'intention de contacter qu'un seul serveur, tu peux t'épargner toute cette peine avec « ssl -L ».
Donc, en fait, il faut juste voir en gros comment le trafic Internet fonctionne et le reste viendra naturellement.
est ce qu'il y a des bibliothèque spécialement pour sa???
Indice : le « ç » se trouve sur la touche « 9 »
Pour le reste, la conversion des adresses virtuelles en adresses physique est effectuée électroniquement et directement par la MMU du micro-processeur lui-même.
Si tu veux le faire à la main, c'est possible parce qu'il ne s'agit formellement que d'additions, de quelques décalages et de masques ET. Donc, nul besoin d'avoir une bibliothèque dédiée. Par contre, tu auras besoin de savoir comment le système d'exploitation que tu utilises, lui, répartit ses processus en mémoire.
Il n'aurait pas pu demander à avoir une meilleure tronche, ton geek ? Il aurait pu avoir toutes les petites amies qu'il veut et ça n'aurait rien changé à son Windows…
Merci beaucoup pour ton tutoriel, c'est sympa d'en faire profiter la communauté. Par contre, ceci : « toute les commandes tapez dans une terminal », franchement ça pique les yeux. Je le dis sans méchanceté ni retenue car je vois bien que c'est du laisser aller et pas de réelles difficultés en orthographe.
Sache que ce n'est pas un détail de chipoteur ni un point de détail secondaire une fois le contenu mis en ligne. C'est réellement dérangeant pour ton lecteur et ça peut le pousser à fuir l'essentiel.
Qu'est-ce qui se passe lorsque tu essaies d'accéder aux consoles en mode texte (Avec Alt+F1..F12 ou Ctrl+Alt+F1..F12) ? Ces consoles sont-elles en frame buffer ou en vrai mode texte ?
Ça semble d'ailleurs se confirmer si tu alloues un tout petit peu moins d'objet que prévu : si tu remplaces
NB_ALLOC 1024*1024
par
NB_ALLOC 1024*1024 - 1024
Tu divises par deux ta consommation mémoire qui redevient proche de celle que tu attends. Comme 1024×1024 est une puissance de deux et que la taille des pages allouées par fast_pool_allocator<> doit l'être aussi, tu dois probablement remplir tout juste une page vers la fin de ta boucle, et l'alloueur prépare la suite en allouant autant d'espace qu'il en a utilisé jusque là. Cette dernière page restant alors majoritairement vide.
Effectivement, cela a l'air de venir de fast_pool_allocator. J'ai essayé avec un simple « new Foo[NB_ALLOC] » et la consommation redevient celle attendue. Je n'ai pas esssayé avec « pool_allocator » tout court car l'interface n'est pas tout-à-fait la même et que ça me faisait suer d'adapter tout ton exemple. :-) Ça ne m'étonne qu'à moitié car privilégier la vitesse se fait traditionnellement au dépit de la mémoire. Les liens entre les deux sont évidemment complexes mais on arrive généralement à une relation inversement proportionnelles, ou à peu près.
En affichant dans la boucle les valeurs des pointeurs renvoyés par new, on s'aperçoit qu'ils sont consécutifs et croissants puis qu'ils sautent brusquement, à intervalles réguliers, d'une plage vers une autre. Il est donc raisonnable de penser que le pool alloue d'emblée une plage suffisamment grande mais de taille arbitraire au départ et que, comme tu ne fais que la remplir sans libérer tes objets (dans ton exemple), à chaque fois qu'il se retrouve au dépourvu, il décide d'allouer cette fois une plage deux fois plus grande que la précédente.
[^] # Re: Au bûcher !!!!
Posté par Obsidian . En réponse au journal [HS] Pluvieux, Heureux. Évalué à 3.
C'est une bonne idée d'allumer un bûcher sous la pluie, en effet… :-)
[^] # Re: Port + Adresse
Posté par Obsidian . En réponse au message rediriger un port sur une interface réseau. Évalué à 1.
Moi, en revanche, je crois que tu ne m'as pas compris. :-)
La solution est dans le paragraphe qui suit. Lis-le en détails et dis-nous dans quelles conditions tu travailles.
# Port + Adresse
Posté par Obsidian . En réponse au message rediriger un port sur une interface réseau. Évalué à 1.
C'est possible mais pas directement car, en soi, un port est indissociable de l'adresse à laquelle on va le chercher : le routage se fait avant tout en fonction des machines que tu cherches à joindre (donc par leur adresse). Tu peux en revanche écrire des règles de filtrage qui n'examinent que le numéro de port et appliquer un traitement en conséquence sur tes paquets.
Par contre si tu es relié à Internet d'une manière générale mais que ton VPN t'envoie vers un autre réseau depuis lequel tu peux également voir le Net en entier, typiquement si tu fais du Net au boulot et que tu disposes d'un VPN vers ta machine mais que les ports Bittorent sont filtrés par l'admin de ta boîte (je suppose que c'est le problème qui t'amène ici) alors il faut déclarer une passerelle supplémentaire en plus de la passerelle par défaut, passant par ton tunnel VPN et en activant le forwarding de l'autre côté. Tu peux aussi lui ajouter une métrique élevée et ajouter deux règles iptables pour interdire le trafic torrent via la passerelle par défaut et n'autoriser QUE le trafic torrent par l'autre.
Enfin, si tu n'as l'intention de contacter qu'un seul serveur, tu peux t'épargner toute cette peine avec « ssl -L ».
Donc, en fait, il faut juste voir en gros comment le trafic Internet fonctionne et le reste viendra naturellement.
[^] # Re: C'est possible
Posté par Obsidian . En réponse au message Comment faire...... Évalué à 3.
Si je ne dis pas d'ânerie, c'est spécifique à Linux et à ext[234].
« +i ».
[^] # Re: C'est possible
Posté par Obsidian . En réponse au message Comment faire...... Évalué à 2.
Ou un chattr, mais ce serait étonnant sur un simple fichier de conf'.
[^] # Re: Une sélection pour finir ma contribution
Posté par Obsidian . En réponse à la dépêche Blagues d'informaticiens. Évalué à 2.
Avec le logiciel aussi, on l'est rarement. Quiconque travaille dans une équipe de développement le sait ! :-)
Donc : aucune différence.
[^] # Re: Approximation
Posté par Obsidian . En réponse à la dépêche Blagues d'informaticiens. Évalué à 2.
C"est aussi le nom de ma Fedora 18 et, du coup, ça explique bien des choses… :-\
[^] # Re: Petite correction
Posté par Obsidian . En réponse à la dépêche Blagues d'informaticiens. Évalué à 1.
Tu es sûr que l'anglais ne serait pas la pire des langues « à l'exception de toutes les autres » ?
# Mémoire virtuelle
Posté par Obsidian . En réponse au message memoire virtuelle . Évalué à 4.
Bonjour,
Indice : le « ç » se trouve sur la touche « 9 »
Pour le reste, la conversion des adresses virtuelles en adresses physique est effectuée électroniquement et directement par la MMU du micro-processeur lui-même.
Si tu veux le faire à la main, c'est possible parce qu'il ne s'agit formellement que d'additions, de quelques décalages et de masques ET. Donc, nul besoin d'avoir une bibliothèque dédiée. Par contre, tu auras besoin de savoir comment le système d'exploitation que tu utilises, lui, répartit ses processus en mémoire.
# Racket ?
Posté par Obsidian . En réponse au message Interface utilisateur scheme/racket. Évalué à 5.
Moi, je dis qu'utiliser un langage qui s'appelle « racket » pour gérer des transactions financières, c'est tendre le bâton pour se faire battre. :-)
[^] # Re: Petite correction
Posté par Obsidian . En réponse à la dépêche Blagues d'informaticiens. Évalué à 3.
Mais maintenant, tu écris correctement, et au bout de sept commentaires seulement !
Finalement, ce n'est pas si compliqué. :-)
[^] # Re: Par Matt Ratcliffe
Posté par Obsidian . En réponse à la dépêche Blagues d'informaticiens. Évalué à 10.
Sans compter le célèbre :
[^] # Re: Blue screen
Posté par Obsidian . En réponse à la dépêche Blagues d'informaticiens. Évalué à 4.
Il n'aurait pas pu demander à avoir une meilleure tronche, ton geek ? Il aurait pu avoir toutes les petites amies qu'il veut et ça n'aurait rien changé à son Windows…
[^] # Re: C
Posté par Obsidian . En réponse à la dépêche Blagues d'informaticiens. Évalué à 10.
Immédiatement suivie de « ta mère en short », en principe. :-)
[^] # Re: Nan mais allo quoi
Posté par Obsidian . En réponse au journal 3 de moins sur terre. Évalué à 2.
Pourquoi ? Ils prévoient d'envoyer Nabilla dans l'espace ?
[^] # Re: 3 taïkonautes
Posté par Obsidian . En réponse au journal 3 de moins sur terre. Évalué à 5.
Je propose « spastrocosmes » pour mettre tout le monde d'accord. :-)
# Aïe ! Mes yeux !
Posté par Obsidian . En réponse au message Loguez toute les commandes tapées dans un terminal dans une base mysql. Évalué à 5.
Hello,
Merci beaucoup pour ton tutoriel, c'est sympa d'en faire profiter la communauté. Par contre, ceci : « toute les commandes tapez dans une terminal », franchement ça pique les yeux. Je le dis sans méchanceté ni retenue car je vois bien que c'est du laisser aller et pas de réelles difficultés en orthographe.
Sache que ce n'est pas un détail de chipoteur ni un point de détail secondaire une fois le contenu mis en ligne. C'est réellement dérangeant pour ton lecteur et ça peut le pousser à fuir l'essentiel.
À part cela, bon courage pour tes futurs hacks.
[^] # Re: records
Posté par Obsidian . En réponse à la dépêche Première mise en demeure pour l'association LinuxFr. Évalué à 3.
Ça y est. :-)
[^] # Re: Et ?
Posté par Obsidian . En réponse à la dépêche Message du Président Directeur Général de Linkeo. Évalué à 10.
→ Non.
[^] # Re: .
Posté par Obsidian . En réponse au message réformes. Évalué à 5.
Frappé, c'est certain. Au coin du bon sens, c'est moins sûr.
[^] # Re: Open Bar
Posté par Obsidian . En réponse à la dépêche L'accord cadre « Open Bar » Microsoft/Défense en cours de renégociation. Évalué à 2.
Surtout quand ça concerne le ministère de la défense…
# chezmoicamarche
Posté par Obsidian . En réponse au message P****n de 1er Avril !. Évalué à 3.
C'est curieux. Tu peux nous faire une capture d'écran ?
Et effectivement, as-tu l'occasion de tester cela avec un autre navigateur ? (voire, éventuellement, de t'en tenir à celui-ci).
[^] # Re: hypothèse
Posté par Obsidian . En réponse au message Problème d'écran qui reste éteint jusqu'au démarrage de X. Évalué à 2.
Qu'est-ce qui se passe lorsque tu essaies d'accéder aux consoles en mode texte (Avec Alt+F1..F12 ou Ctrl+Alt+F1..F12) ? Ces consoles sont-elles en frame buffer ou en vrai mode texte ?
[^] # Re: FAST pool allocator
Posté par Obsidian . En réponse au message operator new + boost::fast_pool_allocator. Évalué à 5. Dernière modification le 20 avril 2013 à 15:16.
Ça semble d'ailleurs se confirmer si tu alloues un tout petit peu moins d'objet que prévu : si tu remplaces
par
Tu divises par deux ta consommation mémoire qui redevient proche de celle que tu attends. Comme 1024×1024 est une puissance de deux et que la taille des pages allouées par fast_pool_allocator<> doit l'être aussi, tu dois probablement remplir tout juste une page vers la fin de ta boucle, et l'alloueur prépare la suite en allouant autant d'espace qu'il en a utilisé jusque là. Cette dernière page restant alors majoritairement vide.
# FAST pool allocator
Posté par Obsidian . En réponse au message operator new + boost::fast_pool_allocator. Évalué à 4.
Hello,
Effectivement, cela a l'air de venir de fast_pool_allocator. J'ai essayé avec un simple «
new Foo[NB_ALLOC]
» et la consommation redevient celle attendue. Je n'ai pas esssayé avec « pool_allocator » tout court car l'interface n'est pas tout-à-fait la même et que ça me faisait suer d'adapter tout ton exemple. :-) Ça ne m'étonne qu'à moitié car privilégier la vitesse se fait traditionnellement au dépit de la mémoire. Les liens entre les deux sont évidemment complexes mais on arrive généralement à une relation inversement proportionnelles, ou à peu près.En affichant dans la boucle les valeurs des pointeurs renvoyés par
new
, on s'aperçoit qu'ils sont consécutifs et croissants puis qu'ils sautent brusquement, à intervalles réguliers, d'une plage vers une autre. Il est donc raisonnable de penser que le pool alloue d'emblée une plage suffisamment grande mais de taille arbitraire au départ et que, comme tu ne fais que la remplir sans libérer tes objets (dans ton exemple), à chaque fois qu'il se retrouve au dépourvu, il décide d'allouer cette fois une plage deux fois plus grande que la précédente.