Spécification de l'interface Socket
Le
David Marec
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.
--
www.freebsd.org
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.
--
www.freebsd.org
Poser une question
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!
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.
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.
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
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.
Optimiste, va... en asynchrone, c'est même pas dit qu'elle existe!
Faut le temps de traverser Internet et de revenir...
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.