Yoltie en particulier et certains en général se sont montrés intéressés par la partie dédiée au réseau de Raydium.. Voiçi un état des lieux actuel:
Protocole non connecté UDP, serveur sur le port 29104, des paquets de taille moyenne (de l'ordre de 64, 128 ou 512 octets par trame).
L'API permet donc de lancer un serveur en une ligne, de connecter un client avec la même simplicité, l'échange d'infos (client->serveur et serveur->clients) se fait très simplement en transmettant des chaines de caractères décalées d'un offset précis (pour que Raydium y glisse ses en-têtes) avec possibilité de broadcast-over-IP.
Cette partie (protocole de bas niveau) me semble suffisante, mais là ou il y'a bcp de choses à faire et à tester, c'est sur la couche du dessus.. les tests déjà menés utilisaient le principe suivant:
client:
n'envoi des infos que lors d'une reception d'info du serveur
serveur:
n'envoi des infos à un client qu'en cas de reception d'infos depuis ce client avec un broadcast toutes les 5 secondes.
Le tout est fait avec des lectures "flushée", autrement dit, seul le dernier paquer reçu est traité.
Les intérêts de modèles sont les suivants:
- pas d'engorgements: le traffic se fait de manière régulière, de manière "polie", en somme
- le broadcast permet, puisque nous travaillons avec UDP, de relancer l'échange entre le client et le serveur si un paquet s'est "perdu" en route, et ce tt les 5 secondes
Le prb, c'est que dans ce modèle, plus la liaison est lente, plus le lag va augementer fortement ! (pas de manière proportionnelle, précisement), contrairement à un envoi régulier d'informations (du style: moi j'envoie des infos tt les 300 ms, tant pis si ca arrive pas ou si ca coince), plus dangereux, mais supportant mieux le lag, je pense.. bref, y'a des choses à voir de ce coté là.
Si qq1 veux coordonner ces tests et fouiller un peu le module reseau, voire trouver la méthode idéale pour les échanges réseaux .... C'est ici qu'il faut le dire
![Wink ;)](./images/smilies/icon_wink.gif)