ENCAPSULATION D'UNE PARTIE DE L'API SOCKET PORTABLE
xterminhate
Messages postés
371
Date d'inscription
dimanche 4 janvier 2004
Statut
Membre
Dernière intervention
23 septembre 2009
-
18 janv. 2004 à 01:54
BlackGoddess Messages postés 338 Date d'inscription jeudi 22 août 2002 Statut Membre Dernière intervention 14 juin 2005 - 19 janv. 2004 à 14:21
BlackGoddess Messages postés 338 Date d'inscription jeudi 22 août 2002 Statut Membre Dernière intervention 14 juin 2005 - 19 janv. 2004 à 14:21
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/19475-encapsulation-d-une-partie-de-l-api-socket-portable
https://codes-sources.commentcamarche.net/source/19475-encapsulation-d-une-partie-de-l-api-socket-portable
19 janv. 2004 à 14:21
19 janv. 2004 à 14:20
je fais pas trop de commentaire la dessus pour l'instant, j'en ferais qd je poserais la source. (triple des => source sur le net, rsa => grace a la classe BigInt sur ce site :) )
19 janv. 2004 à 12:13
Cordialement,
Xter.
19 janv. 2004 à 09:31
19 janv. 2004 à 08:29
Penses tout de même à comparer la valeur de retour de send() avec la taille du message à envoyer. Si la valeur de retour est inférieure à la taille du message, alors il faut recommencer l'émission avec ce qui reste à envoyer du message. Ainsi de suite, jusqu'à ce que le message soit complement envoyé...
Merci,
Xter.
19 janv. 2004 à 01:00
Maximum size of a message for message-oriented socket types (for example, SOCK_DGRAM). Has no meaning for stream oriented sockets.
de plus, à l'appel de getsockopt il me dit que la taille maximum est 2^32, valeur stockée dans un unsigned int qui ne peut pas contenir de nombre plus grand.
ansi, apparement ce serait déjà en interne que le message serait fractionné.
18 janv. 2004 à 18:10
merci bcp :)
18 janv. 2004 à 15:53
Il faut distinguer les cas >0 et =0. En effet, =0 signifie que la connexion a été fermée.
Cordialement,
Xter.
18 janv. 2004 à 14:55
On constate trop souvent "des fuites" dans nos abstractions et cela est dommagable. En effet, l'utilisateur de l'abstraction base_sock n'est pas censée connaitre les limitations des fonctions de la librairie socket que tu encapsules (en particulier la fonction send).
D'ailleurs, la couche logicielle plus avancée (que tu programmes) et qui exploite base_sock n'est pas non plus censée connaitre ses limitations. Imagine que tu developpes cette couche logicielle avancée à partir d'une absctration base_sock que tu n'aurais pas programmé....
Donc, pour être une parfaite abstraction, base_sock devrait implementer ce mécanisme de fragmentation.
Bon courage pour la suite !
Cordialement,
Xter.
18 janv. 2004 à 14:29
lorsqu'un processus appelle une fois WSAStartup, les dll réseau sont chargées. puis, lorsqu'on le rappelle une 2eme fois, un compteur interne estr sulement incrémenté. pour les appels a WSACleanup, le compteur interne est décrémenté et lorsqu'il atteint 0 les dll sont déchargées.
par contre tu as peut-etre raison dans le sens ou un appel de WSAStartup va négocier la version entre celle des dll reseau et celle que ton prog demande, et ce n'est pas très optimisé de refaire cette négociation à chaque instanciation.
ensuite, pour les grandes quantités d'informations, il faut bien comprendre que ceci n'est pour l'instant qu'une encapsulation 'basique' de l'api c socket. Je suis en train de développer d'autres classes de dérivant de celle-ci pour supporter un transfert crypté, la fragmentation de paquets comme tu en parle, et faire respecter l'interface istream / ostream standard c++ pour la lecture/ecriture d'un socket.
en tout cas merci de ces remarques :)
18 janv. 2004 à 01:54
J'attendais avec impatience le résultat de ton travail.
Alors voici quelques (petites) remarques pour commencer. Si l'utilisateur manipules plusieurs instances de base_sock, il execute plusieurs fois WSAStart et WSAClean...aucune idée de l'impact mais un vieux flag static pourrait permettre de l'éviter.
D'autre part, si l'utilisateur souhaite exploiter base_sock pour transmettre de grandes quantitiés d'informations, alors il est nécessaire d'implementer un mécanisme de fragmentation dans write() (contenant l'appel de send()). En effet, la taille du buffer à envoyer ne peut pas exceder SO_MAX_MSG_SIZE. Cela doit etre transparent pour l'utilisateur.
A suivre...
Cordialement,
Xter.