> Bah perso moi dans d'autres langages comme VB ou delphi, on peut ecouter sur un port, et accepter la connexion sur un autre.
> Comme ca le port initial reste libre d'ecouter les nouvelles demandes de connexions.
Heeeuuuurrrkkkkk.... Le problème avec les programes comme celui que tu as developpé, c'est que tu ammenes ca dans une boite, on l'installe, et apres l'utilisateur va voir l'administrateur reseau/securité pour lui demander d'ouvrir des ports.
L'admin, generalement assez sympa, il demande (juste comme ça, en passant) : "Bon, il faut que je t'ouvre quels ports ? TCP/UDP ? vers où ? Y a un créneau horaire ?" (Oui, un admin c'est generalement assez parano...)
Et l'utilisateur du sus-dit logiciel qui répond, l'air de rien : "Bah en fait, il faudrait que tu m'ouvres tous les ports TCP > 1024, je ne sais quel port va utiliser mon serveur, c'est à la gueule du client..."
Et bein, moi, je t'assure que si c'est moi l'admin, ton programme, tu peux en changer tout de suite, sans passer par la case lecteur de CD-ROM...
[^] # Re: Broadcast en C
Posté par Bilbo . En réponse au journal Broadcast en C. Évalué à 1.
> Comme ca le port initial reste libre d'ecouter les nouvelles demandes de connexions.
Heeeuuuurrrkkkkk.... Le problème avec les programes comme celui que tu as developpé, c'est que tu ammenes ca dans une boite, on l'installe, et apres l'utilisateur va voir l'administrateur reseau/securité pour lui demander d'ouvrir des ports.
L'admin, generalement assez sympa, il demande (juste comme ça, en passant) : "Bon, il faut que je t'ouvre quels ports ? TCP/UDP ? vers où ? Y a un créneau horaire ?" (Oui, un admin c'est generalement assez parano...)
Et l'utilisateur du sus-dit logiciel qui répond, l'air de rien : "Bah en fait, il faudrait que tu m'ouvres tous les ports TCP > 1024, je ne sais quel port va utiliser mon serveur, c'est à la gueule du client..."
Et bein, moi, je t'assure que si c'est moi l'admin, ton programme, tu peux en changer tout de suite, sans passer par la case lecteur de CD-ROM...