Resolve "WS2Pv2: Implement ACK and OK messages processing"

added C-ws2p label

added 4 commits

b7c84a36...d1cca2ae - 2 commits from branch dev
8d2401f6 - [docs] dev: illustrate ws2p
a4c88aa3 - [feat] ws2p: implement and test ack and ok messages

added 1 commit

b1099a1d - cargo fmt

@HugoTrentesaux Félicitations tu a réussi plus rapidement que ce que je ne pensais à finir la négociation d'une connexion ! Je n'ai qu'une dizaine de remarques ce qui est très peu vu le fait que c'est ta 1ère contribution au code source en lui-même ^^

J'ai également des remarques générales mais bloquantes (donc qui doivent être traités) :

On ne fait pas de commit dédié a fmt, il faut amend ton commit :)
Le test actuel ne test que les cas passants. Il faudrait créer 1 ou plusieurs nouveaux tests qui vérifient que la connexion passe bien en Denial en cas te tentative d'usurpation. Il suffit par exemple de fournir au client un expected_full_id différent ;)

EDIT: Très bien ton schéma, il faudrait parler de son existence quelque par dans la doc pour développeurs :)

added 2 commits

9c667e40 - replace println -> debug
2db2cd02 - fix things

Compare with previous version

Ça m'embrouille beaucoup de faire un force push à chaque modification. Est-ce que ça te va si on change légèrement la méthode de travail ? J'aimerais faire des petits commits successifs qui prennent en compte tes relectures mais qui ne remplissent pas forcément les exigences pour être mergés. Et une fois que c'est bon, je réorganise tout, je rebase sur dev et on relit une dernière fois l'ensemble avant de merger.

À propos du test, j'ai essayé de remplacer

server_node_clone.my_key_pair.public_key(),

par

PubKey::Ed25519(keypair3().public_key()),

mais j'avais une erreur. En cherchant un peu, j'ai fini par écrire le test trivial :

fn test_connection_negociation_denial() {
    test_connection_negociation();
}

mais il échoue avec :

test test_connection_negociation_denial ... ok
test test_connection_negociation ... FAILED
thread 'test_connection_negociation' panicked at 'Not receive server controller sender'

autrement dit, le test passe la première fois, mais pas la deuxième... étrange.

Je regarderai ça plus tard.

added 1 commit

b287658f - moved update_status to handler

Compare with previous version

Ça m'embrouille beaucoup de faire un force push à chaque modification. Est-ce que ça te va si on change légèrement la méthode de travail ? J'aimerais faire des petits commits successifs qui prennent en compte tes relectures mais qui ne remplissent pas forcément les exigences pour être mergés. Et une fois que c'est bon, je réorganise tout, je rebase sur dev et on relit une dernière fois l'ensemble avant de merger.

Du coup j'ai essayé de me plier a ta méthode et ça m'embrouille de devoir gérer une relecture avec plein de commits superposés. Gitlab gère moins bien et ne m'affiche plus toutes les remarques dans l'onglet change. Je suis obligé d'aller chercher les anciennes remarques dans l'onglet discussion et gitlab ne me dit pas s'il y a eu une modif a cet endroit et du coup je ne peut pas voir si la modif fait conviens ou pas. Je suis obligé de mémoriser le fichier et numéro de ligne, puis d'aller vérifier dans kraken. Ça me prend beaucoup plus de temps. la ça ma pris plus d' 1h pour relire tes diff alor que ça m'aurais pris moins de 30 min si tu avait force push. Je veut bien m'adapter mais la je suis dsl ça va pas être possible cette façon de faire me fait perdre trop de temps :/

EDIT: J'ai dit ça sur le coup car j'étais frustré d'avoir perdu du temps. En vrai ça me demande d'apprendre une autre façon de travailler avec gitlab, une fois que j'aurais réadapter mes process comme il faut je devrait arriver a être aussi efficace, du coup on va expérimenter encore un temps comme ça puis je te dirai :)

autrement dit, le test passe la première fois, mais pas la deuxième... étrange.

Je n'ai pas compris ce que tu a essayé de faire avec les tests, le mieux serait que l'on voit ça en pair programming avec un partage de ton écran sur framatalk :)