je suis =E0 la recherche d'une sp=E9cification ou RFC qui d=E9crive la norme
ou le standard des interfaces manipulant les "socket"=B9 TCP/IP ?
Un tel standard a il =E9t=E9 d=E9fini ?
En particulier, la fonction "Connect" doit elle ,
- comme d=E9crit ici: http://www.freebsd.org/cgi/man.cgi?query=3Dconnect -
retourner un code d'erreur si le serveur n'a pas r=E9pondu =E0 cette
requ=EAte, bien qu'il soit pr=E9sent sur le r=E9seau ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Le Forgeron
Le 02/01/2007 10:58 AM, David Marec nous fit lire :
Bonjour,
je suis à la recherche d'une spécification ou RFC qui décrive la norme ou le standard des interfaces manipulant les "socket"¹ TCP/IP ?
Un tel standard a il été défini ?
En particulier, la fonction "Connect" doit elle , - comme décrit ici: http://www.freebsd.org/cgi/man.cgi?query=connect - retourner un code d'erreur si le serveur n'a pas répondu à cette requête, bien qu'il soit présent sur le réseau ?
¹: voire les sockets elles mêmes.
Il y a beaucoup a apprendre de RFC 3542 (outch!) et 3493 (plus digeste), mais gaffe, ça parle d'IPv6... par rapport à IPv4.
Les sockets sont un standard "de-facto"... ça attache et ça tache. (la structure d'adresse peut avoir des champs en plus ou en moins selon la machine, enfin l'OS... c'est pas drôle.)
L'interface socket n'est que ça, une interface, permettant de manipuler différents protocoles à travers des verbes unifiés (sauf que les adressages sont spécifiques au protocole, ainsi que les options utilisables...qui peuvent aussi changer de nommage selon l'OS...de moins en moins, mais ça arrive.)
déjà, votre connect() est-il synchrone ou asynchrone... A priori synchrone, donc oui, il faudra bien qu'il échoue un jour si TCP n'arrive pas à ouvrir sa connexion. Et la man-page de connect autorise les codes d'erreurs en provenance du protocole, donc à priori, une implémentation a le droit de donner un code spécifique. Ou bien simplement utilisé ETIMEDOUT, ou ENETUNREACH...
La man-page de connect me donne les conformités à SVr4, 4.4BSD et une apparition de connect() en BSD 4.2; avec le bonus que SVr4 ne donnait pas les mêmes erreurs... ça nous rajeunit pas tout ça!
Le 02/01/2007 10:58 AM, David Marec nous fit lire :
Bonjour,
je suis à la recherche d'une spécification ou RFC qui décrive la norme
ou le standard des interfaces manipulant les "socket"¹ TCP/IP ?
Un tel standard a il été défini ?
En particulier, la fonction "Connect" doit elle ,
- comme décrit ici: http://www.freebsd.org/cgi/man.cgi?query=connect -
retourner un code d'erreur si le serveur n'a pas répondu à cette
requête, bien qu'il soit présent sur le réseau ?
¹: voire les sockets elles mêmes.
Il y a beaucoup a apprendre de RFC 3542 (outch!) et 3493 (plus
digeste), mais gaffe, ça parle d'IPv6... par rapport à IPv4.
Les sockets sont un standard "de-facto"... ça attache et ça tache.
(la structure d'adresse peut avoir des champs en plus ou en moins
selon la machine, enfin l'OS... c'est pas drôle.)
L'interface socket n'est que ça, une interface, permettant de
manipuler différents protocoles à travers des verbes unifiés (sauf
que les adressages sont spécifiques au protocole, ainsi que les
options utilisables...qui peuvent aussi changer de nommage selon
l'OS...de moins en moins, mais ça arrive.)
déjà, votre connect() est-il synchrone ou asynchrone...
A priori synchrone, donc oui, il faudra bien qu'il échoue un jour si
TCP n'arrive pas à ouvrir sa connexion. Et la man-page de connect
autorise les codes d'erreurs en provenance du protocole, donc à
priori, une implémentation a le droit de donner un code spécifique.
Ou bien simplement utilisé ETIMEDOUT, ou ENETUNREACH...
La man-page de connect me donne les conformités à SVr4, 4.4BSD et
une apparition de connect() en BSD 4.2; avec le bonus que SVr4 ne
donnait pas les mêmes erreurs...
ça nous rajeunit pas tout ça!
Le 02/01/2007 10:58 AM, David Marec nous fit lire :
Bonjour,
je suis à la recherche d'une spécification ou RFC qui décrive la norme ou le standard des interfaces manipulant les "socket"¹ TCP/IP ?
Un tel standard a il été défini ?
En particulier, la fonction "Connect" doit elle , - comme décrit ici: http://www.freebsd.org/cgi/man.cgi?query=connect - retourner un code d'erreur si le serveur n'a pas répondu à cette requête, bien qu'il soit présent sur le réseau ?
¹: voire les sockets elles mêmes.
Il y a beaucoup a apprendre de RFC 3542 (outch!) et 3493 (plus digeste), mais gaffe, ça parle d'IPv6... par rapport à IPv4.
Les sockets sont un standard "de-facto"... ça attache et ça tache. (la structure d'adresse peut avoir des champs en plus ou en moins selon la machine, enfin l'OS... c'est pas drôle.)
L'interface socket n'est que ça, une interface, permettant de manipuler différents protocoles à travers des verbes unifiés (sauf que les adressages sont spécifiques au protocole, ainsi que les options utilisables...qui peuvent aussi changer de nommage selon l'OS...de moins en moins, mais ça arrive.)
déjà, votre connect() est-il synchrone ou asynchrone... A priori synchrone, donc oui, il faudra bien qu'il échoue un jour si TCP n'arrive pas à ouvrir sa connexion. Et la man-page de connect autorise les codes d'erreurs en provenance du protocole, donc à priori, une implémentation a le droit de donner un code spécifique. Ou bien simplement utilisé ETIMEDOUT, ou ENETUNREACH...
La man-page de connect me donne les conformités à SVr4, 4.4BSD et une apparition de connect() en BSD 4.2; avec le bonus que SVr4 ne donnait pas les mêmes erreurs... ça nous rajeunit pas tout ça!
David Marec
On 5 fév, 22:47, Le Forgeron :
[Spécification interface TCP -- Sockets ] Les sockets sont un standard "de-facto"... ça attache et ça tache.
C'est bien mon souci: j'ai affaire à une impléméntation un peu 'personnelle' de l'interface TCP de la part d'un fournisseur.
[...] déjà, votre connect() est-il synchrone ou asynchrone... A priori synchrone, donc oui, il faudra bien qu'il échoue un jour si TCP n'arrive pas à ouvrir sa connexion. Et la man-page de connect autorise les codes d'erreurs en provenance du protocole, donc à priori, une implémentation a le droit de donner un code spécifique. Ou bien simplement utilisé ETIMEDOUT, ou ENETUNREACH...
La question n'est pas vraiment s'il «peut», mais s'il «doit». Le «connect» que l'on me propose ne me renvoie aucun statut de connexion, d'où mon désarroi, habitué que je suis aux implémentatio ns de type 'BSD' et WinSock.
On 5 fév, 22:47, Le Forgeron <jgrimb...@free.fr> :
[Spécification interface TCP -- Sockets ]
Les sockets sont un standard "de-facto"... ça attache et ça tache.
C'est bien mon souci: j'ai affaire à une impléméntation un peu
'personnelle' de l'interface TCP de la part d'un fournisseur.
[...]
déjà, votre connect() est-il synchrone ou asynchrone...
A priori synchrone, donc oui, il faudra bien qu'il échoue un jour si
TCP n'arrive pas à ouvrir sa connexion. Et la man-page de connect
autorise les codes d'erreurs en provenance du protocole, donc à
priori, une implémentation a le droit de donner un code spécifique.
Ou bien simplement utilisé ETIMEDOUT, ou ENETUNREACH...
La question n'est pas vraiment s'il «peut», mais s'il «doit».
Le «connect» que l'on me propose ne me renvoie aucun statut de
connexion, d'où mon désarroi, habitué que je suis aux implémentatio ns
de type 'BSD' et WinSock.
[Spécification interface TCP -- Sockets ] Les sockets sont un standard "de-facto"... ça attache et ça tache.
C'est bien mon souci: j'ai affaire à une impléméntation un peu 'personnelle' de l'interface TCP de la part d'un fournisseur.
[...] déjà, votre connect() est-il synchrone ou asynchrone... A priori synchrone, donc oui, il faudra bien qu'il échoue un jour si TCP n'arrive pas à ouvrir sa connexion. Et la man-page de connect autorise les codes d'erreurs en provenance du protocole, donc à priori, une implémentation a le droit de donner un code spécifique. Ou bien simplement utilisé ETIMEDOUT, ou ENETUNREACH...
La question n'est pas vraiment s'il «peut», mais s'il «doit». Le «connect» que l'on me propose ne me renvoie aucun statut de connexion, d'où mon désarroi, habitué que je suis aux implémentatio ns de type 'BSD' et WinSock.
David Marec
On 12 fév, 20:11, Patrick Lamaizière :
[Connect()] Je ne pige pas ce que tu veux dire, connect() ne renvoie pas de status : soit ça réussi (valeur 0) soit ça échoue (-1) ou SOCKET_ERROR pour Winsock.
Oui; et c'est un statut, en quelque sorte: la connexion est "ESTABLISHED" ou n'est pas. Dans le cas qui me préoccupe, l'interface qui m'est fournie ne renvoi rien, sinon, que la machine distante existe. Bref, le statut retourné par leur "connect()" ne me renvoie que l'équivalent d'un "ping" ICMP. Ça ne me plait pas trop de devoir faire des select() derrière, puisque c'est la solution que l'on me propose, pour savoir si la connexion est établie ou non.
-- www.diablotins.org
On 12 fév, 20:11, Patrick Lamaizière <adre...@est.invalid> :
[Connect()]
Je ne pige pas ce que tu veux dire, connect() ne renvoie pas de status :
soit ça réussi (valeur 0) soit ça échoue (-1) ou SOCKET_ERROR pour
Winsock.
Oui; et c'est un statut, en quelque sorte: la connexion est
"ESTABLISHED" ou n'est pas.
Dans le cas qui me préoccupe, l'interface qui m'est fournie ne renvoi
rien, sinon, que la machine distante existe.
Bref, le statut retourné par leur "connect()" ne me renvoie que
l'équivalent d'un "ping" ICMP.
Ça ne me plait pas trop de devoir faire des select() derrière, puisque
c'est la solution que l'on me propose, pour savoir si la connexion est
établie ou non.
[Connect()] Je ne pige pas ce que tu veux dire, connect() ne renvoie pas de status : soit ça réussi (valeur 0) soit ça échoue (-1) ou SOCKET_ERROR pour Winsock.
Oui; et c'est un statut, en quelque sorte: la connexion est "ESTABLISHED" ou n'est pas. Dans le cas qui me préoccupe, l'interface qui m'est fournie ne renvoi rien, sinon, que la machine distante existe. Bref, le statut retourné par leur "connect()" ne me renvoie que l'équivalent d'un "ping" ICMP. Ça ne me plait pas trop de devoir faire des select() derrière, puisque c'est la solution que l'on me propose, pour savoir si la connexion est établie ou non.
-- www.diablotins.org
Le Forgeron
Le 02/14/2007 09:03 AM, David Marec nous fit lire :
On 12 fév, 20:11, Patrick Lamaizière :
[Connect()] Je ne pige pas ce que tu veux dire, connect() ne renvoie pas de status : soit ça réussi (valeur 0) soit ça échoue (-1) ou SOCKET_ERROR pour Winsock.
Oui; et c'est un statut, en quelque sorte: la connexion est "ESTABLISHED" ou n'est pas.
Pas toujours... si tu as mis ta socket en asynchrone, ton connect te rend la main immédiatement, et tu seras prévenu plus tard de l'état de la connexion.
Dans le cas qui me préoccupe, l'interface qui m'est fournie ne renvoi rien, sinon, que la machine distante existe.
Optimiste, va... en asynchrone, c'est même pas dit qu'elle existe! Faut le temps de traverser Internet et de revenir...
Bref, le statut retourné par leur "connect()" ne me renvoie que l'équivalent d'un "ping" ICMP. Ça ne me plait pas trop de devoir faire des select() derrière, puisque c'est la solution que l'on me propose, pour savoir si la connexion est établie ou non.
Tu devrais peut-être regarder si tu n'as pas moyen de faire des i/o bloquantes.
Ou d'utiliser des trucs comme getpeername pour récuperer le port du distant... encore que tes zozo sont capables de te le simuler en refilant tes propres demandes.
Le 02/14/2007 09:03 AM, David Marec nous fit lire :
On 12 fév, 20:11, Patrick Lamaizière <adre...@est.invalid> :
[Connect()]
Je ne pige pas ce que tu veux dire, connect() ne renvoie pas de status :
soit ça réussi (valeur 0) soit ça échoue (-1) ou SOCKET_ERROR pour
Winsock.
Oui; et c'est un statut, en quelque sorte: la connexion est
"ESTABLISHED" ou n'est pas.
Pas toujours... si tu as mis ta socket en asynchrone, ton connect te
rend la main immédiatement, et tu seras prévenu plus tard de l'état
de la connexion.
Dans le cas qui me préoccupe, l'interface qui m'est fournie ne renvoi
rien, sinon, que la machine distante existe.
Optimiste, va... en asynchrone, c'est même pas dit qu'elle existe!
Faut le temps de traverser Internet et de revenir...
Bref, le statut retourné par leur "connect()" ne me renvoie que
l'équivalent d'un "ping" ICMP.
Ça ne me plait pas trop de devoir faire des select() derrière, puisque
c'est la solution que l'on me propose, pour savoir si la connexion est
établie ou non.
Tu devrais peut-être regarder si tu n'as pas moyen de faire des i/o
bloquantes.
Ou d'utiliser des trucs comme getpeername pour récuperer le port du
distant... encore que tes zozo sont capables de te le simuler en
refilant tes propres demandes.
Le 02/14/2007 09:03 AM, David Marec nous fit lire :
On 12 fév, 20:11, Patrick Lamaizière :
[Connect()] Je ne pige pas ce que tu veux dire, connect() ne renvoie pas de status : soit ça réussi (valeur 0) soit ça échoue (-1) ou SOCKET_ERROR pour Winsock.
Oui; et c'est un statut, en quelque sorte: la connexion est "ESTABLISHED" ou n'est pas.
Pas toujours... si tu as mis ta socket en asynchrone, ton connect te rend la main immédiatement, et tu seras prévenu plus tard de l'état de la connexion.
Dans le cas qui me préoccupe, l'interface qui m'est fournie ne renvoi rien, sinon, que la machine distante existe.
Optimiste, va... en asynchrone, c'est même pas dit qu'elle existe! Faut le temps de traverser Internet et de revenir...
Bref, le statut retourné par leur "connect()" ne me renvoie que l'équivalent d'un "ping" ICMP. Ça ne me plait pas trop de devoir faire des select() derrière, puisque c'est la solution que l'on me propose, pour savoir si la connexion est établie ou non.
Tu devrais peut-être regarder si tu n'as pas moyen de faire des i/o bloquantes.
Ou d'utiliser des trucs comme getpeername pour récuperer le port du distant... encore que tes zozo sont capables de te le simuler en refilant tes propres demandes.
