Partager via

Envoi et réception de données PGM

  • Article

L’envoi et la réception de données PGM sont similaires à l’envoi ou à la réception de données sur n’importe quel socket. Il existe des considérations spécifiques à PGM, décrites dans les paragraphes suivants.

Envoi de données PGM

Une fois qu’une session d’expéditeur PGM est créée, les données sont envoyées à l’aide des différentes fonctions d’envoi des sockets Windows : send, sendto, WSASend et WSASendTo. Étant donné que les handles de sockets Windows sont des handles de système de fichiers, d’autres fonctions telles que writeFile et CRT peuvent également transmettre des données. L’extrait de code suivant illustre une opération d’expéditeur PGM :

LONG        error;
    //:
error = send (s, pSendBuffer, SendLength, 0);
if (error == SOCKET_ERROR)
{
    fprintf (stderr, "send() failed: Error = %d\n",
             WSAGetLastError());
}

Lorsque vous utilisez le mode message (SOCK_RDM), chaque appel à une fonction d’envoi génère un message discret, ce qui n’est parfois pas souhaitable ; une application peut vouloir envoyer un message de 2 mégaoctets avec plusieurs appels à envoyer. Dans ce cas, l’expéditeur peut définir l’option de socket RM_SET_MESSAGE_BOUNDARY pour indiquer la taille du message qui suit.

Si la fenêtre d’envoi est pleine, un nouvel envoi à partir de l’application n’est pas accepté tant que la fenêtre n’a pas été avancée. La tentative d’envoi sur un socket non bloquant échoue avec WSAEWOULDBLOCK ; un socket bloquant se bloque simplement jusqu’à ce que la fenêtre avance au point où les données demandées peuvent être mises en mémoire tampon et envoyées. Dans les E/S qui se chevauchent, l’opération ne se termine pas tant que la fenêtre n’avance pas suffisamment pour prendre en charge les nouvelles données.

Réception de données PGM

Une fois qu’une session de récepteur PGM est créée, les données sont reçues à l’aide des différentes fonctions de réception des sockets Windows : recv, recvfrom, WSARecv et WSARecvFrom. Étant donné que les handles de sockets Windows sont également des handles de fichier, les fonctions ReadFile et CRT peuvent également être utilisées pour recevoir des données de session PGM. Le transport transfère les données jusqu’au récepteur à mesure qu’elles arrivent tant que les données sont dans l’ordre. Le transport garantit que les données retournées sont contiguës et exemptes de doublons. L’extrait de code suivant illustre une opération de réception PGM :

LONG        BytesRead;
    //:
BytesRead = recv (sockR, pTestBuffer, MaxBufferSize, 0);
if (BytesRead == 0)
{
    fprintf(stdout, "Session was terminated\n");
}
else if (BytesRead == SOCKET_ERROR)
{
    fprintf(stderr, "recv() failed: Error = %d\n",
            WSAGetLastError());
}

Lorsque vous utilisez le mode de message (SOCK_RDM), le transport indique quand un message partiel est reçu, soit avec l’erreur WSAEMSGSIZE, soit en définissant l’indicateur MSG_PARTIAL lors du retour des fonctions WSARecv et WSARecvFrom . Lorsque le dernier fragment du message complet est retourné au client, l’erreur ou l’indicateur n’est pas indiqué.

Lorsque la session se termine correctement, l’opération de réception échoue avec WSAEDISCON. Lorsque la perte de données se produit dans le transport, PGM met temporairement en mémoire tampon les paquets hors séquence et tente de récupérer les données perdues. Si la perte de données est irrécupérable, l’opération de réception échoue avec WSAECONNRESET et la session est terminée. La session peut être réinitialisée en raison de diverses conditions, notamment les suivantes :

  • Le récepteur ou le débit de connexion entrant est trop lent pour suivre le rythme du débit de données entrant.
  • Une perte excessive de données se produit, peut-être en raison de conditions réseau temporaires, telles que des problèmes de routage, une instabilité du réseau, etc.
  • Une erreur irrécupérable se produit sur l’expéditeur.
  • L’utilisation excessive des ressources se produit sur l’ordinateur local, comme le dépassement du stockage tampon interne maximal autorisé ou la rencontre d’une condition de ressources insuffisantes.
  • Une erreur de cohérence des données case activée se produit.
  • L’échec dans un PGM de composant dépend de, par exemple tcp/IP ou sockets Windows.

Le premier et le deuxième élément de la liste ci-dessus peuvent faire en sorte que le destinataire effectue une mise en mémoire tampon excessive avant de manquer de ressources, ou avant de se déplacer au-delà de la fenêtre de l’expéditeur.

Fin d’une session PGM

L’expéditeur ou le récepteur PGM peut arrêter d’envoyer ou de recevoir des données en appelant closesocket. Le récepteur doit appeler closesocket sur les sockets d’écoute et de réception pour éviter les fuites de handle. L’appel de l’arrêt sur l’expéditeur avant d’appeler closesocket garantit que toutes les données sont envoyées et que les données de réparation sont conservées jusqu’à ce que la fenêtre d’envoi passe au-delà de la dernière séquence de données, même si l’application elle-même se termine.