Terminez d'abord "Diffusion d'événements et intégration avec une API REST" pour débloquer cette leçon.Aller à la leçon précédente

Introduction

Socket.IO est une bibliothèque construite par-dessus le protocole WebSocket qui ajoute des fonctionnalités conviviales pour les développeurs, indisponibles dans les WebSockets bruts. Lorsqu'on développe des fonctionnalités temps réel comme des applications de chat, des éditeurs collaboratifs ou des dashboards en direct, on a souvent besoin de regrouper logiquement les clients, d'isoler les canaux de communication et de gérer proprement les déconnexions. Socket.IO fournit les rooms, les namespaces, la reconnexion automatique et le repli de transport prêts à l'emploi, vous évitant ainsi de devoir concevoir tout cela vous-même.

Cette leçon parcourt chacune de ces quatre fonctionnalités avec du code concret. À la fin, vous saurez segmenter votre serveur en namespaces, regrouper dynamiquement les sockets dans des rooms, laisser les clients se reconnecter automatiquement, et compter sur le long-polling HTTP comme filet de sécurité lorsque les WebSockets sont bloqués.

Namespaces

Un namespace est un canal de communication séparé qui partage la même connexion TCP sous-jacente. Le namespace par défaut est `/`, mais vous pouvez en créer des personnalisés pour séparer logiquement les préoccupations — par exemple un chat public versus un panneau d'administration.

Côté serveur :

javascript
const io = require('socket.io')(3000);
const adminNamespace = io.of('/admin');
adminNamespace.on('connection', (socket) => {
console.log('Admin connected:', socket.id);
});

Côté client :

javascript
const adminSocket = io('/admin');
adminSocket.emit('admin-login', { user: 'alice' });

Tout ce qui est envoyé via le namespace `/admin` reste isolé du namespace `/` par défaut, même si les deux tournent sur le même serveur et le même port.

Rooms

Les rooms sont des sous-canaux à l'intérieur d'un namespace. Un socket peut rejoindre ou quitter une room à tout moment, et le serveur peut diffuser vers chaque socket d'une room en un seul appel. C'est le pattern adapté à la messagerie par conversation dans une application de chat, ou à l'état par salle de jeu dans un jeu multijoueur.

javascript
io.on('connection', (socket) => {
socket.on('join-room', (roomId) => {
socket.join(roomId);
socket.to(roomId).emit('user-joined', socket.id);
});
socket.on('chat-message', ({ roomId, message }) => {
io.to(roomId).emit('chat-message', { from: socket.id, message });
});
socket.on('disconnect', () => {
console.log('Socket left:', socket.id);
});
});

`socket.join(roomId)` ajoute le socket à un ensemble en mémoire maintenu par Socket.IO. `io.to(roomId).emit(...)` délivre ensuite le payload à chaque membre de cette room. Le socket qui rejoint ne reçoit pas les messages envoyés avec `socket.to(...)` — utilisez cette forme lorsque vous voulez notifier « tous les autres » dans la room.

schéma : 1 namespace contenant 3 rooms, chaque room ayant quelques clients, flèches de diffusion du serveur vers chaque room

Reconnexion automatique et repli de transport

Les WebSockets bruts cessent définitivement de fonctionner dès que le réseau tombe. Le client Socket.IO gère la reconnexion automatiquement. Vous pouvez configurer la stratégie de retry et informer l'utilisateur via des événements.

javascript
const socket = io({
reconnection: true,
reconnectionAttempts: 10,
reconnectionDelay: 1000,
reconnectionDelayMax: 5000,
});
socket.on('reconnect_attempt', (attempt) => {
console.log('Trying to reconnect, attempt', attempt);
});
socket.on('reconnect', (attemptNumber) => {
console.log('Reconnected after', attemptNumber, 'tries');
});
socket.on('connect_error', (err) => {
console.log('Connection failed:', err.message);
});

Le repli de transport est l'autre moitié de la résilience. Socket.IO tente toujours WebSocket en premier car c'est l'option la moins latente, mais si le handshake échoue — pare-feux d'entreprise, vieux proxies, réseaux restrictifs — il bascule silencieusement vers le long-polling HTTP. Le code applicatif ne change pas ; vos appels `emit` et `on` fonctionnent à l'identique sur l'un ou l'autre transport.

Pièges courants et résumé

Deux erreurs reviennent souvent. Premièrement, ne stockez pas l'appartenance aux rooms dans vos propres variables — faites toujours confiance à `socket.rooms` renvoyé par Socket.IO, car la bibliothèque gère join et leave en interne et votre cache se désynchronisera. Deuxièmement, gardez à l'esprit que `socket.to(roomId)` exclut l'émetteur tandis que `io.to(roomId)` l'inclut, choisissez donc celui qui correspond à votre intention de diffusion.

Pour résumer : les namespaces découpent votre serveur en canaux isolés, les rooms regroupent les sockets à l'intérieur d'un namespace pour des diffusions ciblées, la reconnexion automatique récupère les coupures réseau sans modification du code, et le repli de transport vous maintient en ligne même lorsque les WebSockets sont bloqués. Ensemble, ces fonctionnalités suppriment le boilerplate que vous devriez sinon écrire par-dessus les WebSockets bruts.

Entraînement

Point de contrôle de la leçon

Révisez la leçon et recevez des conseils sur votre travail.

0/1
Répondu · 0/1