Aller au contenu
STREAMING TEMPS RÉEL
AUCUN STOCKAGE
256 RÉCEPTEURS
PUT · POST · GET
CURL-NATIF
FANOUT
PROGRESSION SSE
PRÊT POUR LE E2E
STREAMING TEMPS RÉEL
AUCUN STOCKAGE
256 RÉCEPTEURS
PUT · POST · GET
CURL-NATIF
FANOUT
PROGRESSION SSE
PRÊT POUR LE E2E
STREAMING TEMPS RÉEL
AUCUN STOCKAGE
256 RÉCEPTEURS
PUT · POST · GET
CURL-NATIF
FANOUT
PROGRESSION SSE
PRÊT POUR LE E2E
STREAMING TEMPS RÉEL
AUCUN STOCKAGE
256 RÉCEPTEURS
PUT · POST · GET
CURL-NATIF
FANOUT
PROGRESSION SSE
PRÊT POUR LE E2E
PipeHOODY PIPE

Des named pipes à l'échelle d'Internet

POST sur un path. GET sur le même path. Les données circulent direct de l'émetteur au récepteur — sans buffering, sans upload, sans stockage. Juste du HTTP.

pipe · transfert en direct

Terminal A — Émetteur

$ curl -T report.pdf \

https://abc123-def456-pipe-1.node-us-1.containers.hoody.com/api/v1/pipe/report

[INFO] En attente d'un récepteur...

[INFO] Streaming vers 1 récepteur(s)...

[INFO] Transfert terminé.

Terminal B — Récepteur

$ curl https://abc123-def456-pipe-1.node-us-1.containers.hoody.com/api/v1/pipe/report \

-o report.pdf

% Total report.pdf

100 2.4M 100 2.4M 0 0 1.8M

Aucun stockage·Streaming temps réel·Jusqu'à 256 récepteurs·TTL 5 min
COMMENT ÇA MARCHE

Les données traversent, elles ne s'arrêtent pas

Chaque byte que vous envoyez arrive aux récepteurs en temps réel. Le serveur est un fil, pas un entrepôt.

SOURCE

émetteur

PUT / POST/pipe/{path}

PIPE SERVER

aucun stockage · jusqu'à 256 récepteurs

GET/pipe/{path}

SINK

récepteur

01

L'émetteur s'ouvre

L'émetteur fait POST ou PUT sur n'importe quel path. Le serveur attend — jusqu'à 5 minutes — qu'un récepteur se connecte.

02

Les bytes traversent

Les données streament byte par byte sur le fil. Aucun buffering. Aucun fichier temporaire. Aucune étape d'upload.

03

Les récepteurs se connectent

Les récepteurs font GET sur le même path et tirent le stream en direct. Jusqu'à 256 récepteurs peuvent fanout depuis un seul émetteur.

RECETTES

Compositions Pipe courantes

La plupart des recettes tiennent en deux commandes curl — une pour envoyer, une pour recevoir.

#1

Transfert de fichiers

Livraison peer-to-peer, sans stockage intermédiaire.

émetteur → récepteur

$ curl -T report.pdf …/pipe/report

# curl …/pipe/report -o report.pdf

#2

Stream de logs en direct

Tail les logs d'un conteneur en temps réel depuis n'importe quel terminal.

émetteur → récepteur

$ tail -f app.log | curl -T - …/pipe/logs

# curl …/pipe/logs

#3

Partage d'écran

Stream un bureau vers jusqu'à 10 spectateurs. Sans WebRTC.

émetteur → récepteur

$ ffmpeg … | curl -T - …/pipe/screen?n=10

# browser: …/pipe/screen?n=10&video

#4

Sync de répertoire

Pack, stream et unpack une arborescence dans un seul pipeline.

émetteur → récepteur

$ tar czf - ./project | curl -T - …/pipe/proj

# curl …/pipe/proj | tar xzf -

#5

Transfert chiffré

E2E chiffré — le serveur ne voit jamais le clair.

émetteur → récepteur

$ openssl enc … < secret.doc | curl -T - …/pipe/enc

# curl …/pipe/enc | openssl enc -d …

#6

Diffusion fan-out

Distribue un artefact de build à exactement 3 consommateurs simultanément.

émetteur → récepteur

$ curl -T build.zip …/pipe/release?n=3

# curl …/pipe/release?n=3 (×3 receivers)

#7

Spectateur de progression (3 parties)

Observe vitesse, ETA et bytes sans consommer un slot de récepteur.

émetteur → récepteur

$ curl -T dataset.tar.gz …/pipe/ds (sender)

# curl …/pipe/ds + browser: …/pipe/ds?progress

PROTOCOLES & CONTENU

Ce qui peut traverser un Pipe

Tout Content-Type non exécutable comme script passe verbatim. Les MIME dangereux sont réécrits en text/plain — la donnée n'est pas perdue, le XSS est prévenu.

application/octet-streamPUT → GET

Fichiers binaires, archives, images

/api/v1/pipe/{path}
text/plainPOST → GET

Logs, stdin, config, streams stdout

/api/v1/pipe/{path}
multipart/form-dataPOST → GET

Upload de fichier navigateur (première partie seulement)

/api/v1/pipe/{path}
video/webm, video/mp4PUT → navigateur

Partage d'écran, vidéo enregistrée

/api/v1/pipe/{path}?video
text/event-stream (SSE)GET spectateur

Suivi de progression, vitesse/ETA/état

/api/v1/pipe/{path}?progress
text/html (réécrit)PUT → GET

Réécrit en text/plain avant forward — XSS prévenu, donnée préservée

/api/v1/pipe/{path}
Headers personnalisésPUT → GET

Métadonnées X-Hoody-Pipe, X-Piping forwardées

/api/v1/pipe/{path}

Tous les endpoints vivent sur /api/v1/pipe/[path]. La direction décrit qui écrit, qui lit.

LIMITES

Conçu pour le volume

Limites strictes appliquées par serveur. HTTP 429 quand la capacité est pleine, HTTP 414 quand les paths sont trop longs.

#1

256

Récepteurs max sur un seul path

#2

1,000

Connexions en attente non établies

#3

1,000

Streams simultanés en cours

#4

5 min

TTL avant éviction HTTP 408

#5

1,024

Longueur max d'un path en caractères

API

9 endpoints, deux commandes qui comptent

POST ou PUT pour envoyer. GET pour recevoir. Tout le reste, c'est de l'observabilité.

Observabilité & UI

6 endpoints

GET /api/v1/pipe/health 200 { status, service, built, started, memory, … }

GET
/api/v1/pipe/healthJSON : status, version, activePipes
GET
/api/v1/pipe/versionChaîne de version en texte brut
GET
/api/v1/pipe/helpExemples curl auto-hébergés
GET
/api/v1/pipeUI web navigateur pour uploads no-code
GET
/api/v1/pipe/noscriptUI de repli pour navigateurs sans JS
OPTIONS
/api/v1/pipe/{path}Préflight CORS

Transfert de données

3 endpoints

POST ou PUT pour envoyer · GET pour recevoir

POST
/api/v1/pipe/{path}Envoie des données ; renvoie le statut [INFO] en stream à l'émetteur
PUT
/api/v1/pipe/{path}Alias de POST ; naturel pour curl -T file
GET
/api/v1/pipe/{path}Reçoit des données ; bloque jusqu'à ce que l'émetteur se connecte

À deux commandes curl près

Pas de SDK. Pas de setup d'auth. Pas de limite de taille de fichier. Lancez un conteneur Pipe et commencez à transférer.

Lire la doc