J'envisage d'utiliser SCTP au lieu de TCP pour une application p2p écrite en C. Dois-je le faire? Aussi, comment la vitesse de SCTP se compare-t-elle à la vitesse de TCP?Est-ce que SCTP est bon pour les applications peer-to-peer?
EDIT: J'ai trouvé que SCTP can be tunneled over UDP avec le seul problème étant tunneled SCTP n'est pas interopérable avec SCTP non-tunnel.
Si c'est pour un réseau local, allez-y. Notez toutefois que si vous envisagez de l'utiliser sur Internet ouvert, de nombreux pare-feu grand public ne sont pas suffisamment flexibles pour permettre l'utilisation de protocoles IP non reconnus.
Comment ça vous aide?
Vous êtes P2P, donc chaque pair doit avoir au moins un socket ouvert à tous les autres pairs.
Si vous avez un socket ouvert, alors vous pouvez faire tout ce que vous devez faire par-dessus. Si vous avez pris l'approche d'un socket par fichier et que plusieurs fichiers sont transférés simultanément entre deux homologues, SCTP vous fera économiser un socket par fichier. Cependant, sur un réseau P2P normal de n'importe quelle taille, vous aurez presque jamais avoir plusieurs fichiers en cours de transfert simultanément entre deux pairs.
Ayez juste un socket et avez votre propre petit protocole; envoyer un paquet avec un en-tête, l'en-tête indique un type de contenu, par ex. une commande, ou une partie d'un fichier - et si oui, quel fichier, et quelle gamme d'octets.
Bien sûr, vous obtenez un peu de surcharge pour cela, alors que si vous avez un socket pour les commandes et un par fichier, vous êtes plus efficace. L'enregistrement d'une socket par pair (en supposant un téléchargement à la fois) vaut-il le temps/la complexité de l'utilisation de SCTP?
Une fois que j'aurai appris tous les tenants et les aboutissants de SCTP, je pense qu'il serait plus simple d'utiliser SCTP parce qu'il prend soin de beaucoup de problèmes pour moi, tels que la tolérance aux pannes. SCTP a des en-têtes de paquets plus petits (à ma connaissance), ce qui réduirait les frais généraux de nombreuses petites requêtes. – andreasw
La perte de paquets est un événement si rare qu'elle ne justifie pas l'utilisation de SCTP sur TCP; tout ce que vous gagnez est un couple de secondes de débit continu sur les autres connexions, * si * vous transférez simultanément plusieurs fichiers au même pair. –
En ce qui concerne les petits en-têtes - je suppose que vous finirez par utiliser UDP de toute façon. Si vous avez cinq ou dix mille pairs en file d'attente, vous ne disposerez pas d'un socket TCP/SCTP ouvert à tous. Vous resterez simplement en contact avec le paquet UDP impair de temps en temps. –
Avez-vous examiné si vos systèmes cibles seraient tous préinstallés sur SCTP ou si votre application devrait inclure SCTP elle-même? Dans mon expérience je ne m'attendrais pas à ce que tous les systèmes aient installé SCTP sur eux, et je m'attendrais à ce qu'ils ne le fassent pas si c'était Windows. Si vous incluez SCTP dans l'application elle-même, cela fera plus que doubler le nombre de messages transmis dans un noyau, ce qui aura un impact sur les performances par rapport à l'utilisation du TCP pré-installé.
Avez-vous pensé aux avantages que vous attendez de SCTP? Vous avez mentionné la tolérance aux pannes, mais pour que cela fonctionne avec SCTP, il faut que l'application ait plusieurs ports Ethernet et adresses IP. Est-ce probable sur votre application?
Autant j'aime SCTP (!), Je considérerais sérieusement rester avec TCP, sauf si vous êtes sûr que SCTP est nécessaire ou si vous contrôlez les hôtes sur lesquels votre application est déployée.
Observe
OP a également demandé à propos de SCTP tunnelisé sur UDP, cela résout le problème avec les pare-feu? Qu'en est-il de la perforation pour NAT traversal? est-ce possible dans le cas de SCTP? –
Tunneling permettrait de résoudre le problème de pare-feu. La perforation dépendrait du tunnel qui passe sur un port bien connu et constant. – Alnitak
Voir http://tools.ietf.org/html/draft-ietf-behave-sctpnat-05 pour l'état actuel de SCTP sur NAT et la proposition pour le corriger. SCTP a un mauvais support de protocole pour le moment, et le support réel mis en œuvre est pire - au point de ne pas fonctionner avec de nombreux appareils de qualité grand public. – Bwooce