TcpListener.Start() n'ouvre pas le port

Question

J'ai une classe qui hérite de TcpListener, cette classe Shadows la méthode Start juste pour appeler la base Start() et la base BeginAcceptTcpClient(). De temps en temps, la méthode est appelée mais le port n'est pas ouvert (netstat n'affiche pas le port ouvert).

La classe ressemble à ceci

Public Class ExtendedTcpListener 
    Inherits System.Net.Sockets.TcpListener 

Public Shadows Sub Start() 
    SyncLock (m_stopLock) 
     MyBase.Start() 
     MyBase.BeginAcceptTcpClient(AddressOf Me.CompleteAcceptTcpClient, Me) 
     My.Application.Log.WriteEntry("Extended Tcp Listener started ...", TraceEventType.Verbose) 
    End SyncLock 
End Sub 

Toute idée sur ce qui se passe ou comment déboguer le problème? Comme le Start() est appelé sans exception je m'attendais à trouver le port toujours ouvert (le journal est toujours écrit).

Informations supplémentaires: lorsque la méthode Start fonctionne correctement, elle fonctionne à chaque fois jusqu'à ce que l'application soit redémarrée. Lorsque la méthode Start ne fonctionne pas, elle ne fonctionnera plus tant que l'application ne sera pas redémarrée.

Edit: Il y a aussi une méthode d'arrêt au ExtendedTcpListener:

Public Shadows Sub [Stop]() 
    SyncLock (m_stopLock) 
     MyBase.Stop() 
     My.Application.Log.WriteEntry("... extended Tcp Listener stopped", TraceEventType.Verbose) 
    End SyncLock 
End Sub 

La classe qui utilise le ExtendedTcpListener implémente le modèle IDisposable et à l'intérieur du Éliminez le ExtendedTcpListener.Stop est appelé.

Le texte d'arrêt n'est pas présent dans les journaux lorsque les problèmes se produisent.

Answer 1

Se pourrait-il que, après la première fois que Start est appelé, une autre méthode/thread obtienne un verrou sur m_stopLock? (quel type d'objet est m_stopLock?)

Pouvez-vous regarder avec le débogueur et voir si le constructeur d'observation est appelé? (ou définir une trace avant SynchLock)

Answer 2

Ne disposez-vous pas de l'objet trop tôt? Pouvons-nous voir le code dans lequel vous créez une instance de ExtendedTcpListener et comment vous le gérez?

Answer 3

C'est un drôle, d'accord. Si je comprends bien, une fois que le problème commence à se produire, vous pouvez le reproduire facilement, non? Si c'est le cas, j'attacherais le débogueur à ce point et inspecterais l'objet TcpListener et son Socket sous-jacent (m_ServerSocket). Il n'y a pas d'instructions précises que je puisse donner ici, il suffit de regarder et de voir si quelque chose semble être hors de propos ou tout simplement différent de la façon dont les choses fonctionnent.

Answer 4

Il me semble très dangereux que vous héritiez de TcpListener et de remplacer une méthode non virtuelle en utilisant Shadows. Avez-vous essayé de changer votre code pour ne pas hériter de TcpListener, mais simplement l'encapsuler?

Edit: ajouté exemple de code

Public Class ExtendedTcpListener 
    ' Inherits System.Net.Sockets.TcpListener <== DO NOT INHERIT 

    Private MyTcpListener As New TcpListener() 

    Public Sub Start() 
    SyncLock (m_stopLock) 
     MyTcpListener.Start() 
     MyTcpListener.BeginAcceptTcpClient(AddressOf Me.CompleteAcceptTcpClient, Me) 
     My.Application.Log.WriteEntry("Extended Tcp Listener started ...", TraceEventType.Verbose) 
    End SyncLock 
    End Sub 

    ' ... 
End Class