Version imprimable
bonjour, a tous voila je suis étudiant en informatique et je rencontre quelque difficulté a trouver un équivalent de la fonction select du langage c ou c++, globalement je doit réaliser un client qui contient une IA et je ne peux faire qu'un seul thread du coup je me retrouve bloquer a cause du read de la socket
si quelqu'un avais l'amabilité de m'aider a corriger se problement
cordialement
globalement je fait un readline qui bloque et j'aimerais qu'il read seulement quand in y a des info a lire pour pas qu'il ne bloque le rest de l'appli
Hello,
tu as une méthode available() qui te renvoie combien d'octets tu peux lire sans bloquer :
socket.getInputStream().available()
Simple curiosité, pourquoi tu te limites à 1 seul thread ?
tu ne pourra pas utilise readline en non bloquant, par définition cette méthode attends une retour à la ligne.
Pour lire la socket en non bloquant, il y a les méthodes available de inputstream.
pour les thread j'ai malheureusement des condition a respecter dans le sujet et je n'est droit qu'a un seul thread par programme sinon sa aurait été vite fait bien fait, je vais tester vos méthode et je vous tien au courant en tous ca merci de répondre un dimanche
y aurait 'il une autre methode du style readline pour read une socket sans la bloquer ?
getInputStream().read(buffer,offset,taille) en s'assurant que taille <= getInputStream().available().
Pour info, c'est impossible à faire, java lance d'office plusieurs thread dès le démarragedu programme ;) (Garbage collector et Event dispatch thread, entre autres)Citation:
Envoyé par philip_b
sa je le conçoit bien mais nous il nous autorise seulement un seul thread dans notre appli apres celle qui son faite de façon normal sans l'intervention du programmeur son autoriséCitation:
Envoyé par tchize_
oui mais si tu travaille en application graphique, des threads tu en mangera, et tu sera vraisemblablement obligé d'en créer ;)
j'ai un petit souci avec le buffer du read je ne peux pas lui passer de type String il ne prend ke des bite[] et cela m'embête car j'ai besoin de String
j'ai encore du mal avec le java
j'ai trouvé quelque chose qui a l'aire de marcher
if (buff.ready() == true)
lCmd = buff.readline();
qu'en pensé vous?
ready() te garantis que le prochain appel à read() sur le reader ne bloquera pas, pas que le prochain readLine ne bloquera pas. Ainsi, si t'a reçu une demi ligne, ready() te renverra true, mais readLine attendra la fin de la ligne sur le réseau.
ok merci de vos réponse, après une relecture du sujet normalement toutes les commande envoyer depuis le serveur on un retour a la ligne donc tous devrais être nickel. en tous cas merci de vos réponse bonne journée a tous
Il y a une correspondance avec la fonction select() en java nommé le Selector (java.nio.channels).
Le principe est simple, tu enregistre tes channels (SocketChannel pour les Sockets) dans le selector via la méthode SelectableChannel#register(Selector, int).
Il te donne une clé auquel tu peux lier un objet, ce qui est pratique pour y mettre une représentation de ton client par exemple et ne plus faire le mapping socket/client toi même.
Tu fait ensuite un switch/case sur les constantes statiques de SelectionKey.
Accept = serversocket pret à faire la méthode accept() (comme un read en C mais il n'y a plus les tests à faire pour savoir si c'est le serveur qui est prêt)
Connect = socket client connecté. (C'est utile uniquement pour les histoires de sessions)
Read = socket client avec des données en attente. (comme en C mais cela ne concerne plus les serversocket !)
Write = socket client prêt à envoyer des données. (comme en C)
Le code à écrire est très souvent le même quelque soit l'application. Trouver des exemples ne sera pas si difficile à mon avis. Pour ma part, j'ai vu comment ça fonctionne par le jeu, en décortiquant les serveurs : http://l2jserver.com/svn/trunk/MMOCore/ (attention, code bourrin et sans commentaires :p)
Bonjour philip_b,
La solution de Grimly est ce qui s'approche le plus de ce que tu voulais faire.
Par contre, je rebondis sur une de tes remarques:
Même si ce n'est qu'un exercice, ça n'est pas forcément une bonne habitude que se cantonner à ce qui peut se passer normalement. Ainsi, comment réagirait l'application cliente si, pour une raison ou une autre, ce fameux "retour à la ligne" n'arrivait jamais?Citation:
après une relecture du sujet normalement toutes les commandes envoyées depuis le serveur ont un retour à la ligne
Pour prendre une analogie, normalement une page web se termine par </html>. Maintenant, tu ne serais sans doute pas satisfait d'un navigateur qui attendrait indéfiniment l'arrivée de cette balise si le serveur web (ou le réseau, ou le proxy, ou...) avait la mauvaise idée de "planter" avant de la transmettre...
A+
- Sylvain