RE: [Tsp-devel] Mon buffer brésilien en string sur Internet

[PAGNOT Robert (EADS ASTRIUM)]

Quelle violence ... Ketatil fait le canard pour que tu veuilles le bouffer tout cru ?

Ceci est un complément aux remarques de notre cher Eric.

Salut à Tous!
Moi l'abstraction, c'est comme un canard clandestin le soir d'un dîner de
l'amical des chasseurs/douaniers : J'ai envie de tirer dessus juste pour
voir l'effet que cela fait. Donc je commence ...

1) Petit Bémol
==============
 L'échange de string ne sera pas uniquement limité au groupe asynchrone. Je
peux très bien être un gros neuneu d'utilisateur et vouloir sampler mes 1000
états sous forme de chaîne de caractère du genre "OK" ou "T'esFoutu" à
100Hz. Le provider ayant lui seul le pouvoir de convertir l'état en chaîne,
la protection que nous ayons c'est qu'il peut borner chaque symbole en
string à une taille max au retour du request_sample_init.
J'admets qu'un neuneu veuille recupérer un état "enumeré" à 100Hz comme un bouffon, mais TSP pourrait-il l'en empêcher, et refuser une sample-frequency débile de ce style ? Et limiter à quelque chose d'humain (quelques Hz) ou forcer en asynchrone. Si tu bornes la longueur, cela risque d'être inutilisable car les autres neuneus trouvent toujours le moyen de coder des trucs du style

        "TA-MERE-EN-SHORT-JE-LA-PRENDS-ET-JE-L'INSULTE", puis
        "TA-MERE-EN-SHORT-JE-LA-PRENDS-ET-JE-L'HABILLE", et qui si l'on limite la longueur à
        "TA-MERE-EN-SHORT-JE-LA-PRENDS-ET-JE-L"
                Bonjour les dégâts !

2) Postulat
===========
Le seul besoin coté client de FIFO, c'est pour gérer les retards TEMPORAIRES
du client dans la relecture => La socket n'est pas suffisante, mais je ne
sais plus pourquoi (128Ko / (1000 symboles *100Hz *8octets) me donne 125ms
de marge. C'est peu mais peux-t-on augmenter le buffer de la socket ?
=> Je pourrais construire au retour du request_sample_init. un gros tableau
circulaire de n structures de request_sample. Ainsi je pourrais stocker n
fois des données issus du protocole. Si je prends n > p*freq de sampling,
j'obtient au moins p secondes de répit pour le client. Avec les données
issues de la théorie des groupes de fréquences, je saurais dire à chaque
step lesquelles données ont été mise à jour pour les rendre au client. C'est
quasiment 0h en codage, et cela simplifie en plus l'écriture d'un archiveur
brut de protocole TSP.
D'accord avec les remarques d'Eric ....

3) Gros gourmand !
==================
Gros gourmand me direz vous, tu utilise bien trop de mémoire que nécessaire,
car à certains step, juste une portion infime des données seront mise à jour
(genre les 1% de variables à haute fréquence). Certes, mais si je prends
quelques chiffres, cela n'est pas énorme : 1 secondes * 10000 symboles *
100Hz * 10octets (je prends une valeur moyenne de taille des symboles) me
donne 1Mo de mémoire : Une paille pour un client sur les machines
actuelles....
D'accord avec les remarques d'Eric ....

4) Hérésie !!!
==============
J'irais même plus loin. Si je consomme trop de mémoire, c'est à cause de ce
putain de demande de mettre différentes fréquences dans une même connexion.
Si je dis "Une connexion TSP = 1Frequence*1Phase", je me débarrasse de la
théorie des groupes (je ne l'ai jamais aimé d'abord), je simplifie le codage
du core, et j'ai un mécanisme super simple optimum des buffers !!! De plus
tous les clients actuels ne demande qu'une seule fréquence, donc c'est
pareil. Avec cet affirmation, je suis sur d'aller au bucher des hérétiques
de TSP. Qui veut jouer le rôle de Torquemada ???
Torquemada, lui, avait il un assistant, genre bourreau ???? Si oui, je veut bien prendre le rôle, sinon, il faudrait modifier les livres d'histoire !

5) Pour les puristes
====================
Si vraiment le coté multi-fréquence vous tient à coeur, on peut le masquer
au client en découpant sa requête avec plusieurs groupe de même
fréquence/phase par autant de connections. Et je suis sur qu'on aura pas
beaucoup de clients qui dépasseront les 10 sockets par session. Peut-être
cela va-t-il acheter mon absolution ?
Alors là, si tu parjures ....

Souvenez-vous du choix que l'on a dû faire pour rendre les données au client parmi trois solutions :

• un Méga-RingBuf fourre-tout (ce qui a été fait),
• un Méga-nombre de petits RingBuf (un pour chaque variable),
• une solution intermediaire avec un RingBufs pour chaque fréquence (optimisation d'après le groupage fréquentiel des données !).

Peut-être vaut-il la peine d'y repenser ????

Bon le Golgothe est lâché, à vos clavier, mais pitié ne tapez pas trop fort
sur le pianiste, je suis déjà assez handicapé mental comme cela. Tout ceci
n'est qu'un pavé dans la mare pour faire peur aux canards, et non pas un
diktat de l'admin TSP, surtout que je n'ai toujours pas réactivé ma
connexion SSL.
Moi, je ne l'ai jamais eu. Mais j'espère que mon futur retour à Astrium me permettra de replonger dans l'aquarium TSP avec les requins et autres canards :-)

        Votre (déporté) serviteur,
                Robert