Il est bien connu que les sockets UDP ne sont pas fiables sur un brin
physique. Mais je me demandais ce qu'il en était de sockets UDP sur le
loopback. Est il possible sur certains Unix (et sur linux/*bsd en
particulier) de perdre des paquets UDP ?
Ou bien est ce que comme le bon sens le suppose les sockets UDP sur
localhost sont fiables ?
le but est d'éviter d'avoir à créer une socket unix avec les désagréables
besoin de lancer le programme en root si on veut avoir la socket
dans /var/run/$(myprog).sock. surtout pour "jouer" un protocole où il y a
un envoi puis une réception de message, c'est un peu exagéré de sortir un
mode connecté pour ca.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
pour "jouer" un protocole où il y a un envoi puis une réception de message, c'est un peu exagéré de sortir un mode connecté pour ca.
Ceci dit, il est très rapide.
-- Oups....
Nicolas George
Pierre Habouzit wrote in message <43822fac$0$4304$:
le but est d'éviter d'avoir à créer une socket unix avec les désagréables besoin de lancer le programme en root si on veut avoir la socket dans /var/run/$(myprog).sock.
Il suffit de ne pas mettre la socket dans ce répertoire-là.
Pierre Habouzit wrote in message
<43822fac$0$4304$626a54ce@news.free.fr>:
le but est d'éviter d'avoir à créer une socket unix avec les désagréables
besoin de lancer le programme en root si on veut avoir la socket
dans /var/run/$(myprog).sock.
Il suffit de ne pas mettre la socket dans ce répertoire-là.
Pierre Habouzit wrote in message <43822fac$0$4304$:
le but est d'éviter d'avoir à créer une socket unix avec les désagréables besoin de lancer le programme en root si on veut avoir la socket dans /var/run/$(myprog).sock.
Il suffit de ne pas mettre la socket dans ce répertoire-là.
Pierre Habouzit
Nicolas George wrote:
Pierre Habouzit wrote in message <43822fac$0$4304$:
le but est d'éviter d'avoir à créer une socket unix avec les désagréables besoin de lancer le programme en root si on veut avoir la socket dans /var/run/$(myprog).sock.
Il suffit de ne pas mettre la socket dans ce répertoire-là.
Ce qui demande alors (au choix) : (1) d'avoir un utilisateur dévolu au démon en question. Ce qui est pénible. (2) de mettre la socket dans /tmp. Ce qui est moche.
-- ·O· Pierre Habouzit ··O OOO http://www.madism.org
Nicolas George wrote:
Pierre Habouzit wrote in message
<43822fac$0$4304$626a54ce@news.free.fr>:
le but est d'éviter d'avoir à créer une socket unix avec les désagréables
besoin de lancer le programme en root si on veut avoir la socket
dans /var/run/$(myprog).sock.
Il suffit de ne pas mettre la socket dans ce répertoire-là.
Ce qui demande alors (au choix) :
(1) d'avoir un utilisateur dévolu au démon en question. Ce qui est pénible.
(2) de mettre la socket dans /tmp. Ce qui est moche.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
Pierre Habouzit wrote in message <43822fac$0$4304$:
le but est d'éviter d'avoir à créer une socket unix avec les désagréables besoin de lancer le programme en root si on veut avoir la socket dans /var/run/$(myprog).sock.
Il suffit de ne pas mettre la socket dans ce répertoire-là.
Ce qui demande alors (au choix) : (1) d'avoir un utilisateur dévolu au démon en question. Ce qui est pénible. (2) de mettre la socket dans /tmp. Ce qui est moche.
-- ·O· Pierre Habouzit ··O OOO http://www.madism.org
Stephane Chazelas
2005-11-21, 23:11(+01), Pierre Habouzit:
Nicolas George wrote:
Pierre Habouzit wrote in message <43822fac$0$4304$:
le but est d'éviter d'avoir à créer une socket unix avec les désagréables besoin de lancer le programme en root si on veut avoir la socket dans /var/run/$(myprog).sock.
Il suffit de ne pas mettre la socket dans ce répertoire-là.
Ce qui demande alors (au choix) : (1) d'avoir un utilisateur dévolu au démon en question. Ce qui est pénible. (2) de mettre la socket dans /tmp. Ce qui est moche.
Pourquoi? Il me semble que /tmp est tout indiqué pour des trucs temporaires
Et ~/.myprog.sock ou ~/.myprog/sock pour un truc lancé par un utilisateur pour un utilisateur.
-- Stéphane
2005-11-21, 23:11(+01), Pierre Habouzit:
Nicolas George wrote:
Pierre Habouzit wrote in message
<43822fac$0$4304$626a54ce@news.free.fr>:
le but est d'éviter d'avoir à créer une socket unix avec les désagréables
besoin de lancer le programme en root si on veut avoir la socket
dans /var/run/$(myprog).sock.
Il suffit de ne pas mettre la socket dans ce répertoire-là.
Ce qui demande alors (au choix) :
(1) d'avoir un utilisateur dévolu au démon en question. Ce qui est pénible.
(2) de mettre la socket dans /tmp. Ce qui est moche.
Pourquoi? Il me semble que /tmp est tout indiqué pour des trucs
temporaires
Et ~/.myprog.sock ou ~/.myprog/sock pour un truc lancé par un
utilisateur pour un utilisateur.
Pierre Habouzit wrote in message <43822fac$0$4304$:
le but est d'éviter d'avoir à créer une socket unix avec les désagréables besoin de lancer le programme en root si on veut avoir la socket dans /var/run/$(myprog).sock.
Il suffit de ne pas mettre la socket dans ce répertoire-là.
Ce qui demande alors (au choix) : (1) d'avoir un utilisateur dévolu au démon en question. Ce qui est pénible. (2) de mettre la socket dans /tmp. Ce qui est moche.
Pourquoi? Il me semble que /tmp est tout indiqué pour des trucs temporaires
Et ~/.myprog.sock ou ~/.myprog/sock pour un truc lancé par un utilisateur pour un utilisateur.
-- Stéphane
Pierre Habouzit
Stephane Chazelas wrote:
2005-11-21, 23:11(+01), Pierre Habouzit:
Nicolas George wrote:
Pierre Habouzit wrote in message <43822fac$0$4304$:
le but est d'éviter d'avoir à créer une socket unix avec les désagréables besoin de lancer le programme en root si on veut avoir la socket dans /var/run/$(myprog).sock.
Il suffit de ne pas mettre la socket dans ce répertoire-là.
Ce qui demande alors (au choix) : (1) d'avoir un utilisateur dévolu au démon en question. Ce qui est pénible. (2) de mettre la socket dans /tmp. Ce qui est moche.
Pourquoi? Il me semble que /tmp est tout indiqué pour des trucs temporaires
Et ~/.myprog.sock ou ~/.myprog/sock pour un truc lancé par un utilisateur pour un utilisateur.
qui a dit que je vais faire un programme utilisateur ? ou temporaire ? le but est d'écrire un démon qui va servir dans une queue de mail. -- ·O· Pierre Habouzit ··O OOO http://www.madism.org
Stephane Chazelas wrote:
2005-11-21, 23:11(+01), Pierre Habouzit:
Nicolas George wrote:
Pierre Habouzit wrote in message
<43822fac$0$4304$626a54ce@news.free.fr>:
le but est d'éviter d'avoir à créer une socket unix avec les
désagréables besoin de lancer le programme en root si on veut avoir la
socket dans /var/run/$(myprog).sock.
Il suffit de ne pas mettre la socket dans ce répertoire-là.
Ce qui demande alors (au choix) :
(1) d'avoir un utilisateur dévolu au démon en question. Ce qui est
pénible. (2) de mettre la socket dans /tmp. Ce qui est moche.
Pourquoi? Il me semble que /tmp est tout indiqué pour des trucs
temporaires
Et ~/.myprog.sock ou ~/.myprog/sock pour un truc lancé par un
utilisateur pour un utilisateur.
qui a dit que je vais faire un programme utilisateur ? ou temporaire ? le
but est d'écrire un démon qui va servir dans une queue de mail.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
Pierre Habouzit wrote in message <43822fac$0$4304$:
le but est d'éviter d'avoir à créer une socket unix avec les désagréables besoin de lancer le programme en root si on veut avoir la socket dans /var/run/$(myprog).sock.
Il suffit de ne pas mettre la socket dans ce répertoire-là.
Ce qui demande alors (au choix) : (1) d'avoir un utilisateur dévolu au démon en question. Ce qui est pénible. (2) de mettre la socket dans /tmp. Ce qui est moche.
Pourquoi? Il me semble que /tmp est tout indiqué pour des trucs temporaires
Et ~/.myprog.sock ou ~/.myprog/sock pour un truc lancé par un utilisateur pour un utilisateur.
qui a dit que je vais faire un programme utilisateur ? ou temporaire ? le but est d'écrire un démon qui va servir dans une queue de mail. -- ·O· Pierre Habouzit ··O OOO http://www.madism.org
TiChou
Dans le message <news:4382e402$0$21683$, *Pierre Habouzit* tapota sur f.c.o.unix :
Stephane Chazelas wrote:
Nicolas George wrote:
socket dans /var/run/$(myprog).sock. Il suffit de ne pas mettre la socket dans ce répertoire-là.
Par exemple /var/run/myprog/myprog.sock, comme c'est le cas de plusieurs services tournant sous un uid différent de 0 comme par exemple mysqld.
Ce qui demande alors (au choix) : (1) d'avoir un utilisateur dévolu au démon en question. Ce qui est pénible. (2) de mettre la socket dans /tmp. Ce qui est moche.
Pourquoi? Il me semble que /tmp est tout indiqué pour des trucs temporaires
Oui, si aucun répertoire de travail n'est disponible pour le programme en question, pourquoi est-ce moche de se placer dans /tmp ? Vous n'avez pas répondu.
Et ~/.myprog.sock ou ~/.myprog/sock pour un truc lancé par un utilisateur pour un utilisateur.
qui a dit que je vais faire un programme utilisateur ?
Un programme tourne forcément sous un uid auquel lui est en principe associé un nom d'utilisateur et donc un répertoire de travail. Donc je m'interroge : pourquoi la solution du ~/.myprog.sock ne conviendrait-elle pas ?
le but est d'écrire un démon qui va servir dans une queue de mail.
Donc avec un uid fixe, non ? Si oui, là pareil, pourquoi la solution du /var/{lib,run}/daemon/daemon.sock ne convient pas ?
Sinon, si le programme est amené à être lancé sous différents uid et donc poser des problèmes de permissions, n'est-il pas au moins possible qu'il soit lancé avec le même gid ?
-- TiChou
Dans le message <news:4382e402$0$21683$626a54ce@news.free.fr>,
*Pierre Habouzit* tapota sur f.c.o.unix :
Stephane Chazelas wrote:
Nicolas George wrote:
socket dans /var/run/$(myprog).sock.
Il suffit de ne pas mettre la socket dans ce répertoire-là.
Par exemple /var/run/myprog/myprog.sock, comme c'est le cas de plusieurs
services tournant sous un uid différent de 0 comme par exemple mysqld.
Ce qui demande alors (au choix) :
(1) d'avoir un utilisateur dévolu au démon en question. Ce qui est
pénible.
(2) de mettre la socket dans /tmp. Ce qui est moche.
Pourquoi? Il me semble que /tmp est tout indiqué pour des trucs
temporaires
Oui, si aucun répertoire de travail n'est disponible pour le programme en
question, pourquoi est-ce moche de se placer dans /tmp ? Vous n'avez pas
répondu.
Et ~/.myprog.sock ou ~/.myprog/sock pour un truc lancé par un
utilisateur pour un utilisateur.
qui a dit que je vais faire un programme utilisateur ?
Un programme tourne forcément sous un uid auquel lui est en principe associé
un nom d'utilisateur et donc un répertoire de travail.
Donc je m'interroge : pourquoi la solution du ~/.myprog.sock ne
conviendrait-elle pas ?
le but est d'écrire un démon qui va servir dans une queue de mail.
Donc avec un uid fixe, non ? Si oui, là pareil, pourquoi la solution du
/var/{lib,run}/daemon/daemon.sock ne convient pas ?
Sinon, si le programme est amené à être lancé sous différents uid et donc
poser des problèmes de permissions, n'est-il pas au moins possible qu'il
soit lancé avec le même gid ?
Dans le message <news:4382e402$0$21683$, *Pierre Habouzit* tapota sur f.c.o.unix :
Stephane Chazelas wrote:
Nicolas George wrote:
socket dans /var/run/$(myprog).sock. Il suffit de ne pas mettre la socket dans ce répertoire-là.
Par exemple /var/run/myprog/myprog.sock, comme c'est le cas de plusieurs services tournant sous un uid différent de 0 comme par exemple mysqld.
Ce qui demande alors (au choix) : (1) d'avoir un utilisateur dévolu au démon en question. Ce qui est pénible. (2) de mettre la socket dans /tmp. Ce qui est moche.
Pourquoi? Il me semble que /tmp est tout indiqué pour des trucs temporaires
Oui, si aucun répertoire de travail n'est disponible pour le programme en question, pourquoi est-ce moche de se placer dans /tmp ? Vous n'avez pas répondu.
Et ~/.myprog.sock ou ~/.myprog/sock pour un truc lancé par un utilisateur pour un utilisateur.
qui a dit que je vais faire un programme utilisateur ?
Un programme tourne forcément sous un uid auquel lui est en principe associé un nom d'utilisateur et donc un répertoire de travail. Donc je m'interroge : pourquoi la solution du ~/.myprog.sock ne conviendrait-elle pas ?
le but est d'écrire un démon qui va servir dans une queue de mail.
Donc avec un uid fixe, non ? Si oui, là pareil, pourquoi la solution du /var/{lib,run}/daemon/daemon.sock ne convient pas ?
Sinon, si le programme est amené à être lancé sous différents uid et donc poser des problèmes de permissions, n'est-il pas au moins possible qu'il soit lancé avec le même gid ?
-- TiChou
Pierre Habouzit
Par exemple /var/run/myprog/myprog.sock, comme c'est le cas de plusieurs services tournant sous un uid différent de 0 comme par exemple mysqld.
ce qui demande soit de préinstaller un répertoire avec les bons droits sur myprog, soit que le programme soit lancé en root pour créer sa socket.
Ce qui demande alors (au choix) : (1) d'avoir un utilisateur dévolu au démon en question. Ce qui est pénible. (2) de mettre la socket dans /tmp. Ce qui est moche.
Pourquoi? Il me semble que /tmp est tout indiqué pour des trucs temporaires
Oui, si aucun répertoire de travail n'est disponible pour le programme en question, pourquoi est-ce moche de se placer dans /tmp ? Vous n'avez pas répondu.
parce que tmp peut être plein (l'antivirus qui fait n'importe quoi par exemple, c'est du vécu) et que donc à cause de ca le démon peut ne pas se relancer. Sans parler du nombre impressionnant d'attaques qui existent pour DDoSer des systemes en remplissant leur /tmp.
Et ~/.myprog.sock ou ~/.myprog/sock pour un truc lancé par un utilisateur pour un utilisateur.
qui a dit que je vais faire un programme utilisateur ?
Un programme tourne forcément sous un uid auquel lui est en principe associé un nom d'utilisateur et donc un répertoire de travail. Donc je m'interroge : pourquoi la solution du ~/.myprog.sock ne conviendrait-elle pas ?
faux. les répertoires de travails n'existent pas toujours. Surtout pour un démon qui tourne en nobody/nogroup, sur ma debian, nobody a /nonexistent comme home dir.. je vais aller loin si je met quoi que ce soit dans ~/.myprog.sock ;)
le but est d'écrire un démon qui va servir dans une queue de mail.
Donc avec un uid fixe, non ? Si oui, là pareil, pourquoi la solution du /var/{lib,run}/daemon/daemon.sock ne convient pas ?
parce que je préfèrerais un petit démon dont l'install se réduit à le lancer.
Je trouve particulièrement désagréable que l'écriture du moindre démon demande d'avoir au préalable des installations dans /var/run, avec les bons droits, etc etc.
J'aimerais me limiter au strict minimum : un script d'init, un fichier de conf dans /etc et un démon dans /usr/sbin. Le reste ne fait qu'augmenter les chances de voir le démon planter pour des raisons stupides. C'est un démon qui va être un passage obligé de la chaine de mail, et qui donc ne peut pas se permettre de dépendre de trop de paramètres externes.
Mais bon, je pense que je vais me débrouiller sur ce truc. -- ·O· Pierre Habouzit ··O OOO http://www.madism.org
Par exemple /var/run/myprog/myprog.sock, comme c'est le cas de plusieurs
services tournant sous un uid différent de 0 comme par exemple mysqld.
ce qui demande soit de préinstaller un répertoire avec les bons droits sur
myprog, soit que le programme soit lancé en root pour créer sa socket.
Ce qui demande alors (au choix) :
(1) d'avoir un utilisateur dévolu au démon en question. Ce qui est
pénible.
(2) de mettre la socket dans /tmp. Ce qui est moche.
Pourquoi? Il me semble que /tmp est tout indiqué pour des trucs
temporaires
Oui, si aucun répertoire de travail n'est disponible pour le programme en
question, pourquoi est-ce moche de se placer dans /tmp ? Vous n'avez pas
répondu.
parce que tmp peut être plein (l'antivirus qui fait n'importe quoi par
exemple, c'est du vécu) et que donc à cause de ca le démon peut ne pas se
relancer. Sans parler du nombre impressionnant d'attaques qui existent pour
DDoSer des systemes en remplissant leur /tmp.
Et ~/.myprog.sock ou ~/.myprog/sock pour un truc lancé par un
utilisateur pour un utilisateur.
qui a dit que je vais faire un programme utilisateur ?
Un programme tourne forcément sous un uid auquel lui est en principe
associé un nom d'utilisateur et donc un répertoire de travail.
Donc je m'interroge : pourquoi la solution du ~/.myprog.sock ne
conviendrait-elle pas ?
faux. les répertoires de travails n'existent pas toujours. Surtout pour un
démon qui tourne en nobody/nogroup, sur ma debian, nobody a /nonexistent
comme home dir.. je vais aller loin si je met quoi que ce soit dans
~/.myprog.sock ;)
le but est d'écrire un démon qui va servir dans une queue de mail.
Donc avec un uid fixe, non ? Si oui, là pareil, pourquoi la solution du
/var/{lib,run}/daemon/daemon.sock ne convient pas ?
parce que je préfèrerais un petit démon dont l'install se réduit à le
lancer.
Je trouve particulièrement désagréable que l'écriture du moindre démon
demande d'avoir au préalable des installations dans /var/run, avec les bons
droits, etc etc.
J'aimerais me limiter au strict minimum : un script d'init, un fichier de
conf dans /etc et un démon dans /usr/sbin. Le reste ne fait qu'augmenter
les chances de voir le démon planter pour des raisons stupides. C'est un
démon qui va être un passage obligé de la chaine de mail, et qui donc ne
peut pas se permettre de dépendre de trop de paramètres externes.
Mais bon, je pense que je vais me débrouiller sur ce truc.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
Par exemple /var/run/myprog/myprog.sock, comme c'est le cas de plusieurs services tournant sous un uid différent de 0 comme par exemple mysqld.
ce qui demande soit de préinstaller un répertoire avec les bons droits sur myprog, soit que le programme soit lancé en root pour créer sa socket.
Ce qui demande alors (au choix) : (1) d'avoir un utilisateur dévolu au démon en question. Ce qui est pénible. (2) de mettre la socket dans /tmp. Ce qui est moche.
Pourquoi? Il me semble que /tmp est tout indiqué pour des trucs temporaires
Oui, si aucun répertoire de travail n'est disponible pour le programme en question, pourquoi est-ce moche de se placer dans /tmp ? Vous n'avez pas répondu.
parce que tmp peut être plein (l'antivirus qui fait n'importe quoi par exemple, c'est du vécu) et que donc à cause de ca le démon peut ne pas se relancer. Sans parler du nombre impressionnant d'attaques qui existent pour DDoSer des systemes en remplissant leur /tmp.
Et ~/.myprog.sock ou ~/.myprog/sock pour un truc lancé par un utilisateur pour un utilisateur.
qui a dit que je vais faire un programme utilisateur ?
Un programme tourne forcément sous un uid auquel lui est en principe associé un nom d'utilisateur et donc un répertoire de travail. Donc je m'interroge : pourquoi la solution du ~/.myprog.sock ne conviendrait-elle pas ?
faux. les répertoires de travails n'existent pas toujours. Surtout pour un démon qui tourne en nobody/nogroup, sur ma debian, nobody a /nonexistent comme home dir.. je vais aller loin si je met quoi que ce soit dans ~/.myprog.sock ;)
le but est d'écrire un démon qui va servir dans une queue de mail.
Donc avec un uid fixe, non ? Si oui, là pareil, pourquoi la solution du /var/{lib,run}/daemon/daemon.sock ne convient pas ?
parce que je préfèrerais un petit démon dont l'install se réduit à le lancer.
Je trouve particulièrement désagréable que l'écriture du moindre démon demande d'avoir au préalable des installations dans /var/run, avec les bons droits, etc etc.
J'aimerais me limiter au strict minimum : un script d'init, un fichier de conf dans /etc et un démon dans /usr/sbin. Le reste ne fait qu'augmenter les chances de voir le démon planter pour des raisons stupides. C'est un démon qui va être un passage obligé de la chaine de mail, et qui donc ne peut pas se permettre de dépendre de trop de paramètres externes.
Mais bon, je pense que je vais me débrouiller sur ce truc. -- ·O· Pierre Habouzit ··O OOO http://www.madism.org
Bob qui Trolle
Pierre Habouzit wrote:
Nicolas George wrote:
Ce qui demande alors (au choix) : (1) d'avoir un utilisateur dévolu au démon en question. Ce qui est pénible. (2) de mettre la socket dans /tmp. Ce qui est moche.
à mon avis, la bonne grille de lecture est de se dire que :
- Si tu dois créer des soquettes unix, il faut les mettre là où tu estimes qu'il faut créer tes fichiers temporaires. - Si tu n'as pas vocation à créer de fichiers temporaires, alors, soi t tu dois créer un répertoire ad-hoc (/var/spool....), soit il faut te passer de soquettes unix. - Si tu n'as pas vocation à créer de soquettes Unix et qu'IPC n'est p as un choix envisageable, tu dois inventer quelque chose si tu ne veux pas dépendre d'un protocole de communication entre systèmes non nécessairement présent sauf contraintes spécifiques à ton cas par ticulier.
Wenema s'était, en son temps, posé ce problème : lire sa réflexio n et ses conclusions peut toujours être utile : http://www.postfix.org/OVERVIEW.html
Pierre Habouzit wrote:
Nicolas George wrote:
Ce qui demande alors (au choix) :
(1) d'avoir un utilisateur dévolu au démon en question. Ce qui est pénible.
(2) de mettre la socket dans /tmp. Ce qui est moche.
à mon avis, la bonne grille de lecture est de se dire que :
- Si tu dois créer des soquettes unix, il faut les mettre là où tu
estimes qu'il faut créer tes fichiers temporaires.
- Si tu n'as pas vocation à créer de fichiers temporaires, alors, soi t
tu dois créer un répertoire ad-hoc (/var/spool....), soit il faut te
passer de soquettes unix.
- Si tu n'as pas vocation à créer de soquettes Unix et qu'IPC n'est p as
un choix envisageable, tu dois inventer quelque chose si tu ne veux pas
dépendre d'un protocole de communication entre systèmes non
nécessairement présent sauf contraintes spécifiques à ton cas par ticulier.
Wenema s'était, en son temps, posé ce problème : lire sa réflexio n et
ses conclusions peut toujours être utile :
http://www.postfix.org/OVERVIEW.html
Ce qui demande alors (au choix) : (1) d'avoir un utilisateur dévolu au démon en question. Ce qui est pénible. (2) de mettre la socket dans /tmp. Ce qui est moche.
à mon avis, la bonne grille de lecture est de se dire que :
- Si tu dois créer des soquettes unix, il faut les mettre là où tu estimes qu'il faut créer tes fichiers temporaires. - Si tu n'as pas vocation à créer de fichiers temporaires, alors, soi t tu dois créer un répertoire ad-hoc (/var/spool....), soit il faut te passer de soquettes unix. - Si tu n'as pas vocation à créer de soquettes Unix et qu'IPC n'est p as un choix envisageable, tu dois inventer quelque chose si tu ne veux pas dépendre d'un protocole de communication entre systèmes non nécessairement présent sauf contraintes spécifiques à ton cas par ticulier.
Wenema s'était, en son temps, posé ce problème : lire sa réflexio n et ses conclusions peut toujours être utile : http://www.postfix.org/OVERVIEW.html
DINH Viêt Hoà
Il est bien connu que les sockets UDP ne sont pas fiables sur un brin physique. Mais je me demandais ce qu'il en était de sockets UDP sur le loopback. Est il possible sur certains Unix (et sur linux/*bsd en particulier) de perdre des paquets UDP ?
Ou bien est ce que comme le bon sens le suppose les sockets UDP sur localhost sont fiables ?
non : s'il y a un surplus de paquets en attente, ils seront rejetés.
le but est d'éviter d'avoir à créer une socket unix avec les désagréables besoin de lancer le programme en root si on veut avoir la socket dans /var/run/$(myprog).sock.
Si tu es maître de la machine et du programme, pourquoi ne donnes-tu pas les autorisations à ton programme sur /var/run/[bidule] ?
surtout pour "jouer" un protocole où il y a un envoi puis une réception de message, c'est un peu exagéré de sortir un mode connecté pour ca.
En fait, la majorités des protocoles font un envoi puis réception de message.
-- DINH V. Hoa,
"Paraît-il que c'est ce que recherchent la majorité des djeunz. Il n'y a plus aucun attrait pour les métiers scientifiques ni techniques. Ils veulent être chanteur, acteur ou fonctionnaire. C'est désépérant..." -- Emmanuel Delahaye
Il est bien connu que les sockets UDP ne sont pas fiables sur un brin
physique. Mais je me demandais ce qu'il en était de sockets UDP sur le
loopback. Est il possible sur certains Unix (et sur linux/*bsd en
particulier) de perdre des paquets UDP ?
Ou bien est ce que comme le bon sens le suppose les sockets UDP sur
localhost sont fiables ?
non : s'il y a un surplus de paquets en attente, ils seront rejetés.
le but est d'éviter d'avoir à créer une socket unix avec les désagréables
besoin de lancer le programme en root si on veut avoir la socket
dans /var/run/$(myprog).sock.
Si tu es maître de la machine et du programme, pourquoi ne donnes-tu pas
les autorisations à ton programme sur /var/run/[bidule] ?
surtout pour "jouer" un protocole où il y a
un envoi puis une réception de message, c'est un peu exagéré de sortir un
mode connecté pour ca.
En fait, la majorités des protocoles font un envoi puis réception de
message.
--
DINH V. Hoa,
"Paraît-il que c'est ce que recherchent la majorité des djeunz. Il n'y a plus
aucun attrait pour les métiers scientifiques ni techniques. Ils veulent être
chanteur, acteur ou fonctionnaire. C'est désépérant..." -- Emmanuel Delahaye
Il est bien connu que les sockets UDP ne sont pas fiables sur un brin physique. Mais je me demandais ce qu'il en était de sockets UDP sur le loopback. Est il possible sur certains Unix (et sur linux/*bsd en particulier) de perdre des paquets UDP ?
Ou bien est ce que comme le bon sens le suppose les sockets UDP sur localhost sont fiables ?
non : s'il y a un surplus de paquets en attente, ils seront rejetés.
le but est d'éviter d'avoir à créer une socket unix avec les désagréables besoin de lancer le programme en root si on veut avoir la socket dans /var/run/$(myprog).sock.
Si tu es maître de la machine et du programme, pourquoi ne donnes-tu pas les autorisations à ton programme sur /var/run/[bidule] ?
surtout pour "jouer" un protocole où il y a un envoi puis une réception de message, c'est un peu exagéré de sortir un mode connecté pour ca.
En fait, la majorités des protocoles font un envoi puis réception de message.
-- DINH V. Hoa,
"Paraît-il que c'est ce que recherchent la majorité des djeunz. Il n'y a plus aucun attrait pour les métiers scientifiques ni techniques. Ils veulent être chanteur, acteur ou fonctionnaire. C'est désépérant..." -- Emmanuel Delahaye
Thierry Boudet
On 2005-11-23, DINH Viêt Hoà wrote:
Ou bien est ce que comme le bon sens le suppose les sockets UDP sur localhost sont fiables ?
non : s'il y a un surplus de paquets en attente, ils seront rejetés.
Euh, rejetes, ou silencieusement perdus ?
-- Want to see nacked teens offline? http://www.w3schools.com/downloadwww.htm
On 2005-11-23, DINH Viêt Hoà <dinh.viet.hoa@free.fr> wrote:
Ou bien est ce que comme le bon sens le suppose les sockets UDP sur
localhost sont fiables ?
non : s'il y a un surplus de paquets en attente, ils seront rejetés.
Euh, rejetes, ou silencieusement perdus ?
--
Want to see nacked teens offline? http://www.w3schools.com/downloadwww.htm
