-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[TCP/scheduling] draft + scope #1
Comments
Alors déjà, pourquoi juste TCP? On pourrait facilement descendre en dessous. (+ UDP ?)
Pas d'accord. Faudrait limiter à du bas niveau (ASM/C/Rust/Go)
Tu pense à un truc en particulier?
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.
Pour moi ça n'a rien à faire en bonus part ça, c'est totalement mandatory, le projet à aucun interet sinon! |
TCP c'est deja un standard repandu donc cool de le voir en detail avant de reflechir a comment mieux faire.
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
d'accord avec Louis ca devrait etre mandatory. IMO ftp et irc auraient du l'etre aussi.
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. |
Pour moi ce qui n'est pas clair, par rapport au thread slack, c est ce que vient faire ZMQ dans TCP ?
Concrètement, qu'est ce que t'entendais par là ? Integrer des features ZMQ dans TCP ?
Je pensais aux features ZMQ mais apparement hors-sujet.
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. |
Je vais essayer de résumer ce que j'avais en tête, histoire que ce soit bien clair pour le débat. TCPPour 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:
Donc dans ce programme:
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 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:
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! |
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 ? ACK pr le reste |
Le problème de l'IPC dans Unix, c'est qu'il y a des milliards de façon de faire:
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. De plus, ZMQ à des bindings dans tout les langages du mondes, donc t'es pas obligé de faire du C pour tes applications. |
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
Generals Instructions
Mandatory part
Bonus part
@Ne02ptzero @jzck
The text was updated successfully, but these errors were encountered: