SERVER MULTI-CLIENT COMPATIBLE WIN/NUX
mmuller57
Messages postés
174
Date d'inscription
mardi 10 avril 2001
Statut
Membre
Dernière intervention
30 juillet 2003
-
30 juil. 2003 à 00:48
cs_Thaeron Messages postés 202 Date d'inscription vendredi 6 juillet 2001 Statut Membre Dernière intervention 31 octobre 2007 - 27 janv. 2005 à 00:38
cs_Thaeron Messages postés 202 Date d'inscription vendredi 6 juillet 2001 Statut Membre Dernière intervention 31 octobre 2007 - 27 janv. 2005 à 00:38
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/11141-server-multi-client-compatible-win-nux
https://codes-sources.commentcamarche.net/source/11141-server-multi-client-compatible-win-nux
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