Tout le monde a raison. Cependant, si vous êtes également occupé à tester votre code, votre propre l'application peut toujours "posséder" le socket si elle démarre et s'arrête relativement rapidement. Essayez SO_REUSEADDR comme option de socket :
Que fait exactement SO_REUSEADDR ?
Cette option de socket indique au noyau que même si ce port est occupé (dans l'état TIME_WAIT), continuez et réutilisez-le quand même. S'il est occupé, mais avec un autre état, vous obtiendrez toujours une adresse déjà en erreur d'utilisation. C'est utile si votre serveur a été arrêté, puis redémarré immédiatement alors que les sockets sont toujours actifs sur son port. Vous devez savoir que si des données inattendues arrivent, cela peut perturber votre serveur, mais bien que cela soit possible, ce n'est pas probable.
Il a été souligné que "Une socket est un tuple 5 (proto, adresse locale, port local, adresse distante, port distant). SO_REUSEADDR indique simplement que vous pouvez réutiliser les adresses locales. Le tuple 5 doit toujours être unique!" par Michael Hunter ([email protected]). C'est vrai, et c'est pourquoi il est très peu probable que des données inattendues soient jamais vues par votre serveur. Le danger est qu'un tel tuple 5 flotte toujours sur le net, et pendant qu'il rebondit, une nouvelle connexion du même client, sur le même système, arrive à obtenir le même port distant. Ceci est expliqué par Richard Stevens dans ``2.7 Pleaseexplain the TIME_WAIT state.''.
Vous avez un processus qui utilise déjà ce port. netstat -tulpn permettra de trouver l'ID de processus qui utilise un port particulier.