Discussion :

[ratakses]

Salut à tous,

Je voulais faire un petit serveur qui maintient une liste de Sockets, et qui utilise un thread pour lire sur chacun en utilisant nio. Mais voilà, pour utiliser nio, il faut que j'utilise des SocketChannel, et je n'ai pas trouvé de moyen d'obtenir un SocketChannel à partir d'un Socket, est-ce que qqn sait si c'est possible ?

Merci bien!

[adiGuba]

Salut,

Mais voilà, pour utiliser nio, il faut que j'utilise des SocketChannel, et je n'ai pas trouvé de moyen d'obtenir un SocketChannel à partir d'un Socket, est-ce que qqn sait si c'est possible ?

Il suffit d'utiliser la méthode getChannel() de ta socket

a++

[ratakses]

Merci pour ta réponse, mais en fait getChannel() me retourne null, parce qu'il est spécifié dans l'api :

A socket will have a channel if, and only if, the channel itself was created via the SocketChannel.open or ServerSocketChannel.accept methods.

Et mon problème est que je dispose uniquement de simples Sockets.
Il faut que je crée des Channel séparement ? Je vois pas très bien comment faire en fait

[ratakses]

Je commence à me demander si je ferais pas mieux de manager un stock de SocketChannels à la place d'un stock de Sockets, mais ça m'embête un peu

[Sanguko]

Pourquoi ?

[ratakses]

Parce que ça implique de changer pas mal de choses dans mon code, j'ai déjà commencé à le faire.

D'ailleurs je me demandais quelque chose :
en admettant que je crée un SocketChannel sous forme de variable locale n'existant qu'au sein d'une méthode, que je lui fait un register avec OP_READ et qu'ensuite je stocke ce SocketChannel dans une collection quelconque.
Est-ce que, lorsque la méthode est terminée (et donc que la variable locale n'existe plus) et que je supprime le SocketChannel de ma collection, l'opération select va continuer à utiliser cet objet ? Oubien est-ce qu'il aura disparu ?

En d'autres mots,
Est-ce que l'instance de l'objet elle-même est supprimée (du moins aux yeux du selector) lorsque j'efface l'objet de la collection ?

(Je précise que mon but est de maintenir un stock de SocketChannel liés à des timers afin de ne pas chaque fois devoir en recréer)

Merci pour votre aide...

[Sanguko]

L'instance ne sera pas supprimée tant qu'il restera une reference. Ce qui est a priori le cas, via le Selector, qui contient un ensemble de SelectorKey, qui reference ton objet SocketChannel.

[ratakses]

Ok, merci pour ton aide.

Je crois que j'ai trouvé une solution en faisant le register() dans la classe qui me sert à stocker mes channels, et en faisant un close() au moment ou le timer expire.

[ratakses]

En fait, j'ai encore un problème sur lequel je coince,

voici le morceau de code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
try{
        socketChannel = SocketChannel.open(new InetSocketAddress(destInet, 2000));
}
catch(IOException ioe){
	...
}
stockSockets.put(socketChannel);
 
try{
	Socket socket = socketChannel.socket();
	ObjectOutputStream dos = new ObjectOutputStream(socket.getOutputStream());
	dos.writeObject(message);
	dos.close();
}
catch(IOException ioe){
	...
}

et voici le code de stockSocket.put() :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
synchronized public void put(SocketChannel socketChannel){
		try{
			socketChannel.configureBlocking(false);
			socketChannel.register(selector, SelectionKey.OP_READ);
 
		}
		catch(){
			...
		}
		...
}

Mon problème est que mon programme bloque environ une minute entre le configureBlocking() et le register(), avant de finalement continuer et de me faire une IllegalBlockingModeException au moment où il arrive à la ligne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ObjectOutputStream dos = new ObjectOutputStream(socket.getOutputStream());

Si je retire le configureBlocking(false), le programme lève une IllegalBlockingModeException au moment de faire le register()...

J'ai pas mal cherché, mais je ne comprend pas vraiment la nature de cette exception, est-ce que qqn aurait une idée ?

[ratakses]

Je crois que j'ai trouvé : je pense que cette erreur vient du fait qu'on ne peut pas écrire sur le socket associé à un socketChannel non bloquant