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

[DUFRENNE, Yves]

C'est jour de gloire, je ne suis pas excommunié !!! Ok je suis d'accord pour dire que un flux à <> fréquences, c'est super, mais siouplait enlevez moi ce fer rouge de l'œil, je suis sensible à la conjonctivite.

 

Si je résume : On est tous d'accord pour dire que le client doit avoir une QoS (quel que soit le lien chaussette ou non) qui lui garantie un temps certain de bufferisation, sauf si il demande n'importe quoi à un pauvre provider embarqué. Comme le dit Robert, il y a plein de solutions de voir cette bufferisation. Je vais essayer de mieux expliquer la mienne, car Éric pourtant si brillant n'avait pas tout compris :

 

Définitions

Soit un Provider nommé Alphonse avec 10 000 symboles.

Un Client dit Roger demande 100 symboles entiers à 100Hz, et 900 autres de types quelconques (disons 800 doubles et 100 strings)

Implémentation coté P

Le provider construit une structure (genre par XDR ou autre truc) capable de stocker un instant cohérent de sampling, faite de 100 entier, puis 800 doubles, et 100 buffer de char, chacun ayant la longueur max d'une string retourné par le glue_serveur pour ces symboles). Puis le provider alloue N fois cette structure, pour en faire un joli tableau circulaire. Ceci lui autorisera une QoS coté serveur de N/frequenceMax secondes de tolérance aux pannes réseaux. Cette durée pouvant être configurée par le client dans le meilleur des mondes. 

Certes à certains instant du sampling, il n'y aura qu'une partie de la structure qui sera mise à jour. Mais je pense qu'un provider type "station" peut tout à fais tolérer ce gâchis. Si je reprends mon calcul, 1000 symboles d'une requête * 100 Hz * 10 octets moyens * 1 seconde de QoS me donne 1Mo de mémoire alloué, une paille.

Implémentation coté Client

Pour le client, la bufferisation sert à implémenter une QoS de second niveau. En effet, la bufferisation coté serveur peut-être suffisante pour éviter les pertes, puisqu'il va empiler de son coté. En rajouter une coté client sert à masquer le coté visible ("TSP ça lagge à mort") des trous reseaux, car on peut encore avoir du buffer à lire coté client. Cela sert aussi a permettre de coder une IHM comme un gros porc pendant que le thread client garantie qu'il continue à défiler le flux, même si quand une Cdt rame, tout le monde fait pareil... M'enfin si on veut garder cette bufferisation on peut utiliser le même truc que coté provider, la structure de sampling pouvant être retourner par RPC.

Implémentation si pas socket

Si un jour on a un system TSP sur VME ou mémoire partagée, ces 2 bufferisations (Provider+Client) pourrait même être fondues en une seule, modulo de la prudence ou quelques mutex dans les accès concurrents.

 

Voila j'espère avoir été plus clair, et m'être excusé auprès des canards de France et de Navarre, contre lequel je n'ai absolument rien si ce n'est un fort appétit pour le magret.

Y++

PS : Le trappeur de caribou est il encore présent sur TSP ? Je suis inquiet, depuis qu'on lui décrit la quantité énorme du boulot pour passer TSP en multi-types, il ne réponds plus aux mails. Espérons que ce n'est qu'un surcroît temporaire de boulot .

 

 

-----Original Message-----
From: PAGNOT, Robert
Sent: Monday, January 12, 2004 5:40 PM
To: DUFRENNE, Yves
Cc: 'address@hidden'
Subject: RE: [Tsp-devel] Mon buffer brésilien en string sur Internet

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

important_notice.txt
Description: Text document