Des closures React périmées
ProblèmeLes gestionnaires Socket.io gardaient une ancienne valeur du code de salon : les messages partaient dans le vide.
SolutionLes valeurs utilisées par les callbacks passent par des refs React, toujours à jour.
Retour au bureau
Dans le bureau : le téléphone
OsaDrop
Un code, un fichier, zéro serveur.
OsaDrop envoie des fichiers d'un appareil à l'autre avec un simple code à 6 caractères, un lien ou un QR code. Les fichiers vont directement d'un navigateur à l'autre : ils ne passent jamais par un serveur et ne sont stockés nulle part.
689lignes de code
64 Kopar morceau envoyé
1 Mode tampon maximum
0octet stocké sur le serveur
01Le point de départ
« Envoyer une photo de mon téléphone à un PC qui n'est pas le mien ne devrait pas demander un compte. »
AirDrop ne marche qu'entre appareils Apple. Les autres solutions passent par un cloud : on téléverse, on attend, on télécharge, et le fichier reste quelque part.
OsaDrop prend le chemin le plus court : les deux navigateurs se connectent directement en WebRTC. Le serveur ne sert qu'à les présenter l'un à l'autre, puis il n'entend plus parler du fichier.
02En images
À quoi ça ressemble.
03Comment ça marche
Sous le capot.
Deux phases : une courte présentation par le serveur, puis une conversation directe entre les deux appareils.
Un salon à deux
L'expéditeur choisit un ou plusieurs fichiers et reçoit un code, un lien et un QR code. Le serveur Socket.io crée un salon qui n'accepte que deux appareils.
La signalisation
Les deux navigateurs échangent leur offre, leur réponse SDP et leurs candidats ICE via le serveur. Un serveur STUN les aide à se trouver.
Le canal direct
Un DataChannel WebRTC s'ouvre entre eux, chiffré par défaut. Le serveur n'est plus utilisé.
Envoi par morceaux
Le fichier est découpé en morceaux de 64 Ko. Si plus de 1 Mo attend dans le tampon, l'envoi fait une pause jusqu'à ce qu'il se vide.
Reconstitution
Le destinataire assemble les morceaux, suit la progression, puis le fichier se télécharge tout seul.
✦À toi de jouer
Regarde un fichier voyager
Une simulation du vrai algorithme : le fichier part en morceaux de 64 Ko, et l'envoi s'arrête dès que le tampon dépasse 1 Mo. Décoche le contrôle de débit pour voir ce qui se passait avant le correctif.
!Les défis
Ce qui a résisté.
Le tampon qui déborde
ProblèmeEnvoyer un gros fichier d'un coup saturait la file du DataChannel et coupait le transfert.
SolutionContrôle de débit avec bufferedAmount et l'événement bufferedamountlow : on n'envoie que quand il y a de la place.
Des états qui se croisent
ProblèmeL'interface annonçait « connecté » avant que le canal soit vraiment ouvert.
SolutionL'interface ne suit plus que l'état réel du canal (readyState), avec un délai de garde en cas de silence.
⏱Journal de bord
Comment c'est arrivé.
Première implémentation WebRTC
Salon, signalisation et DataChannel.
Quatre correctifs en 20 minutes
Closures périmées, courses entre états, débordement de la file.
Transfert robuste
Délai de garde sur le flux et scanner de QR code.
Pont OsaNotch
Une page qui expose le même moteur à l'app macOS.
Documentation
README complet avec fonctionnement, déploiement et limites.
Nouvelle interface
Mascotte vivante, plusieurs fichiers à la fois, lien de partage et QR code qui ouvre la page déjà connectée.
Les mêmes codes partout
OsaNotch utilise aussi les codes à 6 caractères : un envoi depuis le site arrive dans le notch.
Astuce : les flèches ← → de ton clavier passent d'un projet à l'autre.