WSACancelBlockingCall exception

Ok, j'ai une étrange exception générée à partir de mon code qui me préoccupe depuis des siècles.

System.Net.Sockets.SocketException: A blocking operation was interrupted by a call to WSACancelBlockingCall
   at System.Net.Sockets.Socket.Accept()
   at System.Net.Sockets.TcpListener.AcceptTcpClient()

MSDN n'est pas très utile sur ce : http://msdn.microsoft.com/en-us/library/ms741547(SV.85).aspx et je ne sais même pas comment commencer le dépannage de celui-ci. C'est seulement jeté 4 ou 5 fois par jour, et jamais dans notre environnement de test. Seulement dans les sites de production, et sur TOUS les sites de production.

J'ai trouvé beaucoup de postes posent à propos de cette exception, mais pas de réponses définitives à ce qui en est la cause et comment le manipuler ou de le prévenir.

Le code s'exécute dans un autre thread d'arrière-plan, la méthode commence par :

public virtual void Startup()
    {
     TcpListener serverSocket= new TcpListener(new IPEndPoint(bindAddress, port));    
        serverSocket.Start();

puis-je exécuter une boucle de mettre toutes les nouvelles connexions que les emplois dans un thread séparé de la piscine. Il devient de plus en plus complexe en raison de l'application de l'architecture, mais en gros:

   while (( socket = serverSocket.AcceptTcpClient()) !=null) //Funny exception here
    {
         connectionHandler = new ConnectionHandler(socket, mappingStrategy);
         pool.AddJob(connectionHandler);
    }
  }

À partir de là, le pool dispose de son propre fils, qui prennent soin de chaque emploi dans son propre thread, séparément.

Ma compréhension est que AcceptTcpClient() est un appel bloquant, et qu'en quelque sorte c'est dire le fil de cesser de bloquer et de continuer l'exécution.. mais pourquoi? Et que suis-je censé faire? Il suffit de prendre l'exception et l'ignorer?

Bien, je pense à un autre thread est la fermeture de la socket, mais ce n'est certainement pas de mon code.
Ce que je voudrais savoir c'est: est-ce socket fermée par le client de connexion (de l'autre côté de la prise) ou est-il fermé par mon serveur. Parce que c'est à ce moment, chaque fois que cette exception se produit, il shutsdown mon port d'écoute, de manière efficace la fermeture de mon service. Si c'est fait à partir d'un emplacement distant, alors c'est un problème majeur.

Sinon, cela pourrait être tout simplement le serveur IIS éteindre mon application, et donc l'annulation de tous mes threads d'arrière-plan et le blocage des méthodes?

InformationsquelleAutor Radu094 | 2008-08-28

c#sockets

42

Est-il possible que le serverSocket est fermé à partir d'un autre thread? Qui sera la cause de cette exception.
- Dire qu'il est. Comment voulez-vous fermer à partir d'un autre thread? Le socket besoin d'être "volatile"?
- Non, tant que l'autre thread a une référence à la prise de l'objet, il peut la fermer.
- Comment pouvez-vous fermer la socket du même thread si elle est dans le Bloc de l'etat???
InformationsquelleAutor TimK

C'est mon exemple de solution pour éviter WSAcancelblablabla:
Définir votre fil mondial, alors vous pouvez utiliser la méthode invoke comme ceci:

private void closinginvoker(string dummy)
    {
        if (InvokeRequired)
        {
            this.Invoke(new Action<string>(closinginvoker), new object[] { dummy });
            return;
        }
        t_listen.Abort();
        client_flag = true;
        c_idle.Close();
        listener1.Stop();
    }

Après vous l'appelez, fermer le thread d'abord, puis l'forever boucle drapeau afin d'en bloquer plus d'attendre (si vous en avez un), puis fermez tcpclient puis cesser de l'auditeur.

InformationsquelleAutor Nikolaus Very Permana

4

Ce qui pourrait arriver sur un serverSocket.Stop(). Que j'ai appelé chaque fois que Dispose a été appelé.

Ici est de savoir comment mon la gestion des exceptions pour les écouter fil ressemblait:
```
try
{
    //...
}
catch (SocketException socketEx)
{    
    if (_disposed)
        ar.SetAsCompleted(null, false); //exception because listener stopped (disposed), ignore exception
    else
        ar.SetAsCompleted(socketEx, false);
}
```
Maintenant ce qui s'est passé, le plus souvent l'exception pourrait se produire avant _disposed a été définie à true. Donc la solution pour moi a été de faire tout ce thread-safe.

InformationsquelleAutor
3

Même ici!
Mais j'ai compris, que le ReceiveBuffer sur "server-side" a été noyé par les clients!
(Dans mon cas un tas de RFID les Scanners, qui a gardé le spamming sur le TagCode, au lieu d'arrêter l'envoi jusqu'à la prochaine TagCode arrive)

A permis de recueillir les ReceiveBuffers et de reconfigurer les scanners...

InformationsquelleAutor blogga

Plus récemment, j'ai vu cette exception lors de l'utilisation de HttpWebRequest de METTRE un gros fichier et le délai d'attente a été adoptée.

En utilisant le code suivant en tant que votre temps de téléchargement > 3 secondes, il sera la cause de cette erreur aussi loin que je pouvais voir.

string path = "Reasonably large file.dat";
int bufferSize = 1024;
byte[] buffer = new byte[bufferSize];
System.Net.HttpWebRequest req = (HttpWebRequest)System.Net.HttpWebRequest.Create("Some URL");
req.Method = "PUT";
req.Timeout = 3000; //3 seconds, small timeout to demonstrate
long length = new System.IO.FileInfo(path).Length;
using (FileStream input = File.OpenRead(path))
{
    using (Stream output = req.GetRequestStream())
    {
        long remaining = length;
        int bytesRead = 0;
        while ((bytesRead = input.Read(buffer, 0, (int)Math.Min(remaining, (decimal)bufferSize))) > 0)
        {
            output.Write(buffer, 0, bytesRead);
            remaining -= bytesRead;
        }
        output.Close();
    }
input.Close();
}

InformationsquelleAutor SimonNZ

Vous devez vous connecter pour publier un commentaire.