oh j'ai compris le proble ci dessus: le flash n'execute le socket que si le serveur est sur le meme hote quele flash ... bon
ca veut dire qu'il faut que je compile sur le dédié, je pense que ca pourra intéresser d'autres personnes:
pour compiler ce programme sous nux (niveau débutant hein ...) et en ayant fait la modif (suppression du delay.h) comment faire ?
faut il faire un makefile ?
excusez si c'est un peu hors sujet que voulez vous, un sujet en amène un autre :o)
cs_Lewil
Messages postés15Date d'inscriptionlundi 18 octobre 2004StatutMembreDernière intervention19 octobre 2005 26 janv. 2005 à 22:13
merci Anacr0x !
et merci aussi pour le bout de code d'envoi aux clients
nikel ;)
c'est pour faire un socket Xml flash
me reste a comprendre pourquoi quand j'exécute le flash en local ca marche et quand je l'éxécute a partir d'un serveur dédié ca veut po :x mais ceci est une autre histoire !
Anacr0x
Messages postés515Date d'inscriptiondimanche 25 mai 2003StatutMembreDernière intervention27 avril 20062 26 janv. 2005 à 21:28
cs_Lewil
Messages postés15Date d'inscriptionlundi 18 octobre 2004StatutMembreDernière intervention19 octobre 2005 26 janv. 2005 à 21:20
coucou et bravo merci pour cette source
question linuxienne, est ce pour le usleep c'est:
#define delay(x) usleep( x * 1000 )
ou
#define delay(x) usleep( x )
cs_Thaeron
Messages postés202Date d'inscriptionvendredi 6 juillet 2001StatutMembreDernière intervention31 octobre 2007 3 janv. 2005 à 22:16
Oups effectivement tu as raison, désolé j'ai refais le code de tête un peu à la va-vite je dois dire.
c'est evidement:
#define delay(x) Sleep(x)
Merci bien Anacr0x car je crois avoir refais la meme erreur sur mon nouveau bot IRC (ce qui expliquerai les temps de lantence important).
Anacr0x
Messages postés515Date d'inscriptiondimanche 25 mai 2003StatutMembreDernière intervention27 avril 20062 3 janv. 2005 à 21:45
Je ne pense pas que ca soit correct, Sleep est en milliseconde et usleep en microseconde. Si tu multiplis les dex valeurs par mille, tu n'obtient pas la même durée d'attente...
cs_Thaeron
Messages postés202Date d'inscriptionvendredi 6 juillet 2001StatutMembreDernière intervention31 octobre 2007 3 janv. 2005 à 21:31
Merci, evitez d'utiliser l'header delay.h j'ai découvert récement que la fonction était buggé, à la place mettez:
#include <time.h>
#ifdef WIN32
#define delay(x) Sleep(x * 1000)
#else
#define delay(x) usleep(x * 1000)
#endif
meech
Messages postés209Date d'inscriptionvendredi 11 avril 2003StatutMembreDernière intervention14 août 2007 3 janv. 2005 à 16:42
Franchement, du bon boulot.
cs_Thaeron
Messages postés202Date d'inscriptionvendredi 6 juillet 2001StatutMembreDernière intervention31 octobre 2007 15 sept. 2004 à 19:34
J'ai completement oublié de mettre le code a jour, j'ai tenté 2 techniques: celle qui consiste a packer 64 fd mais j'ai pas réussi, j'ai donc mis un fd par user.
Je vais mettre à jour des ce soir.
Merci de vos commentaires =)
cs_mafioso
Messages postés1Date d'inscriptionlundi 27 janvier 2003StatutMembreDernière intervention15 septembre 2004 15 sept. 2004 à 15:27
excellent travail merci
j'avais justement besoin de ce genre de source
pour mon travail
merci beaucoup
a++
BlackGoddess
Messages postés338Date d'inscriptionjeudi 22 août 2002StatutMembreDernière intervention14 juin 2005 26 mai 2004 à 14:13
oui, je serais curieux de voir comment tu fais le partage du temps pour chaque select de chaque fd_set
pour la gestion des groupes, je me demande aussi si tu vas garder tes groupes entre les appels ou recréer les groupes a chaque fois
cs_Thaeron
Messages postés202Date d'inscriptionvendredi 6 juillet 2001StatutMembreDernière intervention31 octobre 2007 25 mai 2004 à 21:03
J'ai encore fais un test et sous linux aussi ça bloque, mais vers 1024 sockets.
Je pense que je vais faire un découpage en plusieurs FD avec une liste chainée de FD qui sera traitée de la meme maniere que pour le FD unique (avec un découpage à 64 sockets pour windoz et 1024 sockets pour Linux).
J'essairai de mettre à jour le source sous peu.
cs_Thaeron
Messages postés202Date d'inscriptionvendredi 6 juillet 2001StatutMembreDernière intervention31 octobre 2007 25 mai 2004 à 20:57
Je viens de tester et tu as raison, sous windoz c'est bien limité à 64 flux, (j'ai connecté un nombre de clones > 64, une fois tous connecté j'ai envoyé un message avec chacun).
En revanche sous linux aucun probleme ne s'est posé.
Je vais essayer de trouver une solution pour windoz, merci de ta remarque BlackGoddess.
BlackGoddess
Messages postés338Date d'inscriptionjeudi 22 août 2002StatutMembreDernière intervention14 juin 2005 23 mai 2004 à 14:12
des MSDN :
The variable FD_SETSIZE determines the maximum number of descriptors in a set. (The default value of FD_SETSIZE is 64, which can be modified by defining FD_SETSIZE to another value before including Winsock2.h.)
c normal que 500 connexions simultanées fonctionnent, vu que tu a juste a checker le 1er socket, celui qui ecoute ... 500 envois de données de 500 clients differents fonctionnent aussi ?
BlackGoddess
Messages postés338Date d'inscriptionjeudi 22 août 2002StatutMembreDernière intervention14 juin 2005 21 mai 2004 à 10:42
serieux ??? bizarre ca o_O je reteste ce soir sur mon win2000
cs_Thaeron
Messages postés202Date d'inscriptionvendredi 6 juillet 2001StatutMembreDernière intervention31 octobre 2007 21 mai 2004 à 00:51
Heu j'ai pas trop compris ton probleme, vu que j'ai connecté 500 bots sur le server et que ça marche nickel ( sous XP, sous 98 c'est limité a 100 et quelques sockets )
BlackGoddess
Messages postés338Date d'inscriptionjeudi 22 août 2002StatutMembreDernière intervention14 juin 2005 21 mai 2004 à 00:14
sous windows, le nombre max de sockets dans un set est 64, qq1 connaitrait un moyen de contourner cela ? (tout en restant portable)
j'avais pensé faire un set tout les 64 sockets, puis vérifier chaque set (select) a la queue, mais c'est lourd a mettre en place :(
Qw3rT
Messages postés1Date d'inscriptionmardi 21 octobre 2003StatutMembreDernière intervention12 novembre 2003 12 nov. 2003 à 21:26
Salut ! J'ai essayé ton code et comme fyleo j'avais un bug à la ligne if(FD_ISSET(ktmp->sock,&recois)){
J'ai rajouté klist=supprk(klist,ktmp); comme tu l'as proposé et ca fonctionne maintenant #1 !
Ca faisait un petit bout de temps que je cherchais le problème alors ca serait p-e bien de mettre ton code à jours pour ne pas faire subir ça aux autres! ;)
Bon travail !
fyleo
Messages postés11Date d'inscriptionjeudi 6 juin 2002StatutMembreDernière intervention20 novembre 2003 4 oct. 2003 à 23:22
merci Thaeron ca marche impec maintenant très bon travaille et tu t'y connais vraiment bien franchement bravo!!!!!
cs_Thaeron
Messages postés202Date d'inscriptionvendredi 6 juillet 2001StatutMembreDernière intervention31 octobre 2007 4 oct. 2003 à 17:23
Merci ;o)
"if(FD_ISSET(ktmp->sock,&recois)){" ne vérifie pas si le client est déconnecté, cette fonction vérifie si le flux a changer (dc si il ya des infos), lorsque un client déco on recoi en boucle une chaine vide (taille 0) c'est dc le "if(taille 0) || (taille == -1)" qui detecte si le client est connecté ou pas.
Pour ton probleme, a vrai dire je ne sais pas, il se pourrai bien que ça vienne de visual studio 2003 .net (pour ma part j'utilise GCC).
J'ai pas vraimenet assez de détail pour te dire ce qui pourrai buggé, peut etre que la déconnexion n'est pas détecté (improbable), ou que l'élément de la liste chainée contenant le client déconnecté n'est pas correctement enlevé. Il se peut que la fonction recv renvoi une valeur différente de 0 ou -1, il faudrai que tu test.
Si tu pouvai me donner la nature exact du bug, je pourrai peut etre t'en dire plus.
J'ai réutilisé cette architecture pour un server de messagerie instantané que je code en ce moment et j'ai eu un bug du coté de la déconnexion justement, la solution consiste a rajouté "break;" ou "ktmp=klist;" en dessous de
"klist=supprk(klist,ktmp);"
Si ça ne marche toujours pas, dis le moi et j'essairai de résoudre ce probleme.
Tsh@w
fyleo
Messages postés11Date d'inscriptionjeudi 6 juin 2002StatutMembreDernière intervention20 novembre 2003 1 oct. 2003 à 18:46
bravo pour ta source c très bien penser mais j'ai un problème :
après ke j'ai compliler la source j'ai lancer l'executable (quoi de plus normale ;) et j'ai connecter un client dessus. c la qu'intervient mon pb
lorsque je déconnect un seul des client connectés le programme bug sur : "if(FD_ISSET(ktmp->sock,&recois)){" (lors de la fonction pour vérifié si le client s'est deconnecter)
j'utilise visual studio 2003 .net
et pour compiler j'ai du changer les include et mettre winsock2.h a la place de winsock.h (et la lib qui va avec ce header)
est ce que mon problème viendrais de ça?...
thunderx
Messages postés13Date d'inscriptionmardi 15 avril 2003StatutMembreDernière intervention21 septembre 2006 27 août 2003 à 16:59
:-)
C'est bien de penser aux 2 environnements !
cs_Thaeron
Messages postés202Date d'inscriptionvendredi 6 juillet 2001StatutMembreDernière intervention31 octobre 2007 1 août 2003 à 09:53
Si je donne le source de cette architecture c'est pour qu'elle soit réutilisé, si tu la réutilise je serai empli de fierté et si tu dis que c de moi alors la ça sera le comble du bonheur =D.
Le main est pas fini (il manque l'apel a la fonction qui va gerer les données recues) c'est pour ça que j'ai pas mis de return 0; et de plus vu que c'est une boucle infini le return sera jamais effectué. Mais tu as raison j'aurai du le mettre pour une meilleur compatibilité entre les compilo.
Pour le typedef ... bha c'est la meilleur technique en C que j'ai trouvé pour faire les listes chainé et qui marche sur tout compilo (surtout GCC et sa mouture windows Mingw),sinon "struct client{};" bha ça, ça marche pas (en C++ ça marche mais en C le compilo est pas d'accord).
=)
Anacr0x
Messages postés515Date d'inscriptiondimanche 25 mai 2003StatutMembreDernière intervention27 avril 20062 31 juil. 2003 à 23:08
Par contre pourquoi tu met un "typedef struct _client client;" et puis après tu met ton "struct _client{};"
Tu peu tout simplement faire un "struct client{};" nan ? Pourquoi le typedef ? C pas important mais ca m'intrigue...
Anacr0x
Messages postés515Date d'inscriptiondimanche 25 mai 2003StatutMembreDernière intervention27 avril 20062 31 juil. 2003 à 22:33
Critiqué ? Pourquoi ? Elle est trè bien commenté, sans aucun bug, et bien que j'ai eu du mal avec sa structure, j'ai réussi a comprendre en gros... C'est mon coup de coeur du moment (^_^)
D'ailleur, est-ce ke ca te dérangeré si je métté une source (prochainement ou non) avec ton serveur dedans ? en précisant évidemment que tu est l'auteur...
Toute petite correction : rajoute un return 0; avant la fin du int main(), certain compilateur ne laisseront pas passé ca...
cs_Thaeron
Messages postés202Date d'inscriptionvendredi 6 juillet 2001StatutMembreDernière intervention31 octobre 2007 31 juil. 2003 à 21:15
Je suis content que le source vous plaisent =) j'ai eu peur d'etre violement critiqué =
Pour ceux qui se posent les mm questions que toi Anacr0x (excusez une fois de plus ma façon de coder).
Lorsque des données sont recu d'un client, celui est désigné par ktmp, donc sa socket est ktmp->sock.
Pour fermer l'écoute il faut fermer la socket sd.
=)
Anacr0x
Messages postés515Date d'inscriptiondimanche 25 mai 2003StatutMembreDernière intervention27 avril 20062 31 juil. 2003 à 18:49
Laissez tombé pour mes deux questions, g trouvé comment faire (^_^), jsui tro content...
Anacr0x
Messages postés515Date d'inscriptiondimanche 25 mai 2003StatutMembreDernière intervention27 avril 20062 31 juil. 2003 à 01:24
Vraiment trè bien, g essayé et ca marche sans aucun pb !!!! Par contre, g quelques question (décidemment cette source est bocou trop compliké pour moi) : en immaginant que je souhaitent envoyé un message a tt les client, quel(s) socket(s) dois-je utilisé ?? j'ai essayé avec ktmp->sock, mais ca bug... erreur windows...
Et pui j'ai besoin d'arrété l'écoute sans éteindre le programme totalement, pour cela, je ferme les socket sd et klist->sock mais il semble attendre quelque chose (fonction recv ?) et resté en écoute... comment faire ??
Allé, un 10/10 depuis le tps que j'espere trouvé une source comme ca...
mmuller57
Messages postés174Date d'inscriptionmardi 10 avril 2001StatutMembreDernière intervention30 juillet 20031 30 juil. 2003 à 00:48
27 janv. 2005 à 00:38
servbaze c'est le nom du binaire
et -O3 ça veut dire optimisation de niveau 3 (la meilleure)
26 janv. 2005 à 22:54
ca veut dire qu'il faut que je compile sur le dédié, je pense que ca pourra intéresser d'autres personnes:
pour compiler ce programme sous nux (niveau débutant hein ...) et en ayant fait la modif (suppression du delay.h) comment faire ?
faut il faire un makefile ?
excusez si c'est un peu hors sujet que voulez vous, un sujet en amène un autre :o)
26 janv. 2005 à 22:13
et merci aussi pour le bout de code d'envoi aux clients
nikel ;)
c'est pour faire un socket Xml flash
me reste a comprendre pourquoi quand j'exécute le flash en local ca marche et quand je l'éxécute a partir d'un serveur dédié ca veut po :x mais ceci est une autre histoire !
26 janv. 2005 à 21:28
#ifdef _WIN32
#define delay(ms) Sleep(ms)
#else
#define delay(ms) usleep(ms*1000)
#endif
26 janv. 2005 à 21:20
question linuxienne, est ce pour le usleep c'est:
#define delay(x) usleep( x * 1000 )
ou
#define delay(x) usleep( x )
3 janv. 2005 à 22:16
c'est evidement:
#define delay(x) Sleep(x)
Merci bien Anacr0x car je crois avoir refais la meme erreur sur mon nouveau bot IRC (ce qui expliquerai les temps de lantence important).
3 janv. 2005 à 21:45
3 janv. 2005 à 21:31
#include <time.h>
#ifdef WIN32
#define delay(x) Sleep(x * 1000)
#else
#define delay(x) usleep(x * 1000)
#endif
3 janv. 2005 à 16:42
15 sept. 2004 à 19:34
Je vais mettre à jour des ce soir.
Merci de vos commentaires =)
15 sept. 2004 à 15:27
j'avais justement besoin de ce genre de source
pour mon travail
merci beaucoup
a++
26 mai 2004 à 14:13
pour la gestion des groupes, je me demande aussi si tu vas garder tes groupes entre les appels ou recréer les groupes a chaque fois
25 mai 2004 à 21:03
Je pense que je vais faire un découpage en plusieurs FD avec une liste chainée de FD qui sera traitée de la meme maniere que pour le FD unique (avec un découpage à 64 sockets pour windoz et 1024 sockets pour Linux).
J'essairai de mettre à jour le source sous peu.
25 mai 2004 à 20:57
En revanche sous linux aucun probleme ne s'est posé.
Je vais essayer de trouver une solution pour windoz, merci de ta remarque BlackGoddess.
23 mai 2004 à 14:12
The variable FD_SETSIZE determines the maximum number of descriptors in a set. (The default value of FD_SETSIZE is 64, which can be modified by defining FD_SETSIZE to another value before including Winsock2.h.)
c normal que 500 connexions simultanées fonctionnent, vu que tu a juste a checker le 1er socket, celui qui ecoute ... 500 envois de données de 500 clients differents fonctionnent aussi ?
21 mai 2004 à 10:42
21 mai 2004 à 00:51
21 mai 2004 à 00:14
j'avais pensé faire un set tout les 64 sockets, puis vérifier chaque set (select) a la queue, mais c'est lourd a mettre en place :(
12 nov. 2003 à 21:26
J'ai rajouté klist=supprk(klist,ktmp); comme tu l'as proposé et ca fonctionne maintenant #1 !
Ca faisait un petit bout de temps que je cherchais le problème alors ca serait p-e bien de mettre ton code à jours pour ne pas faire subir ça aux autres! ;)
Bon travail !
4 oct. 2003 à 23:22
4 oct. 2003 à 17:23
"if(FD_ISSET(ktmp->sock,&recois)){" ne vérifie pas si le client est déconnecté, cette fonction vérifie si le flux a changer (dc si il ya des infos), lorsque un client déco on recoi en boucle une chaine vide (taille 0) c'est dc le "if(taille 0) || (taille == -1)" qui detecte si le client est connecté ou pas.
Pour ton probleme, a vrai dire je ne sais pas, il se pourrai bien que ça vienne de visual studio 2003 .net (pour ma part j'utilise GCC).
J'ai pas vraimenet assez de détail pour te dire ce qui pourrai buggé, peut etre que la déconnexion n'est pas détecté (improbable), ou que l'élément de la liste chainée contenant le client déconnecté n'est pas correctement enlevé. Il se peut que la fonction recv renvoi une valeur différente de 0 ou -1, il faudrai que tu test.
Si tu pouvai me donner la nature exact du bug, je pourrai peut etre t'en dire plus.
J'ai réutilisé cette architecture pour un server de messagerie instantané que je code en ce moment et j'ai eu un bug du coté de la déconnexion justement, la solution consiste a rajouté "break;" ou "ktmp=klist;" en dessous de
"klist=supprk(klist,ktmp);"
Si ça ne marche toujours pas, dis le moi et j'essairai de résoudre ce probleme.
Tsh@w
1 oct. 2003 à 18:46
après ke j'ai compliler la source j'ai lancer l'executable (quoi de plus normale ;) et j'ai connecter un client dessus. c la qu'intervient mon pb
lorsque je déconnect un seul des client connectés le programme bug sur : "if(FD_ISSET(ktmp->sock,&recois)){" (lors de la fonction pour vérifié si le client s'est deconnecter)
j'utilise visual studio 2003 .net
et pour compiler j'ai du changer les include et mettre winsock2.h a la place de winsock.h (et la lib qui va avec ce header)
est ce que mon problème viendrais de ça?...
27 août 2003 à 16:59
C'est bien de penser aux 2 environnements !
1 août 2003 à 09:53
Le main est pas fini (il manque l'apel a la fonction qui va gerer les données recues) c'est pour ça que j'ai pas mis de return 0; et de plus vu que c'est une boucle infini le return sera jamais effectué. Mais tu as raison j'aurai du le mettre pour une meilleur compatibilité entre les compilo.
Pour le typedef ... bha c'est la meilleur technique en C que j'ai trouvé pour faire les listes chainé et qui marche sur tout compilo (surtout GCC et sa mouture windows Mingw),sinon "struct client{};" bha ça, ça marche pas (en C++ ça marche mais en C le compilo est pas d'accord).
=)
31 juil. 2003 à 23:08
Tu peu tout simplement faire un "struct client{};" nan ? Pourquoi le typedef ? C pas important mais ca m'intrigue...
31 juil. 2003 à 22:33
D'ailleur, est-ce ke ca te dérangeré si je métté une source (prochainement ou non) avec ton serveur dedans ? en précisant évidemment que tu est l'auteur...
Toute petite correction : rajoute un return 0; avant la fin du int main(), certain compilateur ne laisseront pas passé ca...
31 juil. 2003 à 21:15
Pour ceux qui se posent les mm questions que toi Anacr0x (excusez une fois de plus ma façon de coder).
Lorsque des données sont recu d'un client, celui est désigné par ktmp, donc sa socket est ktmp->sock.
Pour fermer l'écoute il faut fermer la socket sd.
=)
31 juil. 2003 à 18:49
31 juil. 2003 à 01:24
Et pui j'ai besoin d'arrété l'écoute sans éteindre le programme totalement, pour cela, je ferme les socket sd et klist->sock mais il semble attendre quelque chose (fonction recv ?) et resté en écoute... comment faire ??
Allé, un 10/10 depuis le tps que j'espere trouvé une source comme ca...
30 juil. 2003 à 00:48