[TCP/scheduling] draft + scope

[ariard]

Intro

Decouvrir le monde du networking low-level en designant sa propre stack OSI, level 4 et 5 ( soit TCP et ZMQ) ?
apprendre les tradeoff entre reliabilite et performance + scheduling

Goals

• ecrire une stack TCP-like
• developper algo scheduling/congestion
• ecrire une API accessibles aux applications

Generals Instructions

• userland
• libpcap pour simuler/tester ?
• langage libre ?

Mandatory part

• stack doit ouvrir/fermer proprement une connexion meme en cas de pair qui deconne
• packetiser les payload dans IP
• duplex channel
• stack doit etre reliable et transmettre l'integralite de la data
• mecanisme de congestion en cas d afflux soudain de traffic
• stack doit supporter plusieurs connexions sur une seule socket
• checksum

Bonus part

• compatible RFC
• zmq-like features

@Ne02ptzero @jzck

[Ne02ptzero]

Alors déjà, pourquoi juste TCP? On pourrait facilement descendre en dessous. (+ UDP ?)

langage libre ?

Pas d'accord. Faudrait limiter à du bas niveau (ASM/C/Rust/Go)

stack doit supporter plusieurs connexions sur une seule socket

Tu pense à un truc en particulier?

checksum

Généralement c'est la carte réseau qu'il le fait pour IP + TCP, jsais pas si c'est une bonne idée de le foutre la dedans.

compatible RFC

Pour moi ça n'a rien à faire en bonus part ça, c'est totalement mandatory, le projet à aucun interet sinon!

[jzck]

Pourquoi TCP?

TCP c'est deja un standard repandu donc cool de le voir en detail avant de reflechir a comment mieux faire.

langage libre ?

Pas d'accord. Faudrait limiter à du bas niveau (ASM/C/Rust/Go)

d'accord mais si le but c'est de faire scheduling il faut interdire les libs externes (je pense a libevent(et cousins) pour le C et a Tokio/mio pour rust) je ne m'y connais pas assez mais le go ne va-t-il pas premacher le travail de concurrence? C/Rust ok pour moi

compatible RFC

d'accord avec Louis ca devrait etre mandatory. IMO ftp et irc auraient du l'etre aussi.

checksum

on pourrait faire un projet entier de bit fiddling et astuces bas niveau pour augmenter les perf des operations frequentes comme celle-ci, mais ici out of scope je pense.

Est-ce qu'il faut rajouter une section benchmarks? comme le throughput ou le nombre de connection simultanees etc... ca fait un peu lourd de mettre ca en correction ou de faire tourner une vm de 42 expres, mais c'est dur pour un correcteur de faire quoi que ce soit face a une stack tcp, je pense qu'il faut regarder ce que font les stack tcp FOSS et obliger l'etudiant a faire un minimum de tests/benchs pour prouver ce qu'il a fait, quitte a lui fournir des scripts pour tracer des courbes.

[ariard]

Pour moi ce qui n'est pas clair, par rapport au thread slack, c est ce que vient faire ZMQ dans TCP ?
@jzck (#kernel) :

zeroMQ c'est cool pour pas avoir a faire la partie applicative mais il y a aussi toutes les features asynchrones de zmq qui sont le coeur du projet , alors il faudrait autoriser seulement la moitie de zmq?"

Concrètement, qu'est ce que t'entendais par là ? Integrer des features ZMQ dans TCP ?
Si non, alors obvious TCP compatible avec la RFC pour scope du projet

Tu pense à un truc en particulier?

Je pensais aux features ZMQ mais apparement hors-sujet.

c'est dur pour un correcteur de faire quoi que ce soit face a une stack tcp

Tu peux fournir des séquences de packet poisonés et un launcher pour tester le handshaking, le closing, la non-responsiveness et donc le respect du protocole sur les edges cases ?

Le benchmark ça serait cool il y a peu de projets de 42 (au moins en system) qui l'apprennent.
Mais est-ce possible d'évaluer les stacks tcp FOSS independamment de la stack IP ?

[Ne02ptzero]

Je vais essayer de résumer ce que j'avais en tête, histoire que ce soit bien clair pour le débat.

TCP

Pour TCP, on a un programme qui une entrée / sortie unique, dont le seul but est de parser un paquet TCP, et de router applicativement le paquet en question:

                                                               +----------------------------+
                                                               |                            |
                                                               |                            |
                                                               |                            |
+------------------------------+     +-------------------+     |                            |
|                              +----->                   +----->                            |
|     Entrée / Sortie          |     |    Stack TCP      |     |       Applications         |
| (Une espèce de carte réseau) <-----+                   <-----+                            |
|                              |     +-------------------+     |                            |
+------------------------------+                               |                            |
                                                               |                            |
                                                               +----------------------------+

Donc dans ce programme:

• Relation d'IO avec un acteur externe (Une carte réseau émulée, un programme qui lit un .pcap, etc)
• Parsing / Verification de l'intégrité d'un paquet TCP
• Routage Applicatif du paquet:
  • Maintient d'une table de connexion
  • DROP de paquets si jamais un handshake n'a pas eu lieu
  • Gérer les timeouts

Au délà de ça du coup, t'a la partie applicative pure, ou un programme doit pouvoir "bind" un port pour lui, si jamais il veut être atteint par l'extérieur. Je met bind entre guillemet parce qu'on est en userspace, du coup on peut pas overload le syscall bind, et les applications ne peuvent pas utiliser read/write pour lire sur la socket qui en résulte.

L'idée de ZMQ, c'est pour gérer cette communication là justement, entre la Stack TCP et les applications. Il faudrait un semili-protocole en place pour pouvoir demander un port, envoyer de la data, attendre de la data, et de-bind un port.

Au délà de toute ces mécaniques, y'aura des stress tests sur la stack pour voir si on:

• N'a pas de replay
• N'a pas de DROP de paquets
• Respecte bien le séquencage demandé par l'application

Dans l'idée la carte réseau serait fournie par nous, ainsi que quelques applications exemple sur en utilisant le protocole ZMQ, pour le début des tests.

J'espère que c'est plus clair du coup!

[ariard]

Ok, donc pour les simili-syscall (send, receive, open, status) entre stack TCP/user on pourrait "figer" une API dans le sujet comme ça on est libre de fournir des applications pour les tests ?
Par rapport à cette option-là, utiliser ZMQ me semble pas plus simple, à moins qu'il y ait des issues que j'ai pas vues ?

ACK pr le reste

[Ne02ptzero]

Par rapport à cette option-là, utiliser ZMQ me semble pas plus simple, à moins qu'il y ait des issues que j'ai pas vues ?

Le problème de l'IPC dans Unix, c'est qu'il y a des milliards de façon de faire:

• Signals,
• Anonymous Pipes
• Named Pipes or FIFOs
• SysV Message Queues
• POSIX Message Queues
• SysV Shared memory
• POSIX Shared memory
• SysV semaphores
• POSIX semaphores
• FUTEX locks
• File-backed and anonymous shared memory using mmap
• UNIX Domain Sockets
• Netlink Sockets
• Network Sockets
• Inotify mechanisms
• FUSE subsystem
• D-Bus subsystem

Le truc qui rentre également en jeu, c'est la gestion de la concurrence / locks dans l'IPC, parce qu'il va y en avoir besoin pour la Stack.
Je dit pas qu'on peut pas faire sans ZMQ, c'est juste que le sujet n'est pas sur l'IPC (Ça peut être un bon sujet d'ailleurs), donc si on peut éviter de se taper les problématiques de bases / merde dans le sujet en utilisant un truc qui gère tout à notre place, et se concentrer uniquement sur le cœur du sujet (la Stack TCP), je trouve ça mieux.

De plus, ZMQ à des bindings dans tout les langages du mondes, donc t'es pas obligé de faire du C pour tes applications.