🥇 Mise en œuvre du protocole Reliable Udp pour .Net

Internet a beaucoup changé. L'un des principaux protocoles Internet, le UDP, est utilisé par les applications non seulement pour la diffusion de datagrammes et de messages en broadcast, mais aussi pour établir des connexions « peer-to-peer » entre les nœuds du réseau. En raison de sa simplicité, ce protocole a vu apparaître de nombreuses applications imprévues. Cependant, ses inconvénients, tels que l'absence de garantie de livraison, n'ont pas disparu. Cet article décrit la mise en œuvre d'un protocole de livraison garantie sur UDP.
Contenu :Introduction
Exigences du protocole
En-tête Reliable UDP
Principes de fonctionnement du protocole
Timeouts et minuteries du protocole
Diagramme d'états de transmission de Reliable UDP
Plongée dans le code. Bloc de contrôle de transmission
Plongée dans le code. États

Méthode DisposeByTimeout
Méthode ProcessPackets
Méthode ReceivePacket
Méthode SendPacket

Plongée dans le code. Création et établissement des connexions
Plongée dans le code. Fermeture de la connexion par timeout
Plongée dans le code. Récupération des données
API Reliable UDP
Conclusion
Liens utiles et articles

Introduction

L'architecture initiale de l'Internet supposait un espace d'adressage homogène, où chaque nœud avait une adresse IP globale et unique, et pouvait communiquer directement avec d'autres nœuds. Aujourd'hui, l'Internet a, en réalité, une architecture différente : un domaine d'adresses IP globales et de nombreux domaines d'adresses privées, cachés derrière des dispositifs NAT.Dans une telle architecture, seuls les dispositifs situés dans l'espace d'adressage global peuvent interagir facilement avec d'autres sur le réseau, car ils possèdent une adresse IP unique et globale routable. Un nœud situé dans un réseau privé peut se connecter à d'autres nœuds au sein de ce même réseau, ainsi qu'à d'autres nœuds bien connus dans l'espace d'adressage global. Cette interaction est en grande partie rendue possible grâce au mécanisme de traduction d'adresses réseau. Les dispositifs NAT, tels que les routeurs Wi-Fi, créent des enregistrements spéciaux dans les tables de traduction pour les connexions sortantes et modifient les adresses IP et les numéros de ports dans les paquets. Cela permet d'établir une connexion sortante depuis le réseau privé vers des nœuds dans l'espace d'adressage global. Cependant, en même temps, les dispositifs NAT bloquent généralement tout le trafic entrant, à moins que des règles spécifiques ne soient établies pour les connexions entrantes.

Cette architecture d'Internet est assez correcte pour l'interaction client-serveur, lorsque les clients peuvent se trouver dans des réseaux privés, tandis que les serveurs possèdent une adresse globale. Mais cela crée des difficultés pour la connexion directe entre deux nœuds au sein de différents. réseaux privés. La connexion directe entre deux nœuds est essentielle pour les applications « peer-to-peer », telles que la transmission vocale (Skype), l'accès à distance à un ordinateur (TeamViewer) ou les jeux en ligne. L'une des méthodes les plus efficaces pour établir une connexion peer-to-peer entre des dispositifs situés dans différents réseaux privés s'appelle le « hole punching ». Cette technique est le plus souvent utilisée avec des applications basées sur le protocole UDP.

Cependant, si votre application nécessite une livraison garantie des données, par exemple, si vous transférez des fichiers entre des ordinateurs, alors l'utilisation d'UDP entraînera de nombreuses difficultés, car UDP n'est pas un protocole de livraison garantissant la livraison et ne garantit pas l'ordre des paquets, contrairement au protocole TCP.

Dans ce cas, pour garantir la livraison des paquets, il est nécessaire de mettre en œuvre un protocole de niveau applicatif qui assure la fonctionnalité requise et fonctionne au-dessus de l'UDP.

Dans une telle situation, pour assurer la livraison garantie des paquets, un protocole de niveau applicatif doit être mis en œuvre, garantissant la fonctionnalité nécessaire et fonctionnant par-dessus l'UDP.

Je tiens à souligner qu'il existe une technique de TCP hole punching pour établir des connexions TCP entre des nœuds dans des réseaux privés différents, mais en raison du manque de support de nombreux dispositifs NAT, elle n'est généralement pas considérée comme un moyen principal de connexion de ces nœuds.

Dans cet article, je vais aborder uniquement la mise en œuvre du protocole de livraison garantie. La mise en œuvre de la technique UDP hole punching sera décrite dans les articles suivants.

Exigences du protocole

La livraison fiable des paquets est mise en œuvre par un mécanisme d'accusé de réception positif (dit positive acknowledgment).
La nécessité d'une transmission efficace de grandes quantités de données, c'est-à-dire que le protocole doit éviter les retransmissions inutiles de paquets.
Il doit être possible d'annuler le mécanisme de confirmation de la livraison (capacité de fonctionner comme un protocole UDP « pur »).
Possibilité de mettre en œuvre un mode de commande avec confirmation de chaque message.
L'unité de base de transmission de données doit être un message.

Ces exigences coïncident en grande partie avec les exigences du protocole de données fiables, décrites dans rfc 908 et rfc 1151, et je me suis basé sur ces standards lors de la conception de ce protocole.

Pour comprendre ces exigences, examinons les diagrammes temporels de transmission des données entre deux nœuds d'un réseau selon les protocoles TCP et UDP. Supposons que dans les deux cas, un paquet soit perdu.
Transmission de données non interactives via TCP :

Comme le montre le diagramme, en cas de perte de paquets, TCP détectera le paquet perdu et en informera l'expéditeur, en demandant le numéro du segment perdu.
Transmission de données via le protocole UDP :

UDP ne prend aucune mesure pour détecter les pertes. La vérification des erreurs de transmission dans le protocole UDP repose entièrement sur l'application.

La détection des erreurs dans le protocole TCP est réalisée grâce à l'établissement d'une connexion avec le nœud final, en maintenant l'état de cette connexion, en indiquant le numéro des octets envoyés dans chaque en-tête de paquet, et en envoyant des notifications de réception par le biais du numéro d'accusé de réception « acknowledge number ».

De plus, pour améliorer les performances (c'est-à-dire envoyer plusieurs segments sans attendre de confirmation), le protocole TCP utilise ce qu'on appelle une fenêtre de transmission — le nombre d'octets de données que l'expéditeur d'un segment s'attend à recevoir.

Pour plus de détails sur le protocole TCP, vous pouvez consulter rfc 793, avec UDP dans rfc 768, où ils sont, en fait, définis.

Comme il est évident d'après ce qui précède, pour créer un protocole de livraison de messages fiable sur UDP (que nous appellerons désormais Reliable UDP), il est nécessaire de mettre en œuvre des mécanismes de transmission de données similaires à ceux de TCP. À savoir :

maintenir l'état de la connexion
utiliser la numérotation des segments
utiliser des paquets de confirmation spéciaux
utiliser un mécanisme de fenêtre simplifié pour augmenter le débit du protocole

De plus, il est nécessaire :

de signaler le début du message, pour allouer des ressources à la connexion
de signaler la fin du message, pour transmettre le message reçu à l'application supérieure et libérer les ressources du protocole
de permettre au protocole, pour des connexions spécifiques, de désactiver le mécanisme de confirmation de livraison, afin de fonctionner comme un UDP « pur »

En-tête Reliable UDP

Rappelons que le datagramme UDP est encapsulé dans un datagramme IP. Le paquet Reliable UDP est donc « enveloppé » dans un datagramme UDP.
Encapsulation de l'en-tête Reliable UDP :

La structure de l'en-tête Reliable UDP est assez simple :

Flags – les drapeaux de contrôle du paquet
MessageType – type de message, utilisé par les applications supérieures pour s'abonner à des messages spécifiques
TransmissionId — l'identifiant de transmission, qui, avec l'adresse et le port du destinataire, définit de manière unique la connexion
PacketNumber – numéro de paquet
Options – options supplémentaires du protocole. Dans le cas du premier paquet, utilisé pour indiquer la taille du message

Les drapeaux suivants existent :

FirstPacket — premier paquet du message
NoAsk — le message ne nécessite pas l'activation du mécanisme de confirmation
LastPacket — dernier paquet du message
RequestForPacket — paquet de confirmation ou demande d'un paquet perdu

Principes de fonctionnement du protocole

Étant donné que Reliable UDP est orienté vers la transmission garantie de messages entre deux nœuds, il doit être capable d'établir une connexion avec l'autre partie. Pour établir la connexion, l'expéditeur envoie un paquet avec le drapeau FirstPacket, auquel la réponse indiquera l'établissement de la connexion. Tous les paquets de réponse, ou, autrement dit, les paquets de confirmation, affichent toujours la valeur du champ PacketNumber unité supérieure à la valeur la plus élevée de PacketNumber parmi les paquets reçus avec succès. Dans le champ Options, la taille du message est enregistrée pour le premier paquet envoyé.

Un mécanisme similaire est utilisé pour terminer la connexion. Dans le dernier paquet de messages, le drapeau LastPacket est défini. Dans le paquet de réponse, le numéro du dernier paquet + 1 est indiqué, ce qui signifie pour la partie réceptrice que le message a été livré avec succès.
Diagramme d'établissement et de terminaison de la connexion :

Lorsque la connexion est établie, le transfert de données commence. Les données sont transmises par blocs de paquets. Chaque bloc, sauf le dernier, contient un nombre fixe de paquets. Ce nombre est égal à la taille de la fenêtre de réception/transmission. Le dernier bloc de données peut contenir moins de paquets. Après l'envoi de chaque bloc, la partie émettrice attend une confirmation de livraison ou une demande de renvoi des paquets perdus, laissant la fenêtre de réception/transmission ouverte pour recevoir des réponses. Après réception de la confirmation de livraison du bloc, la fenêtre de réception/transmission est déplacée et le prochain bloc de données est envoyé.

La partie réceptrice accepte les paquets. Chaque paquet est vérifié pour sa conformité à la fenêtre de transmission. Les paquets ne correspondant pas à la fenêtre et les doublons sont rejetés. Comme la taille de la fenêtre est strictement fixe et identique pour le récepteur et l'émetteur, en cas de livraison d'un bloc de paquets sans pertes, la fenêtre est déplacée pour recevoir les paquets du prochain bloc de données et une confirmation de livraison est envoyée. Si la fenêtre n'est pas remplie dans le délai fixé par le minuteur de travail, une vérification sera lancée pour déterminer quels paquets n'ont pas été livrés et des demandes de renvoi seront envoyées.
Diagramme de retransmission :

Timeouts et minuteries du protocole

Il existe plusieurs raisons pour lesquelles une connexion ne peut pas être établie. Par exemple, si la partie réceptrice est hors ligne. Dans ce cas, lors de la tentative d'établissement de la connexion, celle-ci sera fermée en raison d'un dépassement de délai. Dans la mise en œuvre de Reliable UDP, deux minuteurs sont utilisés pour établir les délais. Le premier, le minuteur de travail, est utilisé pour attendre la réponse de l'hôte distant. S'il expire du côté de l'émetteur, le dernier paquet envoyé est renvoyé. Si, cependant, le minuteur expire chez le récepteur, une vérification des paquets perdus est effectuée et des demandes de renvoi sont envoyées.

Le second minuteur est nécessaire pour fermer la connexion en cas d'absence de communication entre les nœuds. Pour le côté expéditeur, il se déclenche immédiatement après le déclenchement du minuteur de travail et attend une réponse du nœud distant. En l'absence de réponse dans le délai imparti, la connexion est terminée et les ressources sont libérées. Du côté récepteur, le minuteur de fermeture de connexion se déclenche après le double déclenchement du minuteur de travail. Cela est nécessaire pour éviter la perte du paquet de confirmation. Lorsque le minuteur se déclenche, la connexion est également terminée et les ressources sont libérées.

Diagramme d'états de transmission de Reliable UDP

Les principes de fonctionnement du protocole sont réalisés dans un automate à états, chaque état ayant une logique de traitement spécifique des paquets.
Diagramme des états du Reliable UDP :

Fermé – n'est en réalité pas un état, c'est un point de départ et de terminaison pour l'automate. L'état Fermé est considéré comme le bloc de gestion de transmission, qui, en réalisant un serveur UDP asynchrone, redirige les paquets vers les connexions appropriées et démarre le traitement des états.

EnvoiPremierPaquet – état initial dans lequel se trouve la connexion sortante lors de l'envoi d'un message.

Dans cet état, le premier paquet pour les messages ordinaires est envoyé. Pour les messages sans accusé de réception, c'est le seul état – dans celui-ci, l'ensemble du message est envoyé.

CycleEnvoi – état principal pour la transmission des paquets du message.

La transition vers cet état depuis l'état EnvoiPremierPaquet se fait après l'envoi du premier paquet de message. C'est précisément dans cet état que parviennent tous les accusés de réception et les demandes de retransmission. La sortie de cet état est possible pour deux raisons – en cas de livraison réussie du message ou à cause d'un délai d'attente.

PremierPaquetReçu – état initial pour le destinataire du message.

Ici, la correction du début de la transmission est vérifiée, les structures nécessaires sont créées et un accusé de réception du premier paquet est envoyé.

Pour un message constitué d'un seul paquet et envoyé sans confirmation de livraison – c'est le seul état. Après le traitement de ce type de message, la connexion est fermée.

Assemblage – état principal pour la réception des paquets du message.

Il enregistre les paquets dans un stockage temporaire, vérifie la perte de paquets, envoie des accusés de réception pour les blocs de paquets et les messages dans leur intégralité, et envoie des demandes de retransmission des paquets perdus. En cas de réception réussie de l'ensemble du message, la connexion passe à l'état Terminé, sinon, il sort par délai d'attente.

Terminé – fermeture de la connexion en cas de réception réussie de l'ensemble du message.

Cet état est nécessaire pour assembler le message et pour les cas où l'accusé de réception du message a été perdu en route vers l'expéditeur. La sortie de cet état se fait par délai d'attente, mais la connexion est considérée comme correctement fermée.

Plongée dans le code. Bloc de contrôle de transmission

Un des éléments clés de Reliable UDP est le bloc de contrôle de transmission. La tâche de ce bloc est de stocker les connexions en cours et les éléments auxiliaires, de distribuer les paquets entrants aux connexions appropriées, de fournir une interface pour envoyer des paquets à la connexion et de mettre en œuvre l'API du protocole. Le bloc de contrôle de transmission reçoit des paquets du niveau UDP et les redirige vers le traitement dans l'automate à états. Un serveur UDP asynchrone est mis en œuvre pour recevoir les paquets.
Quelques membres de la classe ReliableUdpConnectionControlBlock :

internal class ReliableUdpConnectionControlBlock : IDisposable
{
  // tableau de bytes pour la clé spécifiée. Utilisé pour assembler les messages entrants
  public ConcurrentDictionary<Tuple, byte[]> IncomingStreams { get; private set; }
  // tableau de bytes pour la clé spécifiée. Utilisé pour envoyer des messages sortants.
  public ConcurrentDictionary<Tuple, byte[]> OutcomingStreams { get; private set; }
  // enregistrement de la connexion pour la clé spécifiée.
  private readonly ConcurrentDictionary<Tuple, ReliableUdpConnectionRecord> m_listOfHandlers;
  // liste des abonnés aux messages.
  private readonly List m_subscribers;
  // socket local
  private Socket m_socketIn;
  // port pour les messages entrants
  private int m_port;
  // adresse IP locale
  private IPAddress m_ipAddress;
  // point de terminaison local
  public IPEndPoint LocalEndpoint { get; private set; }
  // collection d'états préalablement initialisés
  // de l'automate
  public StatesCollection States { get; private set; }
  // générateur de nombres aléatoires. Utilisé pour créer TransmissionId
  private readonly RNGCryptoServiceProvider m_randomCrypto;
  	//...
}

Implémentation d'un serveur UDP asynchrone :

private void Receive()
{
  EndPoint connectedClient = new IPEndPoint(IPAddress.Any, 0);
  // Création d'un nouveau tampon pour chaque socket.BeginReceiveFrom 
  byte[] buffer = new byte[DefaultMaxPacketSize + ReliableUdpHeader.Length];
  // Transmission du tampon en tant que paramètre pour la méthode asynchrone
  this.m_socketIn.BeginReceiveFrom(buffer, 0, buffer.Length, SocketFlags.None, ref connectedClient, EndReceive, buffer);
}

private void EndReceive(IAsyncResult ar)
{
  EndPoint connectedClient = new IPEndPoint(IPAddress.Any, 0);
  int bytesRead = this.m_socketIn.EndReceiveFrom(ar, ref connectedClient);
  // Le paquet a été reçu, prêt à en accepter un suivant        
  Receive();
  // Puisque la façon la plus simple de résoudre la question du tampon - obtenir une référence à celui-ci 
  // depuis IAsyncResult.AsyncState        
  byte[] bytes = ((byte[]) ar.AsyncState).Slice(0, bytesRead);
  // Obtention de l'en-tête du paquet        
  ReliableUdpHeader header;
  if (!ReliableUdpStateTools.ReadReliableUdpHeader(bytes, out header))
  {          
    // Un paquet incorrect a été reçu - on l'ignore
    return;
  }
  // Construction de la clé pour déterminer le record de connexion pour le paquet
  Tuple key = new Tuple(connectedClient, header.TransmissionId);
  // Obtention du record de connexion existant ou création d'un nouveau
  ReliableUdpConnectionRecord record = m_listOfHandlers.GetOrAdd(key, new ReliableUdpConnectionRecord(key, this, header.ReliableUdpMessageType));
  // Démarrage du traitement du paquet dans l'automate final
  record.State.ReceivePacket(record, header, bytes);
}

Pour chaque transmission de message, une structure contenant des informations sur la connexion est créée. Cette structure s'appelle record de connexion.
Certains membres de la classe ReliableUdpConnectionRecord :

classe interne ReliableUdpConnectionRecord : IDisposable
{    
  // tableau d'octets avec le message    
  public byte[] IncomingStream { get; set; }
  // référence à l'état de l'automate
  public ReliableUdpState State { get; set; }    
  // paire qui identifie de manière unique l'enregistrement de connexion
  // dans le bloc de contrôle de transmission     
  public Tuple Key { get; private set;}
  // limite inférieure de la fenêtre de réception    
  public int WindowLowerBound;
  // taille de la fenêtre de transmission
  public readonly int WindowSize;     
  // numéro de paquet à envoyer
  public int SndNext;
  // nombre de paquets à envoyer
  public int NumberOfPackets;
  // numéro de transmission (c'est la seconde partie de Tuple)
  // chaque message a son propre	
  public readonly Int32 TransmissionId;
  // point de terminaison IP distant – le récepteur du message
  public readonly IPEndPoint RemoteClient;
  // taille du paquet, pour éviter la fragmentation au niveau IP
  // ne doit pas dépasser MTU – (IP.Header + UDP.Header + RelaibleUDP.Header)
  public readonly int BufferSize;
  // bloc de contrôle de transmission
  public readonly ReliableUdpConnectionControlBlock Tcb;
  // encapsule les résultats de l'opération asynchrone pour BeginSendMessage/EndSendMessage
  public readonly AsyncResultSendMessage AsyncResult;
  // ne pas envoyer de paquets d'accusé de réception
  public bool IsNoAnswerNeeded;
  // dernier paquet correctement reçu (toujours défini sur le plus grand numéro)
  public int RcvCurrent;
  // tableau des numéros de paquets perdus
  public int[] LostPackets { get; private set; }
  // le dernier paquet est-il arrivé. Utilisé comme bool.
  public int IsLastPacketReceived = 0;
  //...
}

Plongée dans le code. États

Les états implémentent l'automate du protocole Reliable UDP, où se déroule le traitement principal des paquets. La classe abstraite ReliableUdpState fournit une interface pour l'état :

Toute la logique de fonctionnement du protocole est réalisée par les classes présentées ci-dessus, en collaboration avec une classe d'assistance fournissant des méthodes statiques, telles que, par exemple, la construction de l'en-tête ReliableUdp à partir de l'enregistrement de connexion.

Les mises en œuvre des méthodes d'interface qui définissent les principaux algorithmes de fonctionnement du protocole seront examinées en détail.

Méthode DisposeByTimeout

La méthode DisposeByTimeout est responsable de la libération des ressources de connexion à l'expiration du délai d'attente et pour signaler la livraison réussie/échouée du message.
ReliableUdpState.DisposeByTimeout :

protected virtual void DisposeByTimeout(object record)
{
  ReliableUdpConnectionRecord connectionRecord = (ReliableUdpConnectionRecord) record;      
  if (record.AsyncResult != null)
  {
    connectionRecord.AsyncResult.SetAsCompleted(false);
  }
  connectionRecord.Dispose();
}

Il est redéfini uniquement dans l'état Terminé.
Completed.DisposeByTimeout :

protected override void DisposeByTimeout(object record)
{
  ReliableUdpConnectionRecord connectionRecord = (ReliableUdpConnectionRecord) record;
  // nous signalons la réception réussie du message
  SetAsCompleted(connectionRecord);
}

Méthode ProcessPackets

La méthode ProcessPackets est responsable du traitement supplémentaire d'un paquet ou de plusieurs paquets. Elle est appelée directement ou via un minuteur d'attente des paquets.

Dans l'état Assemblage la méthode est redéfinie et est chargée de vérifier les paquets perdus et de passer à l'état Terminé, en cas de réception du dernier paquet et de vérification réussie
Assembling.ProcessPackets :

public override void ProcessPackets(ReliableUdpConnectionRecord connectionRecord)
{
  if (connectionRecord.IsDone != 0)
    return;
  if (!ReliableUdpStateTools.CheckForNoPacketLoss(connectionRecord, connectionRecord.IsLastPacketReceived != 0))
  {
    // il y a des paquets perdus, nous envoyons des demandes pour eux
    foreach (int seqNum in connectionRecord.LostPackets)
    {
      if (seqNum != 0)
      {
        ReliableUdpStateTools.SendAskForLostPacket(connectionRecord, seqNum);
      }
    }
    // nous réglons le minuteur une seconde fois, pour tenter de renvoyez
    if (!connectionRecord.TimerSecondTry)
    {
      connectionRecord.WaitForPacketsTimer.Change(connectionRecord.ShortTimerPeriod, -1);
      connectionRecord.TimerSecondTry = true;
      return;
    }
    // si après deux tentatives de WaitForPacketTimer
    // nous n'avons pas réussi à obtenir les paquets - lançons le minuteur de fermeture de connexion
    StartCloseWaitTimer(connectionRecord);
  }
  else if (connectionRecord.IsLastPacketReceived != 0)
  // vérification réussie
  {
    // nous envoyons un accusé de réception de la réception du bloc de données
    ReliableUdpStateTools.SendAcknowledgePacket(connectionRecord);
    connectionRecord.State = connectionRecord.Tcb.States.Completed;
    connectionRecord.State.ProcessPackets(connectionRecord);
    // au lieu de mettre immédiatement en œuvre les ressources
    // nous lançons le minuteur, au cas où
    // si le dernier ack n'atteint pas l'expéditeur et qu'il le demande à nouveau.
    // au déclenchement du minuteur - nous mettons en œuvre les ressources
    // dans l'état Complété, la méthode du minuteur est redéfinie
    StartCloseWaitTimer(connectionRecord);
  }
  // c'est le cas où l'ack du bloc de paquets a été perdu
  else
  {
    if (!connectionRecord.TimerSecondTry)
    {
      ReliableUdpStateTools.SendAcknowledgePacket(connectionRecord);
      connectionRecord.WaitForPacketsTimer.Change(connectionRecord.ShortTimerPeriod, -1);
      connectionRecord.TimerSecondTry = true;
      return;
    }
    // nous lançons le minuteur de fermeture de connexion
    StartCloseWaitTimer(connectionRecord);
  }
}

Dans l'état CycleEnvoi cette méthode est appelée uniquement par le minuteur, et est responsable de la réexpédition du dernier message, ainsi que de l'activation du minuteur de fermeture de connexion.
SendingCycle.ProcessPackets :

public override void ProcessPackets(ReliableUdpConnectionRecord connectionRecord)
{
  if (connectionRecord.IsDone != 0)
    return;
  // Envoi du dernier paquet à nouveau
  // (En cas de restauration de la connexion, le nœud récepteur renverra les demandes qui n'ont pas été reçues)
  ReliableUdpStateTools.SendPacket(connectionRecord, ReliableUdpStateTools.RetransmissionCreateUdpPayload(connectionRecord, connectionRecord.SndNext - 1));
  // Démarre le timer CloseWait - pour attendre la restauration ou la clôture de la connexion
  StartCloseWaitTimer(connectionRecord);
}

Dans l'état Terminé Cette méthode arrête le timer de travail et transmet le message aux abonnés.
Completed.ProcessPackets:

public override void ProcessPackets(ReliableUdpConnectionRecord connectionRecord)
{
  if (connectionRecord.WaitForPacketsTimer != null)
    connectionRecord.WaitForPacketsTimer.Dispose();
  // Assemble le message et le transmet aux abonnés
  ReliableUdpStateTools.CreateMessageFromMemoryStream(connectionRecord);
}

Méthode ReceivePacket

Dans l'état PremierPaquetReçu La principale tâche de la méthode est de déterminer si le premier paquet du message a réellement été reçu sur l'interface, ainsi que de rassembler un message composé d'un seul paquet.
FirstPacketReceived.ReceivePacket:

public override void ReceivePacket(ReliableUdpConnectionRecord connectionRecord, ReliableUdpHeader header, byte[] payload)
{
  if (!header.Flags.HasFlag(ReliableUdpHeaderFlags.FirstPacket))
    // nous rejetons le paquet
    return;
  // la combinaison des deux drapeaux - FirstPacket et LastPacket - indique que nous avons un seul message
  if (header.Flags.HasFlag(ReliableUdpHeaderFlags.FirstPacket) &
      header.Flags.HasFlag(ReliableUdpHeaderFlags.LastPacket))
  {
    ReliableUdpStateTools.CreateMessageFromSinglePacket(connectionRecord, header, payload.Slice(ReliableUdpHeader.Length, payload.Length));
    if (!header.Flags.HasFlag(ReliableUdpHeaderFlags.NoAsk))
    {
      // envoyer le paquet d'accusé de réception          
      ReliableUdpStateTools.SendAcknowledgePacket(connectionRecord);
    }
    SetAsCompleted(connectionRecord);
    return;
  }
  // par conception, tous les numéros de paquet commencent à 0;
  if (header.PacketNumber != 0)          
    return;
  ReliableUdpStateTools.InitIncomingBytesStorage(connectionRecord, header);
  ReliableUdpStateTools.WritePacketData(connectionRecord, header, payload);
  // comptons le nombre de paquets qui doivent arriver
  connectionRecord.NumberOfPackets = (int)Math.Ceiling((double) ((double) connectionRecord.IncomingStream.Length/(double) connectionRecord.BufferSize));
  // enregistrons le numéro du dernier paquet reçu (0)
  connectionRecord.RcvCurrent = header.PacketNumber;
  // décalons la fenêtre de réception de 1
  connectionRecord.WindowLowerBound++;
  // changeons d'état
  connectionRecord.State = connectionRecord.Tcb.States.Assembling;
  // si le mécanisme d'accusé de réception n'est pas nécessaire
  // démarrons un minuteur qui libérera toutes les structures         
  if (header.Flags.HasFlag(ReliableUdpHeaderFlags.NoAsk))
  {
    connectionRecord.CloseWaitTimer = new Timer(DisposeByTimeout, connectionRecord, connectionRecord.ShortTimerPeriod, -1);
  }
  else
  {
    ReliableUdpStateTools.SendAcknowledgePacket(connectionRecord);
    connectionRecord.WaitForPacketsTimer = new Timer(CheckByTimer, connectionRecord, connectionRecord.ShortTimerPeriod, -1);
  }
}

Dans l'état CycleEnvoi Cette méthode est redéfinie pour recevoir des confirmations de livraison et des demandes de retransmission.
SendingCycle.ReceivePacket:

public override void ReceivePacket(ReliableUdpConnectionRecord connectionRecord, ReliableUdpHeader header, byte[] payload)
{
  if (connectionRecord.IsDone != 0)
    return;
  if (!header.Flags.HasFlag(ReliableUdpHeaderFlags.RequestForPacket))
    return;
  // calcul de la limite supérieure de la fenêtre
  // on prend la limite de la fenêtre + 1, pour obtenir les confirmations de livraison
  int windowHighestBound = Math.Min((connectionRecord.WindowLowerBound + connectionRecord.WindowSize), (connectionRecord.NumberOfPackets));
  // vérification de l'appartenance à la fenêtre
  if (header.PacketNumber  windowHighestBound)
    return;
  connectionRecord.WaitForPacketsTimer.Change(connectionRecord.ShortTimerPeriod, -1);
  if (connectionRecord.CloseWaitTimer != null)
    connectionRecord.CloseWaitTimer.Change(-1, -1);
  // vérifier le dernier paquet :
  if (header.PacketNumber == connectionRecord.NumberOfPackets)
  {
    // transmission terminée
    Interlocked.Increment(ref connectionRecord.IsDone);
    SetAsCompleted(connectionRecord);
    return;
  }
  // c'est une réponse au premier paquet avec confirmation
  if ((header.Flags.HasFlag(ReliableUdpHeaderFlags.FirstPacket) && header.PacketNumber == 1))
  {
    // sans décalage de fenêtre
    SendPacket(connectionRecord);
  }
  // confirmation de la réception du bloc de données
  else if (header.PacketNumber == windowHighestBound)
  {
    // décalage de la fenêtre d réception/envoi
    connectionRecord.WindowLowerBound += connectionRecord.WindowSize;
    // réinitialisation du tableau de contrôle de transmission
    connectionRecord.WindowControlArray.Nullify();
    // envoi du bloc de paquets
    SendPacket(connectionRecord);
  }
  // c'est une demande de retransmission - on envoie le paquet demandé
  else
    ReliableUdpStateTools.SendPacket(connectionRecord, ReliableUdpStateTools.RetransmissionCreateUdpPayload(connectionRecord, header.PacketNumber));
}

Dans l'état Assemblage La méthode ReceivePacket effectue le travail principal de l'assemblage du message à partir des paquets reçus.
Assembling.ReceivePacket:

public override void ReceivePacket(ReliableUdpConnectionRecord connectionRecord, ReliableUdpHeader header, byte[] payload)
{
  if (connectionRecord.IsDone != 0)
    return;
  // traitement des paquets avec le mécanisme de confirmation de livraison désactivé
  if (header.Flags.HasFlag(ReliableUdpHeaderFlags.NoAsk))
  {
    // réinitialiser le minuteur
    connectionRecord.CloseWaitTimer.Change(connectionRecord.LongTimerPeriod, -1);
    // enregistrer les données
    ReliableUdpStateTools.WritePacketData(connectionRecord, header, payload);
    // si nous avons reçu un paquet avec le dernier indicateur - finaliser
    if (header.Flags.HasFlag(ReliableUdpHeaderFlags.LastPacket))
    {
      connectionRecord.State = connectionRecord.Tcb.States.Completed;
      connectionRecord.State.ProcessPackets(connectionRecord);
    }
    return;
  }
  // calcul de la limite supérieure de la fenêtre
  int windowHighestBound = Math.Min((connectionRecord.WindowLowerBound + connectionRecord.WindowSize - 1), (connectionRecord.NumberOfPackets - 1));
  // ignorer les paquets en dehors de la fenêtre
  if (header.PacketNumber  (windowHighestBound))
    return;
  // ignorer les doublons
  if (connectionRecord.WindowControlArray.Contains(header.PacketNumber))
    return;
  // enregistrer les données 
  ReliableUdpStateTools.WritePacketData(connectionRecord, header, payload);
  // incrémenter le compteur de paquets        
  connectionRecord.PacketCounter++;
  // enregistrer le numéro de paquet actuel dans le tableau de contrôle de fenêtre        
  connectionRecord.WindowControlArray[header.PacketNumber - connectionRecord.WindowLowerBound] = header.PacketNumber;
  // établir le plus grand paquet reçu        
  if (header.PacketNumber > connectionRecord.RcvCurrent)
    connectionRecord.RcvCurrent = header.PacketNumber;
  // redémarrer les minuteurs        
  connectionRecord.TimerSecondTry = false;
  connectionRecord.WaitForPacketsTimer.Change(connectionRecord.ShortTimerPeriod, -1);
  if (connectionRecord.CloseWaitTimer != null)
    connectionRecord.CloseWaitTimer.Change(-1, -1);
  // si le dernier paquet est arrivé
  if (header.Flags.HasFlag(ReliableUdpHeaderFlags.LastPacket))
  {
    Interlocked.Increment(ref connectionRecord.IsLastPacketReceived);
  }
  // si nous avons reçu tous les paquets de la fenêtre, alors réinitialiser le compteur
  // et envoyer un paquet de confirmation
  else if (connectionRecord.PacketCounter == connectionRecord.WindowSize)
  {
    // réinitialiser le compteur.      
    connectionRecord.PacketCounter = 0;
    // décaler la fenêtre de transmission
    connectionRecord.WindowLowerBound += connectionRecord.WindowSize;
    // réinitialisation du tableau de contrôle de transmission
    connectionRecord.WindowControlArray.Nullify();
    ReliableUdpStateTools.SendAcknowledgePacket(connectionRecord);
  }
  // si le dernier paquet est déjà reçu        
  if (Thread.VolatileRead(ref connectionRecord.IsLastPacketReceived) != 0)
  {
    // vérifier les paquets          
    ProcessPackets(connectionRecord);
  }
}

Dans l'état Terminé La seule tâche de la méthode est d'envoyer une nouvelle confirmation de la réception réussie du message.
Completed.ReceivePacket:

public override void ReceivePacket(ReliableUdpConnectionRecord connectionRecord, ReliableUdpHeader header, byte[] payload)
{
  // renvoi du dernier paquet en raison de
  // le dernier ack n'est pas arrivé à l'expéditeur
  if (header.Flags.HasFlag(ReliableUdpHeaderFlags.LastPacket))
  {
    ReliableUdpStateTools.SendAcknowledgePacket(connectionRecord);
  }
}

Méthode SendPacket

Dans l'état EnvoiPremierPaquet Cette méthode envoie le premier paquet de données, ou, si le message ne nécessite pas de confirmation de livraison — tout le message.
FirstPacketSending.SendPacket :

public override void SendPacket(ReliableUdpConnectionRecord connectionRecord)
{
  connectionRecord.PacketCounter = 0;
  connectionRecord.SndNext = 0;
  connectionRecord.WindowLowerBound = 0;       
  // si la confirmation n'est pas nécessaire - envoyons tous les paquets
  // et libérons les ressources
  if (connectionRecord.IsNoAnswerNeeded)
  {
    // Ici, l'envoi se fait tel quel
    do
    {
      ReliableUdpStateTools.SendPacket(connectionRecord, ReliableUdpStateTools.CreateUdpPayload(connectionRecord, ReliableUdpStateTools. CreateReliableUdpHeader(connectionRecord)));
      connectionRecord.SndNext++;
    } while (connectionRecord.SndNext < connectionRecord.NumberOfPackets);
    SetAsCompleted(connectionRecord);
    return;
  }
  // créons l'en-tête du paquet et l'envoyons
  ReliableUdpHeader header = ReliableUdpStateTools.CreateReliableUdpHeader(connectionRecord);
  ReliableUdpStateTools.SendPacket(connectionRecord, ReliableUdpStateTools.CreateUdpPayload(connectionRecord, header));
  // augmentons le compteur
  connectionRecord.SndNext++;
  // décalons la fenêtre
  connectionRecord.WindowLowerBound++;
  connectionRecord.State = connectionRecord.Tcb.States.SendingCycle;
  // Démarrons le minuteur
  connectionRecord.WaitForPacketsTimer = new Timer(CheckByTimer, connectionRecord, connectionRecord.ShortTimerPeriod, -1);
}

Dans l'état CycleEnvoi Dans cette méthode, un bloc de paquets est envoyé.
SendingCycle.SendPacket :

public override void SendPacket(ReliableUdpConnectionRecord connectionRecord)
{      
  // envoi d'un bloc de paquets      
  for (connectionRecord.PacketCounter = 0;
        connectionRecord.PacketCounter < connectionRecord.WindowSize &&
        connectionRecord.SndNext < connectionRecord.NumberOfPackets;
        connectionRecord.PacketCounter++)
  {
    ReliableUdpHeader header = ReliableUdpStateTools.CreateReliableUdpHeader(connectionRecord);
    ReliableUdpStateTools.SendPacket(connectionRecord, ReliableUdpStateTools.CreateUdpPayload(connectionRecord, header));
    connectionRecord.SndNext++;
  }
  // en cas de grande fenêtre de transmission, redémarrons le minuteur après l'envoi
  connectionRecord.WaitForPacketsTimer.Change( connectionRecord.ShortTimerPeriod, -1 );
  if ( connectionRecord.CloseWaitTimer != null )
  {
    connectionRecord.CloseWaitTimer.Change( -1, -1 );
  }
}

Plongée dans le code. Création et établissement des connexions

Maintenant que nous avons fait connaissance avec les principaux états et méthodes utilisés pour gérer les états, nous pouvons examiner en détail quelques exemples de fonctionnement du protocole.
Diagramme de transmission des données dans des conditions normales :

Examinons en détail la création record de connexion pour établir une connexion et envoyer le premier paquet. L'initiateur de la transmission est toujours l'application qui appelle la méthode API pour envoyer le message. Ensuite, la méthode StartTransmission du bloc de contrôle de transmission est activée, lançant la transmission de données pour le nouveau message.
Création d'une connexion sortante :

private void StartTransmission(ReliableUdpMessage reliableUdpMessage, EndPoint endPoint, AsyncResultSendMessage asyncResult)
{
  if (m_isListenerStarted == 0)
  {
    if (this.LocalEndpoint == null)
    {
      throw new ArgumentNullException( "", "Vous devez utiliser un constructeur avec des paramètres ou démarrer l'écoute avant d'envoyer un message" );
    }
    // démarrer le traitement des paquets entrants
    StartListener(LocalEndpoint);
  }
  // créer une clé pour le dictionnaire, basée sur EndPoint et ReliableUdpHeader.TransmissionId        
  byte[] transmissionId = new byte[4];
  // générer un numéro aléatoire transmissionId        
  m_randomCrypto.GetBytes(transmissionId);
  Tuple key = new Tuple(endPoint, BitConverter.ToInt32(transmissionId, 0));
  // créer un nouvel enregistrement pour la connexion et vérifier, 
  // si un tel numéro existe déjà dans nos dictionnaires
  if (!m_listOfHandlers.TryAdd(key, new ReliableUdpConnectionRecord(key, this, reliableUdpMessage, asyncResult)))
  {
    // si cela existe – régénérer le numéro aléatoire 
    m_randomCrypto.GetBytes(transmissionId);
    key = new Tuple(endPoint, BitConverter.ToInt32(transmissionId, 0));
    if (!m_listOfHandlers.TryAdd(key, new ReliableUdpConnectionRecord(key, this, reliableUdpMessage, asyncResult)))
      // si encore échoué – générer une exception
      throw new ArgumentException("La paire TransmissionId & EndPoint existe déjà dans le dictionnaire");
  }
  // état lancé pour traitement         
  m_listOfHandlers[key].State.SendPacket(m_listOfHandlers[key]);
}

Envoi du premier paquet (état FirstPacketSending) :

public override void SendPacket(ReliableUdpConnectionRecord connectionRecord)
{
  connectionRecord.PacketCounter = 0;
  connectionRecord.SndNext = 0;
  connectionRecord.WindowLowerBound = 0;       
  // ... 
  // créer l'en-tête du paquet et l'envoyer 
  ReliableUdpHeader header = ReliableUdpStateTools.CreateReliableUdpHeader(connectionRecord);
  ReliableUdpStateTools.SendPacket(connectionRecord, ReliableUdpStateTools.CreateUdpPayload(connectionRecord, header));
  // augmenter le compteur
  connectionRecord.SndNext++;
  // décaler la fenêtre
  connectionRecord.WindowLowerBound++;
  // passer à l'état SendingCycle
  connectionRecord.State = connectionRecord.Tcb.States.SendingCycle;
  // Démarrer le minuteur
  connectionRecord.WaitForPacketsTimer = new Timer(CheckByTimer, connectionRecord, connectionRecord.ShortTimerPeriod, -1);
}

Après l'envoi du premier paquet, l'expéditeur passe à l'état CycleEnvoi – attendre la confirmation de la livraison du paquet.
Le côté récepteur, à l'aide de la méthode EndReceive, accepte le paquet envoyé, crée un nouveau record de connexion et transmet ce paquet, avec l'en-tête préalablement analysé, au traitement de la méthode ReceivePacket de l'état PremierPaquetReçu
Création d'une connexion côté réception :

private void EndReceive(IAsyncResult ar)
{
  // ...
  // paquet reçu
  // analyse de l'en-tête du paquet
  ReliableUdpHeader header;
  if (!ReliableUdpStateTools.ReadReliableUdpHeader(bytes, out header))
  {
    // un paquet incorrect est arrivé - nous le rejetons
    return;
  }
  // construit la clé pour déterminer l'enregistrement de connexion pour le paquet
  Tuple key = new Tuple(connectedClient, header.TransmissionId);
  // récupère l'enregistrement de connexion existant ou en crée un nouveau
  ReliableUdpConnectionRecord record = m_listOfHandlers.GetOrAdd(key, new ReliableUdpConnectionRecord(key, this, header.ReliableUdpMessageType));
  // lance le traitement du paquet dans la machine d'état
  record.State.ReceivePacket(record, header, bytes);
}

Réception du premier paquet et envoi de l'accusé de réception (état FirstPacketReceived) :

public override void ReceivePacket(ReliableUdpConnectionRecord connectionRecord, ReliableUdpHeader header, byte[] payload)
{
  if (!header.Flags.HasFlag(ReliableUdpHeaderFlags.FirstPacket))
    // rejetons le paquet
    return;
  // ...
  // par conception tous les numéros de paquet commencent à 0;
  if (header.PacketNumber != 0)
    return;
  // initialise le tableau pour stocker les parties du message
  ReliableUdpStateTools.InitIncomingBytesStorage(connectionRecord, header);
  // enregistre les données du paquet dans le tableau
  ReliableUdpStateTools.WritePacketData(connectionRecord, header, payload);
  // calcule le nombre de paquets qui doivent arriver
  connectionRecord.NumberOfPackets = (int)Math.Ceiling((double)((double)connectionRecord.IncomingStream.Length / (double)connectionRecord.BufferSize));
  // enregistre le numéro du dernier paquet reçu (0)
  connectionRecord.RcvCurrent = header.PacketNumber;
  // après cela, déplace la fenêtre de réception de 1
  connectionRecord.WindowLowerBound++;
  // passe à l'état suivant
  connectionRecord.State = connectionRecord.Tcb.States.Assembling;
  if (/*si le mécanisme de confirmation n'est pas requis*/)
  // ...
  else
  {
    // envoie l'accusé de réception
    ReliableUdpStateTools.SendAcknowledgePacket(connectionRecord);
    connectionRecord.WaitForPacketsTimer = new Timer(CheckByTimer, connectionRecord, connectionRecord.ShortTimerPeriod, -1);
  }
}

Plongée dans le code. Fermeture de la connexion par timeout

Le traitement des délais d'expiration est une partie importante de Reliable UDP. Considérons un exemple dans lequel un nœud intermédiaire a échoué et la livraison des données dans les deux directions est devenue impossible.
Diagramme de fermeture de connexion par délai d'expiration :

Comme le montre le diagramme, le minuteur de travail de l'expéditeur s'active immédiatement après l'envoi du bloc de paquets. Cela se produit dans la méthode SendPacket de l'état CycleEnvoi.
Activation du minuteur de travail (état SendingCycle) :

public override void SendPacket(ReliableUdpConnectionRecord connectionRecord)
{      
  // envoie un bloc de paquets   
  // ...   
  // redémarre le minuteur après l'envoi
  connectionRecord.WaitForPacketsTimer.Change(connectionRecord.ShortTimerPeriod, -1);
  if (connectionRecord.CloseWaitTimer != null)
    connectionRecord.CloseWaitTimer.Change(-1, -1);
}

Les périodes du minuteur sont définies lors de l'établissement de la connexion. Par défaut, ShortTimerPeriod est égal à 5 secondes. Dans l'exemple, il est fixé à 1,5 seconde.

Pour une connexion entrante, le minuteur se déclenche après la réception du dernier paquet de données reçu, ce qui se produit dans la méthode ReceivePacket de l'état. Assemblage
Activation du minuteur de travail (état Assembling) :

public override void ReceivePacket(ReliableUdpConnectionRecord connectionRecord, ReliableUdpHeader header, byte[] payload)
{
  // ... 
  // redémarre les minuteurs        
  connectionRecord.TimerSecondTry = false;
  connectionRecord.WaitForPacketsTimer.Change(connectionRecord.ShortTimerPeriod, -1);
  if (connectionRecord.CloseWaitTimer != null)
    connectionRecord.CloseWaitTimer.Change(-1, -1);
  // ...
}

Dans la connexion entrante, aucun paquet n'est arrivé pendant la période d'attente du minuteur de travail. Le minuteur a été déclenché et a appelé la méthode ProcessPackets, dans laquelle des paquets perdus ont été détectés et des demandes de retransmission ont été envoyées pour la première fois.
Envoi de demandes de retransmission (état Assembling) :

public override void ProcessPackets(ReliableUdpConnectionRecord connectionRecord)
{
  // ...        
  if (/* vérification des paquets perdus */)
  {
    // envoi des demandes de retransmission
    // réinitialisation du minuteur pour une deuxième tentative d'envoi
    if (!connectionRecord.TimerSecondTry)
    {
      connectionRecord.WaitForPacketsTimer.Change(connectionRecord.ShortTimerPeriod, -1);
      connectionRecord.TimerSecondTry = true;
      return;
    }
    // si après deux tentatives de WaitForPacketTimer 
    // les paquets n'ont pas été reçus - démarre le minuteur de fermeture de connexion
    StartCloseWaitTimer(connectionRecord);
  }
  else if (/* dernier paquet reçu et vérification réussie */)
  {
    // ...
    StartCloseWaitTimer(connectionRecord);
  }
  // si l'ack sur le bloc de paquets a été perdu
  else
  { 
    if (!connectionRecord.TimerSecondTry)
    {
      // renvoyer l'ack
      connectionRecord.WaitForPacketsTimer.Change(connectionRecord.ShortTimerPeriod, -1);
      connectionRecord.TimerSecondTry = true;
      return;
    }
    // démarre le minuteur de fermeture de connexion
    StartCloseWaitTimer(connectionRecord);
  }
}

La variable TimerSecondTry s'est établie à true. Cette variable est responsable du redémarrage du minuteur de travail.

Du côté de l'expéditeur, le minuteur de travail se déclenche également et le dernier paquet envoyé est renvoyé.
Activation du minuteur de fermeture de connexion (état SendingCycle) :

public override void ProcessPackets(ReliableUdpConnectionRecord connectionRecord)
{
  // ...        
  // renvoyer le dernier paquet 
  // ...        
  // démarrer le minuteur CloseWait – pour attendre la récupération de la connexion ou sa fermeture
  StartCloseWaitTimer(connectionRecord);
}

Après quoi un minuteur de fermeture de connexion est lancé dans la connexion sortante.
ReliableUdpState.StartCloseWaitTimer :

protected void StartCloseWaitTimer(ReliableUdpConnectionRecord connectionRecord)
{
  if (connectionRecord.CloseWaitTimer != null)
    connectionRecord.CloseWaitTimer.Change(connectionRecord.LongTimerPeriod, -1);
  else
    connectionRecord.CloseWaitTimer = new Timer(DisposeByTimeout, connectionRecord, connectionRecord.LongTimerPeriod, -1);
}

La période d'attente du minuteur de fermeture de connexion est par défaut de 30 secondes.

Après un court laps de temps, le minuteur de travail côté récepteur se déclenche à nouveau, des demandes sont envoyées, après quoi le minuteur de fermeture de connexion de la connexion entrante est lancé.

Lors de l'activation des minuteurs de fermeture, toutes les ressources des deux enregistrements de connexion sont libérées. L'expéditeur signale une livraison échouée à l'application supérieure (voir l'API Reliable UDP).
Libération des ressources de l'enregistrement de connexion :

public void Dispose()
{
  try
  {
    System.Threading.Monitor.Enter(this.LockerReceive);
  }
  finally
  {
    Interlocked.Increment(ref this.IsDone);
    if (WaitForPacketsTimer != null)
    {
      WaitForPacketsTimer.Dispose();
    }
    if (CloseWaitTimer != null)
    {
      CloseWaitTimer.Dispose();
    }
    byte[] stream;
    Tcb.IncomingStreams.TryRemove(Key, out stream);
    stream = null;
    Tcb.OutcomingStreams.TryRemove(Key, out stream);
    stream = null;
    System.Threading.Monitor.Exit(this.LockerReceive);
  }
}

Plongée dans le code. Récupération des données

Diagramme de récupération de transmission de données en cas de perte de paquet :

Comme déjà abordé dans la fermeture de la connexion par délai d'attente, à l'expiration du minuteur de travail, le récepteur effectuera une vérification des paquets perdus. En cas de pertes de paquets, une liste des numéros de paquets non reçus sera établie. Ces numéros sont ajoutés au tableau LostPackets de la connexion spécifique et des demandes de retransmission sont envoyées.
Envoi de demandes de retransmission de paquets (état Assembling) :

public override void ProcessPackets(ReliableUdpConnectionRecord connectionRecord)
{
  //...
  if (!ReliableUdpStateTools.CheckForNoPacketLoss(connectionRecord, connectionRecord.IsLastPacketReceived != 0))
  {
    // il y a des paquets perdus, nous envoyons des demandes pour eux
    foreach (int seqNum in connectionRecord.LostPackets)
    {
      if (seqNum != 0)
      {
        ReliableUdpStateTools.SendAskForLostPacket(connectionRecord, seqNum);
      }
    }
    // ...
  }
}

L'expéditeur recevra la demande de retransmission et renverra les paquets manquants. Il convient de noter qu'à ce moment-là, l'expéditeur a déjà lancé le minuteur de fermeture de connexion et, lors de la réception de la demande, il est réinitialisé.
Renvoi des paquets perdus (état SendingCycle) :

public override void ReceivePacket(ReliableUdpConnectionRecord connectionRecord, ReliableUdpHeader header, byte[] payload)
{
  // ...
  connectionRecord.WaitForPacketsTimer.Change(connectionRecord.ShortTimerPeriod, -1);
  // réinitialiser le minuteur de fermeture de la connexion 
  if (connectionRecord.CloseWaitTimer != null)
    connectionRecord.CloseWaitTimer.Change(-1, -1);
  // ...
  // c'est une demande de retransmission – nous envoyons le paquet requis          
  else
    ReliableUdpStateTools.SendPacket(connectionRecord, ReliableUdpStateTools.RetransmissionCreateUdpPayload(connectionRecord, header.PacketNumber));
}

Le paquet retransmis (packet#3 sur le diagramme) est reçu par la connexion entrante. Une vérification est effectuée pour remplir la fenêtre de réception et le transfert de données normal reprend.
Vérification de l'entrée dans la fenêtre de réception (état Assembling) :

public override void ReceivePacket(ReliableUdpConnectionRecord connectionRecord, ReliableUdpHeader header, byte[] payload)
{
  // ...
  // augmentons le compteur de paquets        
  connectionRecord.PacketCounter++;
  // enregistrons dans le tableau de contrôle de la fenêtre le numéro actuel du paquet        
  connectionRecord.WindowControlArray[header.PacketNumber - connectionRecord.WindowLowerBound] = header.PacketNumber;
  // définissons le plus grand paquet reçu        
  if (header.PacketNumber > connectionRecord.RcvCurrent)
    connectionRecord.RcvCurrent = header.PacketNumber;
  // redémarrons les minuteurs        
  connectionRecord.TimerSecondTry = false;
  connectionRecord.WaitForPacketsTimer.Change(connectionRecord.ShortTimerPeriod, -1);
  if (connectionRecord.CloseWaitTimer != null)
    connectionRecord.CloseWaitTimer.Change(-1, -1);
  // ...
  // si tous les paquets de la fenêtre sont reçus, réinitialisons le compteur
  // et envoyons le paquet d'accusé de réception
  else if (connectionRecord.PacketCounter == connectionRecord.WindowSize)
  {
    // réinitialisons le compteur.      
    connectionRecord.PacketCounter = 0;
    // décalage de la fenêtre de transmission
    connectionRecord.WindowLowerBound += connectionRecord.WindowSize;
    // réinitialisation du tableau de contrôle de la transmission
    connectionRecord.WindowControlArray.Nullify();
    ReliableUdpStateTools.SendAcknowledgePacket(connectionRecord);
  }
  // ...
}

API Reliable UDP

Pour interagir avec le protocole de transmission de données, il existe une classe ouverte Reliable Udp, qui est un wrapper autour du bloc de contrôle de transmission. Voici les membres les plus importants de la classe :

classe publique scellée ReliableUdp : IDisposable
{
  // récupère le point de terminaison local
  public IPEndPoint LocalEndpoint    
  // crée une instance de ReliableUdp et commence
  // à écouter les paquets entrants à l'adresse IP spécifiée
  // et au port. Une valeur de 0 pour le port signifie utiliser
  // un port attribué dynamiquement
  public ReliableUdp(IPAddress localAddress, int port = 0) 
  // abonnement pour recevoir des messages entrants
  public ReliableUdpSubscribeObject SubscribeOnMessages(ReliableUdpMessageCallback callback, ReliableUdpMessageTypes messageType = ReliableUdpMessageTypes.Any, IPEndPoint ipEndPoint = null)    
  // désabonnement pour arrêter de recevoir des messages
  public void Unsubscribe(ReliableUdpSubscribeObject subscribeObject)
  // envoyer un message de manière asynchrone 
  // Remarque : la compatibilité avec XP et Server 2003 est maintenue, car .NET Framework 4.0 est utilisé
  public Task SendMessageAsync(ReliableUdpMessage reliableUdpMessage, IPEndPoint remoteEndPoint, CancellationToken cToken)
  // commencer l'envoi asynchrone d'un message
  public IAsyncResult BeginSendMessage(ReliableUdpMessage reliableUdpMessage, IPEndPoint remoteEndPoint, AsyncCallback asyncCallback, Object state)
  // obtenir le résultat de l'envoi asynchrone
  public bool EndSendMessage(IAsyncResult asyncResult)  
  // libérer les ressources
  public void Dispose()    
}

La réception d'un message se fait par abonnement. La signature du délégué pour la méthode de rappel :

public delegate void ReliableUdpMessageCallback(ReliableUdpMessage reliableUdpMessage, IPEndPoint remoteClient);

Message :

public class ReliableUdpMessage
{
  // type de message, simple énumération
  public ReliableUdpMessageTypes Type { get; private set; }
  // données du message
  public byte[] Body { get; private set; }
  // si défini à true – le mécanisme de confirmation de livraison sera désactivé
  // pour l'envoi d'un message spécifique
  public bool NoAsk { get; private set; }
}

Pour s'abonner à un type de message spécifique et/ou à un expéditeur spécifique, deux paramètres optionnels sont utilisés : ReliableUdpMessageTypes messageType et IPEndPoint ipEndPoint.

Types de messages :

public enum ReliableUdpMessageTypes : short
{ 
  // Tout
  Any = 0,
  // Requête au serveur STUN 
  StunRequest = 1,
  // Réponse du serveur STUN
  StunResponse = 2,
  // Transmission de fichier
  FileTransfer = 3,
  // ...
}

L'envoi d'un message se fait de manière asynchrone, pour cela, un modèle de programmation asynchrone est implémenté dans le protocole :

public IAsyncResult BeginSendMessage(ReliableUdpMessage reliableUdpMessage, IPEndPoint remoteEndPoint, AsyncCallback asyncCallback, Object state)

Le résultat de l'envoi du message sera true – si le message a été correctement reçu par le destinataire et false – si la connexion a été fermée en raison d'un délai d'attente :

public bool EndSendMessage(IAsyncResult asyncResult)

Conclusion

Beaucoup de choses n'ont pas été décrites dans cet article. Les mécanismes de coordination des flux, le traitement des exceptions et des erreurs, et la mise en œuvre de méthodes asynchrones pour l'envoi de messages. Cependant, le noyau du protocole, la description de la logique de traitement des paquets, l'établissement de connexions et le traitement des délais d'expiration doivent être clarifiés pour vous.

La version du protocole de livraison fiable démontrée est suffisamment stable et flexible, répondant ainsi à certaines exigences définies précédemment. Cependant, je tiens à ajouter que l'implémentation décrite peut être améliorée. Par exemple, pour augmenter la bande passante et modifier dynamiquement les périodes des minuteries, des mécanismes tels que la fenêtre glissante et le RTT peuvent être ajoutés au protocole. Il serait également utile de mettre en œuvre un mécanisme de détermination de la MTU entre les nœuds de connexion (mais seulement en cas d'envoi de gros messages).

Merci de votre attention, j'attends vos commentaires et suggestions.

P.S. Pour ceux qui s'intéressent aux détails ou souhaitent simplement tester le protocole, voici le lien vers le projet sur GitHub :
Projet Reliable UDP

Liens utiles et articles

Spécification du protocole TCP : en anglais et en russe
Spécification du protocole UDP : en anglais et en russe
Discussion sur le protocole RUDP : draft-ietf-sigtran-reliable-udp-00
Reliable Data Protocol : rfc 908 et rfc 1151
Mise en œuvre simple de la confirmation de livraison par UDP : Prenez le contrôle total de vos réseaux avec .NET et UDP
Article décrivant les mécanismes de contournement des NAT : Communication entre pairs à travers des traducteurs d'adresses réseau
Mise en œuvre du modèle de programmation asynchrone : Implémentation du modèle de programmation asynchrone CLR et Comment implémenter le modèle de conception IAsyncResult
Transférer le modèle de programmation asynchrone vers un modèle asynchrone basé sur des tâches (APM en TAP) :
TPL et programmation asynchrone traditionnelle .NET
Interopérabilité avec d'autres modèles et types asynchrones

Mise à jour : Merci mayorovp et sidristij pour l'idée d'ajouter une tâche à l'interface. La compatibilité de la bibliothèque avec les anciens systèmes d'exploitation n'est pas compromise, car le framework 4 prend en charge XP et le serveur 2003.

Source : habr.com

Implémentation du protocole Reliable Udp pour .Net