Discussion :

[darkvadr]

J'aimerais savoir s'il est possible de piloter le clavier d'un ordianteur distant, tout en étant sur de ne jamais perdre un click sur une touche.

Pour l'instant j'utilise un IdTCPServer (l'ordianteur à pilotrer) et un idTCPclient (sur l'ordinateur pilote)

Dans une boucle je regarde le caractere appuyé (pour l'instant je ne gere pas les virtuals keys car je communique en ascii (writeln readln)ce qui semble etre un probleme et je dis au client d'envoyer le caractere.

Le serveur recoit bien le caractere...
Mais comme on doit effectuer des traitements entre chaque read on rate des appuis.

Je voudrais etre sur de ne pas rater de key stroke.

La mauvaise "solution" que j'ai trouvé c'est d'envoyer tous les X ms un message au client (en ascii encore)... Message quit dit 'next stroke'

Le client ne peux pas renvoyer de nouvelle touche avant d'avoir recut un 'next stroke'

malheureusement, ca hache trop la communication...

Comme j'envisage d'utiliser cette technique dans des projets aussi variés que le pilotage d'un jeu video, un telecommande pour robot etc... Il me faut quelque chose d'efficace.

Par exemple avec le robot voici les symptomes de ma methodes d'aujourd'hui.


En mode local:

Lorsque j'appuye sur une touche directement, le moteur fait n pas, et ne relis le clavier qu'une fois les n pas executés... Si j'ai toujours le doigts appuyés il refait n pas. Bien qu'il y ait eu une interruption celle ci est si coutre que cela donne l'apparence d'une parfaite fluidité.

En remote avec ma methode:
le moteur fait un arret entre chaque étape (le temps d'envoyer next step etc...)

Bon ben voila... piloter un clavier par internet avec une "sensation" de temps reel et sans perdre de key stroke... C'est possible?

Qu'elle la bonne méthode?

La mienne est très mauvaise.

[Rayek]

Pourqoi ne fait tu pas un thread qui va traiter les éléments (touches ) qui sont dans une liste.

- Le client envoi la touche
- Le serveur recoit la touche et l'ajoute à la liste et on démarre le thread s'il n'est pas en travail
- Le thread scan la liste et voit une entrée et lance son traitement.
- Le thread traite la liste et s'arrete quand elle est vide.

Je pense que tu perdras beaucoup moins de touche avec ce système.

[darkvadr]

Ok, bon je vais essayer de réféléchir et de ne pas me la jouer X.P. sur ce coup. Vu que c'est la première fois que j'essaye de realiser un truc pareil et que vous avez la gentillesse de m'aider.

Donc reprenons le côté serveur:

il me faut 1) un objet Tthread (celui qu'on trouve dans fichier /nouveau/objet thread fera t'il l'affaire?)

1) serveur (donc idTCPserver + son thread manager)

Et quelque chose pour stocker une liste...
Bon la chose qui me vient à l'idée c'est un objet Tlist...
Qu'en pensez vous? C'est bon ou l'objet Tlist est-il inadapté?

Bon le client envoye des touches appuyées...

Côté serveur on passe dans le IdTCPserver1.execute

je fais mon Athread.connection.readln et au lieu de traiter je fais mon Tliste.add.

Jusque là, ai-je compris ou je suis déjà out de tout?

Ensuite je demarre le thread.execute s'il n'est pas déjà en execution

si le TListe.items.count>0 je fais une boucle qui traite la liste (je delete chaque entrée de la liste une fois traitée? ou non?)

quand la liste est vide je passe un flag thread ready (ou quelque chose du genre?).

Mais... Ca veut dire que la liste continue d'être remplie pendant que je la vide...

Je ne pense pas pouvoir arriver à jamais la vider puisque les données vont arriver beaucoup plus vite que je ne pourrais les traiter(je recoit l'appuye sur une touche certes mais dans certains cas l'appuye sur une touche donne lieu a des interpollations de degres 4 (splines)).

Ensuite ne va t'on pas avoir un probleme d'acces à la Tlist si le thread essaye de la lire pendant que le serveur essaye de l'ecrire?

Ou peut etre qu'il faut une sorte de double buffering... (c'est à dire avec deux Tlist, en premier on recopie le Tlist du serveur dans celui du thread et une fois le traitement finit, on vide le Tliste du thread et on swap).

[anapurna]

salut

ce n'est pas une simple liste qu'il te faut mais une Queue
c'est à dire un liste specialise qui fait de firstin-firstout
a la difference d'une pile qui fait du Firstin-Lastout


@+ Phil

[darkvadr]

salut

ce n'est pas une simple liste qu'il te faut mais une Queue
c'est à dire un liste specialise qui fait de firstin-firstout
a la difference d'une pile qui fait du Firstin-Lastout


@+ Phil

Oui bon... je vais googeliser comme une bete cet aprem( gestion de queue etc)...
Si vous avez des exemples d'utilisation de ce genre de système, je suis très très preneur bien sur.

EDIT: humm j'espere ne pas avoir a passer a l'assembleur pour faire un fifo parceque là je suis mal barré...

REEDIT (parce que des questions me viennent)... Si je recoit des données plus vite que je peux les traiter et que je ne veux pas en perdre, meme si j'arrive (et c'est pas gagné) à implementer un FIFO. Je vais me retrouver en buffer overflow non?

Un buffer overflow sur une application réseau, c'est mal... très très mal...

[Rayek]

Avec une bete TStringList tu peux faire du Fifo (First In - First Out)

Avec le Thread, tu ne lis que le Premier élément de la TStringList (le 0), dès que tu l'as traité, tu le supprime puis tu refait pareil jusqu'a ce que ca soit vide.
Pendant ce temps,le serveur avec son execute, ajoute à la TStringlist les touches à faire après.

Les deux se font en //

il me faut 1) un objet Tthread (celui qu'on trouve dans fichier /nouveau/objet thread fera t'il l'affaire?)

1) serveur (donc idTCPserver + son thread manager)

Oui, mais tu as des tutos sur les thread sur developpez qui te seront très pratique (c'est ce que j'ai utilisé pour apprendre à utliser les thread).

Et quelque chose pour stocker une liste...
Bon la chose qui me vient à l'idée c'est un objet Tlist...
Qu'en pensez vous? C'est bon ou l'objet Tlist est-il inadapté?

J'ai répondu plus haut

Mais... Ca veut dire que la liste continue d'être remplie pendant que je la vide...

Oui, tout à fait

Je ne pense pas pouvoir arriver à jamais la vider puisque les données vont arriver beaucoup plus vite que je ne pourrais les traiter(je recoit l'appuye sur une touche certes mais dans certains cas l'appuye sur une touche donne lieu a des interpollations de degres 4 (splines)).

En francais ca donne quoi (je vois pas de quoi tu parles :p)

Ensuite ne va t'on pas avoir un probleme d'acces à la Tlist si le thread essaye de la lire pendant que le serveur essaye de l'ecrire?

Non ca gène pas, d'un coté tu vas faire du Add (donc tu empiles à la dernière position) et de l'autre tu vas delete (donc tu dépiles depuis la 1er position)

Ou peut etre qu'il faut une sorte de double buffering... (c'est à dire avec deux Tlist, en premier on recopie le Tlist du serveur dans celui du thread et une fois le traitement finit, on vide le Tliste du thread et on swap)

Pas utile, si tu comprends corretement comment foncitonne le Fifo.

Pour te faire une image facile du fifo, considère un jeu de carte sur une table. Le Add c'est quand tu poses une carte sur le dessus de la pile, le delete c'est quand tu retires une carte par le dessous de la pile ^^ (oui l'exemple est simpliste ^^)

[darkvadr]

En francais ca donne quoi (je vois pas de quoi tu parles :p)

he ben... ca donne un certain temps de traitement avant de pouvoir passer à la commande suivante. Bon ben je m'y mets.
Et merci... Je viendrais certainement vous redéranger avec quelques question pas piquées des vers (ou des hannetons c'est selon).

[darkvadr]

merci les mecs, ca marche impec!

Z'êtes mes heros...