FR
RU
EN
ES
ZH
DE
PT
AR
HI
Appel long ou canal permanent : comment C# affiche les données en temps réel
\n\nImaginez : vous écrivez un chat en C#. Ou un terminal boursier. Ou un système de notifications. Le client attend des données — et il n'est pas prêt à attendre longtemps. Avant, les développeurs se débrouillaient comme ils pouvaient : ils mettaient des minuteurs, sollicitaient le serveur toutes les 5 secondes, multipliaient les requêtes inutiles. Aujourd'hui, nous avons deux approches civilisées — Long Polling et WebSocket. Toutes deux permettent au serveur d'envoyer des données au client sans demande explicite de sa part. Mais elles fonctionnent de manière fondamentalement différente.
\n\nDans cet article, nous analyserons comment implémenter les deux approches en C# (ASP.NET Core), les comparerons en termes de vitesse, de charge et de complexité, et comprendrons quoi choisir pour votre projet. C'est parti.
\n\nQu'est-ce que le Long Polling ? (Et pourquoi ce n'est pas magique)
\n\nLong Polling est une émulation du temps réel sur du HTTP classique. Le client envoie une requête au serveur, mais le serveur ne répond pas immédiatement. Il maintient la connexion ouverte jusqu'à ce qu'un nouvel événement se produise (ou que le délai d'attente expire). Dès que les données sont prêtes — le serveur envoie la réponse, le client la traite et ouvre immédiatement une nouvelle requête « longue ».
\n\nC'est une astuce astucieuse qui fonctionne sur n'importe quel serveur HTTP et dans n'importe quel navigateur. Mais elle a un coût : chaque connexion reste en mémoire sur le serveur, et si vous avez des milliers de clients, cela devient un problème.
\n\nExemple de Long Polling en C# (ASP.NET Core)
\n\nÉcrivons un contrôleur simple qui simule une file d'attente de notifications. Le client sollicite un endpoint, le serveur attend de nouvelles données (par exemple, depuis un canal Channel<string>) et les envoie.
using Microsoft.AspNetCore.Mvc;\nusing System.Threading.Channels;\n\n[ApiController]\n[Route("api/[controller]")]\npublic class NotificationsController : ControllerBase\n{\n private static readonly Channel<string> _channel = Channel.CreateUnbounded<string>();\n\n // Endpoint pour publier une notification (par exemple, depuis un autre service)\n [HttpPost("publish")]\n public async Task<IActionResult> Publish([FromBody] string message)\n {\n await _channel.Writer.WriteAsync(message);\n return Ok("Notification envoyée");\n }\n\n // Long Polling : le client attend jusqu'à ce qu'un nouveau message apparaisse\n [HttpGet("long-poll")]\n public async Task<IActionResult> LongPoll(CancellationToken cancellationToken)\n {\n // Attend un nouveau message ; s'il n'y en a pas, attend jusqu'à 30 secondes\n using var cts = CancellationTokenSource.CreateLinkedTokenSource(cancellationToken);\n cts.CancelAfter(TimeSpan.FromSeconds(30));\n\n try\n {\n var message = await _channel.Reader.ReadAsync(cts.Token);\n return Ok(new { data = message });\n }\n catch (OperationCanceledException)\n {\n // Délai d'attente expiré — renvoie une réponse vide, le client répétera la requête\n return Ok(new { data = (string?)null });\n }\n }\n}\nLe client (JavaScript) ressemblera à ceci :
\n\nasync function startLongPoll() {\n while (true) {\n const response = await fetch('/api/notifications/long-poll');\n const result = await response.json();\n if (result.data) {\n console.log('Nouvelle notification :', result.data);\n }\n // On commence immédiatement un nouveau poll\n }\n}\nstartLongPoll();\nTout est simple. Mais il y a un détail : si le serveur redémarre ou si le client perd la connexion, les données sont perdues. Le Long Polling ne garantit pas la livraison.
\n\nWebSocket : un tunnel bidirectionnel en C#
\n\nWebSocket est un protocole de communication bidirectionnelle complet sur TCP. Après une poignée de main (une requête HTTP GET standard avec mise à niveau), le client et le serveur communiquent directement, sans frais généraux d'en-têtes HTTP. Le serveur peut envoyer un message à tout moment, et le client le recevra instantanément.
\n\nDans ASP.NET Core, WebSocket est intégré nativement. Aucune bibliothèque externe n'est nécessaire (
