Comment SignalR fonctionne en interne?

Question

Quelqu'un peut-il me faire savoir comment SignalR fonctionne en interne de manière à haut niveau?

Je suppose qu'il est le rinçage des données à l'aide Response.Flush et à côté client, il envoie les requêtes Ajax à certains intervalles. Est-il exact?

Answer 1

Non, SignalR est une abstraction sur une connexion. Il vous donne deux modèles de programmation sur cette connexion (hubs et connexions persistantes). SignalR a un concept de transport, chaque transport décide comment les données sont envoyées / reçues et comment il se connecte et se déconnecte.

SignalR a quelques construit dans les transports:

1. WebSockets
2. Serveur Événements ENVOYÉ
3. Pour toujours Cadre
4. Long vote

SignalR essaie de choisir le « meilleur » connexion pris en charge par le serveur et le client (vous pouvez aussi le forcer à utiliser un transport spécifique).

C'est le haut niveau. Si vous voulez voir comment chaque transport est mis en œuvre, vous pouvez consulter le code source .

Il y a aussi le code client pour chaque transport: https://github.com/SignalR/SignalR/tree/master/ src / Microsoft.AspNet.SignalR.Client.JS

Si vous vous demandez comment le temps de transport de vote fonctionne notamment:

Il envoie une requête au serveur ajax qui attend de manière asynchrone pour un signal pour répondre. Quand il y a un signal ou les temps de requête sur, elle retourne à partir du serveur et envoie une autre demande et le processus se poursuit. (Je suis parti quelques détails sur la façon dont le client, il garde la trace de ce qu'il a vu il ne pas manquer les messages)

Il faut espérer que la plupart des réponses de votre question.

Answer 2

@davidfowl a déjà répondu à la majeure partie. Cependant, pour fournir quelques détails au sujet de la différence de comportement des transports, en particulier entre WebSocket et d'autres moyens de transport; ci-dessous quelques points.

• WebSocket est le seul transport qui établit une véritable persistante, une connexion bidirectionnelle entre le client et le serveur. Cependant, WebSocket est uniquement pris en charge par IIS 8 ou au-dessus, et les dernières versions d'Internet Explorer, Google Chrome et Mozilla Firefox.
• Alors que le serveur Sent Events, toujours cadre et long sondage, les trois suivent une communication à sens unique, et sont pris en charge par la plupart des navigateurs.