Débutant Java, Sockets et observers

Version imprimable

17/12/2006, 11h26
nouknouk

Débutant Java, Sockets et observers

Bonjour à tous.

Pour planter le décor, je viens tout juste de me mettre au développement JAVA. J'ai néanmoins une excellente connaissance du C++ en général et du framework Qt en particulier.

J'aurais justement une question de débutant en JAVA: voilà, je voudrais implémenter une appli client/serveur en Java et j'ai commencé à regarder du côté de la classe Socket.

Celle-ci m'interpelle un poil, car j'y ai bien retrouvé les méthodes (bloquantes et non bloquantes) pour lire et écrire sur une socket TCP mais je ne vois pas comment implémenter simplement un mécanisme de callback pour être prévenu lorsque de nouvelles données sont accessibles en lecture (ie. en tant que client, être prévenu lorsque le serveur m'a envoyé quelque chose).

J'ai bien l'idée d'implémenter, à la mano, un thread séparé qui irait régulièrement voir si de nouvelles données sont accessibles et utiliser en parallèle un mécanisme d'observable/observer pour mon 'callback'.
Mais je me demandais s'il n'y avait pas une façon plus simple (et déjà toute faite) pour exécuter une de mes fonctions quand de nouvelles données sont disponibles.

Merci d'avance pour vos réponses à ma question que j'imagine bien bête et innocente :oops:

EDIT: je viens de me rendre compte que j'aurais peut-être mieux fait de poster ma question dans le forum API / IO :roll: ... je n'ai pas l'impression de pouvoir déplacer mon post ... un modo pourra peut être le faire pour moi ?
17/12/2006, 12h40
®om

Tu fais un read (bloquant) sur l'entrée de ta socket client dans un thread séparé...
17/12/2006, 13h34
nouknouk

Salut, et tout d'abord merci pour ta réponse.

Le thread supplémentaire avec le read bloquant me paraîssait justement un peu 'lourd' à mettre en oeuvre. C'est ce que j'ai tenté d'expliquer dans mon paragraphe commençant par "J'ai bien l'idée d'implémenter, à la mano, un thread séparé..."

N'y aurait-t-il pas d'autre moyen plus léger ?
17/12/2006, 13h41
®om

Citation:

Envoyé par nouknouk

Le thread supplémentaire avec le read bloquant me paraîssait justement un peu 'lourd' à mettre en oeuvre. C'est ce que j'ai tenté d'expliquer dans mon paragraphe commençant par "J'ai bien l'idée d'implémenter, à la mano, un thread séparé..."

et cette phrase finissait par qui irait régulièrement voir si de nouvelles données sont accessibles et utiliser en parallèle un mécanisme d'observable/observer pour mon 'callback'.
La méthode que je te propose ne va pas "régulièrement voir"... le read() est prévenu dès que quelque chose arrive...
17/12/2006, 13h41
nicØB

Oui ça sera lourd, car un thread par client ...

Utilise plutôt nio où tu n'auras besoin que d'un seul thread.
Fais une recherche sur le forum, d'autres personnes on déjà poser des questions sur l'utilisation de cette api.
18/12/2006, 13h28
professeur shadoko

pour implanter un "callback" sur réseau ... essaye R.M.I ... c'est chic et élégant.
19/12/2006, 10h21
dingoth

Euh ... Je ne vois pas le rapport avec RMI, là o_Ô Dans le style solution encore plus lourde, c'est fort, ça :)
19/12/2006, 13h28
professeur shadoko

Citation:

Envoyé par dingoth

Euh ... Je ne vois pas le rapport avec RMI, là o_Ô Dans le style solution encore plus lourde, c'est fort, ça :)

ben non justement ! c'est très facile d'organiser un call-back sur une référence distante de plus l'objet "serveur" fait l'attente que tu cherche à programmer.
alors pourquoi reécrire quelque chose qui marche bien?
(R.M.I n'est pas "lourd" du tout, le confit de canard je dis pas mais RMI non ...)
19/12/2006, 14h01
dingoth

Au temps pour moi. Je n'avais pas bien compris la requête de nouknouk.

Effectivement, le RMI est adapté aux callbacks en ce sens, puisque les appels se font directement sur Objet.méthode(...) qui d'un côté du réseau enverra un ordre à l'autre, et cet autre bout du réseau exécutera le code souhaité.