SERVER HTTP,FTP,IRC,POP3,SMTP,NTP AVEC LE WIZARD POUR LA CONFIGURATION ET LES CLIENT GRAPHIQUE TOUS SOUS LINUX / WINDOWS ( VIA WXWINDOWS ET CYGWIN)

Télécharger le zip

10 août 2004 20:24:57 :

compilation: make linux ( sous linux ) ca va pondre un .bin make cygwin ( sous windows ) ca va pondre un .exe depuis vc++ pour les client sous windows pour faire marcher en dehors de la console cygwin suffit de copier deux dll dans le meme rep que l'exe, cygwin1.dll et cygcygipc-2.dll en ce qui concerne wxWindows sous nux ca chie de temps en temps car les options de compile que wx-config --libs et wx-config --cxxflags renvoie sont pas tjrs bonne , le mieux c editer le makefile ou extraire la commande de compile et l'adapter a votre systeme perso j'utilise une debian 3.0 avec noyau 2.6 maison, g++ et cie en version 3.qqchose et wxGTK v2.4.0 en compilation statique ( pas shared ) et ca compilote tout seul

11 août 2004 15:03:00 :

Explication: Q: pourquoi cygwin ? R: pour permettre la portabilité des prog sous windows sans avoir a tout recoder. Inconveniant: toutes les fonction linux ne sont pas supporté donc parfois le code peu sembler un peu bizarre Q: pourquoi wxWindow ? R: toujours pour un souci de portabilité, en passant par wxWindow, on evite d'ecrire avec les mfc d'un coté, et avec gtk ou autre de l'autre coté Inconveniant: sous linux, le linkage avec les libs de wxWindow est assez hasardeux Q: pourquoi les server en mode console ? R: parce que c souvent comme ca sous nux et ca permet de lancer comme deamon sont bp modif le code Inconveniant: Aucun, si ce n'est de faire raller les obsede du "clic-clic-button" Q: comment faire un deamon ? R: voir cours d'archi :) le principe est simple : on fork -> ca creer un deuxieme processus, on "tue" le pere, le fils est orphelin on fe un nouveau "session leader" et ca se ratache au processus "init" Q: pourquoi defois des processus et d'autre fois des thread ? R: perso , c'est une question de clarté et d'utilité: un thread et un processus on des comportement different ( semaphore/mutex, memoire partagé de base ou non, heritage de certaine variable etc ....) donc suivant les cas d'utilisation on prefere utilise l'un ou l'autre. la encore vo mieux relire ses cours d'architecture systeme :) Q: pourqoi des signaux ? R: cours d'archi :) ex: vous tuer un server, donc fo tuer tous les fils qui trainait pour eviter les zombie ( immmoooooteeeeepppp !!!! ) et faire le menage dans les socket ouverte, bah on fe ca avec les signaux pour dire a tout le monde : "suicide collectif !!" Q: pourquoi defois ca multithread avec un fork et pourquoi d'autre fois non ? R: question de communication entre les processus, ex: le server http ecoute sur le port 80, il recoit une demande de connec, il fork et le fils s'occupe du client pendant que le pere continue d'ecouter, la pas besoin de communiquer entre les client donc le modele avec fork et le bazar est correct. Par contre dans le cas du server IRC c plus cho ! la il ya communication -> donc mise en place de memoire partagé avec des semaphore dans tous les sens ou de pipe ou de socket unix locaux ou je ne c koi encore. pkoi g pas fe ca ? deja paske c casse cou**le et ensuite paske cygwin a quelque prob avec les ipc ( inter processus communication ), tous n'est pas supporte ou de maniere assez strange.donc pas de memoire partage ni de multithread. Comment faire alors pour que le prog ne bloque pas sur un seul client ? LES SOCKET NON-BLOQUANT !!! le principe est simple: on gere un POOL de socket que l'on va observer un certain temps tour a tour grace au macro FD_ISSET FD_* etc ... et a la fonction select qui permet de mettre en premier plan un descripteur sur lekel il se passe qqchose ( pour rapelle sous nux, une socket EST un descripteur de fichier ) voila , on peu gerer un pool de client presque simultanement sans creer de thread ou proccessus. Le hic, c'est la monté en charge lorsque que l'on utilise ce modele de server, c tres gourmand en ressource !! ( la encore cf cours d'architecture systeme pour plus d'explication ) Q: le server ntp n'est pas multithreader ? R: paske sinon ca risque de creer des ecart de qq nanoseconde ( c un server de temps, fo etre precis :) ) pour les details -> voir comment marche le scheduler de nux lors de l'execution de process concurrent....... Bon d'accord c pas la vrai raison ( meme si effectivement ca peut arriver ) c surtout que jav la fleme de le faire correctment , un packet ntp fe dans les 48 octet, on est en mode udp, donc du non connecté, bref ca rique pas de bloquer tres longtemps lors d'une connection cliente.