Peut TCP c# client de recevoir et d'envoyer en continu/consécutivement sans sommeil?

Il n'y a rien de mal nécessairement avec le groupement de questions ensemble, mais il n'est de répondre à la question plus difficile... 🙂

L'article MSDN vous lié montre comment faire un seul et fait de la communication TCP, qui est, peut-on envoyer et recevoir. Vous remarquerez également qu'il utilise le Socket classe directement là où la plupart des gens, y compris moi-même, suggère d'utiliser le TcpClient classe à la place. Vous pouvez toujours obtenir le sous-jacent Socket via le Client bien si vous avez besoin de configurer un certain socket par exemple (p. ex., SetSocketOption()).

L'autre aspect de l'exemple à noter est que, bien qu'il utilise des threads pour exécuter le AsyncCallback délégués pour les deux BeginSend() et BeginReceive(), il s'agit essentiellement d'un single-threaded exemple, en raison de la façon dont le ManualResetEvent objets sont utilisés. En cas de récidive de l'échange entre un client et un serveur, ce n'est pas ce que vous voulez.

Très bien, alors vous voulez utiliser TcpClient. Connexion au serveur (par exemple, TcpListener) doit être simple d'utilisation Connect() si vous voulez une opération de blocage ou BeginConnect() si vous voulez un non-opération de blocage. Une fois que la connexion est d'établir, d'utiliser le GetStream() méthode pour obtenir le NetworkStream objet à utiliser pour la lecture et l'écriture. Utiliser le Read()/Write() opérations de blocage I/O et le BeginRead()/méthodes beginwrite() opérations pour les non-blocage I/O. a Noter que le BeginRead() et BeginWrite() utiliser le même AsyncCallback mécanisme employé par le BeginReceive() et BeginSend() méthodes de la Socket classe.

L'une des principales choses à noter à ce point, est ce petit texte de présentation dans la documentation MSDN pour NetworkStream:

Opérations de lecture et écriture peuvent être effectuées simultanément sur un
instance de la NetworkStream classe sans la nécessité pour
la synchronisation. Aussi longtemps qu'il existe un unique thread pour l'écrire
opérations et un fil unique pour les opérations de lecture, il y aura
être pas de contre-ingérence entre lire et écrire des threads et pas de
la synchronisation est nécessaire.

En bref, parce que vous avez l'intention de lire et écrire à partir de la même TcpClient exemple, vous aurez besoin de deux fils pour le faire. À l'aide de threads séparés veillera à ce qu'aucune donnée n'est perdue lors de la réception de données en même temps quelqu'un essaie d'envoyer. La manière dont j'ai abordé ce problème dans mes projets est de créer un objet de niveau supérieur, dire Client, qui enveloppe le TcpClient et de ses sous-jacent NetworkStream. Cette classe crée et gère des deux Thread objets, en les passant la NetworkStream objet à chaque cours de construction. Le premier thread est le Sender fil. Tous ceux qui veulent envoyer des données fait par l'intermédiaire d'un public SendData() méthode sur la Client, qui achemine les données vers le Sender pour la transmission. Le deuxième thread est le Receiver fil. Ce fil à la publication de toutes les données reçues des parties intéressées par l'intermédiaire d'un événement public exposés par le Client. Il ressemble à quelque chose comme ceci:

Client.cs

public sealed partial class Client : IDisposable
{
    //Called by producers to send data over the socket.
    public void SendData(byte[] data)
    {
        _sender.SendData(data);
    }

    //Consumers register to receive data.
    public event EventHandler<DataReceivedEventArgs> DataReceived;

    public Client()
    {
        _client = new TcpClient(...);
        _stream = _client.GetStream();

        _receiver = new Receiver(_stream);
        _sender   = new Sender(_stream);

        _receiver.DataReceived += OnDataReceived;
    }

    private void OnDataReceived(object sender, DataReceivedEventArgs e)
    {
        var handler = DataReceived;
        if (handler != null) DataReceived(this, e);  //re-raise event
    }

    private TcpClient     _client;
    private NetworkStream _stream;
    private Receiver      _receiver;
    private Sender        _sender;
}

Client.Le récepteur.cs

private sealed partial class Client
{
    private sealed class Receiver
    {
        internal event EventHandler<DataReceivedEventArgs> DataReceived;

        internal Receiver(NetworkStream stream)
        {
            _stream = stream;
            _thread = new Thread(Run);
            _thread.Start();
        }

        private void Run()
        {
            //main thread loop for receiving data...
        }

        private NetworkStream _stream;
        private Thread        _thread;
    }
}

Client.Expéditeur.cs

private sealed partial class Client
{
    private sealed class Sender
    {
        internal void SendData(byte[] data)
        {
            //transition the data to the thread and send it...
        }

        internal Sender(NetworkStream stream)
        {
            _stream = stream;
            _thread = new Thread(Run);
            _thread.Start();
        }

        private void Run()
        {
            //main thread loop for sending data...
        }

        private NetworkStream _stream;
        private Thread        _thread;
    }
}

Avis qu'il s'agit de trois .cs fichiers, mais de définir les différents aspects de la même Client classe. J'utilise Visual Studio astuce décrite ici à nid respectifs Receiver et Sender fichiers en vertu de la Client fichier. En un mot, c'est la façon dont je le fais.

Concernant la NetworkStream.DataAvailable/Thread.Sleep() question. Je suis d'accord qu'un événement pourrait être sympa, mais vous pouvez l'atteindre efficacement à l'aide de la Read() méthode en combinaison avec une infinie ReadTimeout. Cela n'aura aucun impact négatif sur le reste de votre application (par exemple, l'INTERFACE utilisateur), car il s'exécute dans son propre thread. Toutefois, cela complique la fermeture du thread (par exemple, lorsque l'application se ferme), de sorte que vous voudrez probablement utiliser quelque chose de plus raisonnable, disons 10 millisecondes. Mais alors, vous êtes de retour dans les bureaux de vote, qui est ce que nous essayons d'éviter en premier lieu. Voici comment je le fais, avec des commentaires pour plus d'explications:

private sealed class Receiver
{
    private void Run()
    {
        try
        {
            //ShutdownEvent is a ManualResetEvent signaled by
            //Client when its time to close the socket.
            while (!ShutdownEvent.WaitOne(0))
            {
                try
                {
                    //We could use the ReadTimeout property and let Read()
                    //block.  However, if no data is received prior to the
                    //timeout period expiring, an IOException occurs.
                    //While this can be handled, it leads to problems when
                    //debugging if we are wanting to break when exceptions
                    //are thrown (unless we explicitly ignore IOException,
                    //which I always forget to do).
                    if (!_stream.DataAvailable)
                    {
                        //Give up the remaining time slice.
                        Thread.Sleep(1);
                    }
                    else if (_stream.Read(_data, 0, _data.Length) > 0)
                    {
                        //Raise the DataReceived event w/data...
                    }
                    else
                    {
                        //The connection has closed gracefully, so stop the
                        //thread.
                        ShutdownEvent.Set();
                    }
                }
                catch (IOException ex)
                {
                    //Handle the exception...
                }
            }
        }
        catch (Exception ex)
        {
            //Handle the exception...
        }
        finally
        {
            _stream.Close();
        }
    }
}

Comme à présent comme "keepalive" sont concernés, il n'est malheureusement pas un moyen de contourner le problème de savoir quand l'autre côté n'a pas quitté la connexion silencieusement à l'exception d'essayer d'envoyer des données. Dans mon cas, depuis que je contrôle à la fois l'envoi et la réception des côtés, j'ai ajouté un petit KeepAlive message (8 octets) de mon protocole. C'est envoyé toutes les cinq secondes des deux côtés de la connexion TCP à moins que d'autres données est déjà en cours d'envoi.

Je pense que j'ai répondu à toutes les facettes que vous avez touché. J'espère que vous trouverez ce utile.