Salut,
 
Je développe un logiciel (avec C++ Builder) de réception de messages d'alarmes. Mon soft est serveur TCP/IP et écoute un ou plusieurs ports. Avec un équipement d'un constructeur, j'ai des problèmes de connexions : il faut environ une minute pour qu'un des équipements se reconnecte après une déconnexion.
 
Les traces Wireshark montrent - en caractères bien rouges - que ces équipements réutilisent le même numéro de port source pour toutes les connexions [TCP Port numbers reused]. Ceci est contraire aux recommandations (voir RFC 1323, annexes B.2, http://www.ietf.org/rfc/rfc1323.txt) : "Applications built upon TCP that close one connection and open a new one (e.g., an FTP data transfer connection using Stream mode) must choose a new socket pair each time.".    
Je pense que les problèmes viennent de là. Ca marche bien avec d'autres systèmes qui changent leur numéro de port source à chaque connexion.
 
Bref, je cherche s'il est possible de forcer le numéro de port source à l'ouverture d'une connexion TCP/IP client. Tout ça pour tenter, avec un logiciel de test, de reproduire ces problèmes de connexions. Je n'ai pas trouvé comment faire, ni dans les fonctions de type BSD (socket, bind, connect), ni dans les fonctions de l'API Win32 : WSAxxx.  
 
Quelqu'un connaîtrait-il la fonction ou le paramètre magique ?    
Quant à ouvrir un socket en mode RAW...      Je suis pas très chaud pour me retaper toute la pile TCP !
 

Hmm, ça ressemble à un problème de connexion en TIME_WAIT. As-tu essayé d'utiliser l'option SO_REUSEADDR sur la socket ?

Merci pour l'idée. C'est sans doute un problème de TIME_WAIT dans les routeurs entre les deux bouts, sur le PC cible, je ne vois même pas arriver les trames [SYN].
Pour le SO_REUSEADDR, il me semble que cette option permet de lier un socket à une adresse+port cible déjà en cours de connexion. Je ne pense pas que ça conserve le port source après déco/reco...
Bon, faut que j'essaye ça au cas où...

J'ai essayé le paramètre SO_REUSEADDR, comme je pensais il permet - côté serveur - de se (re)mettre en écoute d'un port en état TIME_WAIT.
Et non - côté client - de réutiliser le même port source.
 
Entre temps, j'ai trouvé un petit utilitaire qui permet le faire : FPipe
       http://www.mcafee.com/us/downloads [...] fpipe.aspx
 
C'est un redirecteur de port, il écoute un port, accepte N connexions entrantes et les redirige vers une adresse:port cible... et... il permet de forcer le port source. Y'en a qui sont costauds dans la programmation des sockets...  
 
Maintenant, je bloque encore sur la pile TCP de Windows qui bloque les demandes de connexions sortantes des sockets en TIME_WAIT. J'ai trouvé le paramètre TcpTimedWaitDelay et je l'ai mis au minumum = 30 secondes. Je vais tenter la reproduction du problème des connexions. Si je peux le reproduire, je vais mettre le concepteur des équipements le nez dans leur m...