Discussion :

[Goduak]

Salut,

Est-il possible de créer 2 input stream sur une socket ainsi que 2 output stream.
J'ai testé et à chaque fois que je créé un 2 eme inputstream ça marche, mais une fois que je le ferme pour utiliser l'autre input stream ça ferme la socket...
du coup je ne peut plus rien recevoir!

Si vous avez une idée, merci

Go

[CyberChouan]

Il ne faut pas créer 2 inputStream ou 2 outputStream, mais un de chaque.

Par contre, ensuite, tu peux récupérer autant de fois que tu le souhaite une référence sur l'instance de chacun de ces flux.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
// Creation des Stream une unique fois (la premiere fois que tu en as besoin)
 
// Dans ta classe 1
InputStream premiereReferenceSurMonInputStream = monSocket.getInputStream();
// tu en fais ce que tu veux...
 
// Dans ta classe 2
InputStream deuxiemeReferenceSurMonInputStream = monSocket.getInputStream();
// tu en fais ce que tu veux (bis)...
 
// Une fois que tu as fini d'utiliser ta socket, tu fermes les flux

[Goduak]

Merci de ta réponse !

Mais en fait, je créé un :
ObjectInputStream ois = new ObjectInputStream(s.getInputStream());
pour mon écoute serveur.

Mais à un moment une fois que ois reçoit un msg de type transfert de fichier, j'active le transfert de fichier avec un :
OutputStream dataOut = clientSocket.getOutputStream();
et la fonction dataOut.write(buffer, 0, i).

Le transfert du client au serveur fonctionne très bien, mais le serveur ne reçoit pas l'instruction qu'il a tout reçu. Instruction qui a lieu si uniquement on fait un dataOut.close().

Mais si je fais ce dataOut.close(), je ferme tous les flux du coup qd mon ois attendra qqch je vais avoir une exception...

Y a-t-il possibilité de contrer ce pb?

[Deadpool]

Tu peux essayer en utilisant la méthode flush de dataOut qui permet de forcer l'écriture des tous les octets restant à écrire mais sans fermer dataOut.

[Goduak]

merci de ta réponse.
Malgré tout ça ne change absolument rien...
c'est horrible ce truc!

[Deadpool]

merci de ta réponse.
Malgré tout ça ne change absolument rien...
c'est horrible ce truc!

Bon pour que l'on puisse t'aider plus efficacement va falloir que tu postes tout le code qui te pose problème...

[Goduak]

Merci de ta proposition, tu fais presque de l'humanitaire...vu le temps que je galère !
Pour plus de lisibilité je te l'envoi en pièce jointe.

J'espère que tu auras une idée...

partie posant pb.zip

[Goduak]

Dans ce que je t'envoie, le client envoie au serveur le fichier qu'il possède avec la méthode sendFile( socket ) et le serveur reçoit ce fichier et le créé sur ce disque dur avec la méthode stock( socket ).

La méthode sendFile se termine en affichant :
DEBUT ENVOI DU FICHIER FTM puis FIN ENVOI DU FICHIER FTM donc ça marche, tandis que lorsque le serveur utilise la méthode stock, le serveur reste coincé ds le while attendant désespérémment une valeur de i égale à -1. ça n'affiche que : DEBUT ECRITURE DU FICHIER FTM.

Si le client utilise la méthode sendFile et que je rajoute un dataOut.close() la méthode stock se terminera bien mais le client aura une exception et coincera sur le readObject contenu dans la méthode de la boucle d'écoute cliente :
myMsgManager.receiveMessage();

Voilà pour mieux comprendre le pb...

[adiGuba]

Salut,

Si tu ne fermes pas les OutputStream/InputStream de tes sockets c'est normal que le read() ne renvoie jamais -1, car c'est la valeur renvoyé lorsque les flux correspondant de la socket sont fermés...

a++

[Goduak]

Salut,

Si tu ne fermes pas les OutputStream/InputStream de tes sockets c'est normal que le read() ne renvoie jamais -1, car c'est la valeur renvoyé lorsque les flux correspondant de la socket sont fermés...

a++

Oui c'est ce que j'ai cru comprendre...Mais donc comment faire pour contourner le pb ?

[adiGuba]

Oui c'est ce que j'ai cru comprendre...Mais donc comment faire pour contourner le pb ?

La question est plutôt : pourquoi cherches-tu a lire dans la socket si le serveur n'envoie plus rien ?

a++

[Goduak]

Je cherche à lire dans la socket pour que la transmission se termine correctement côté serveur et que je puisse toujours côté serveur répondre à une autre requête cliente.

Il y a sans doute une autre méthode de transfert...comment ferais tous les peer to peer et tt sinon...nan?

[adiGuba]

Je cherche à lire dans la socket pour que la transmission se termine correctement côté serveur et que je puisse toujours côté serveur répondre à une autre requête cliente.

Je ne sais pas comment tu gère ton serveur, mais normalement il devrait utiliser une ServerSocket et la méthode accept().

A chaque fois qu'un client se connecte une nouvelle socket est créé, et le traitement s'effectue dans un thread. Pendant ce temps la le thread principal du serveur peut revenir sur la méthode accept() afin d'attendre d'autre client...


Tu peux t'inspirer de ce tutoriel : Développement d'un serveur Java multi-thread simple

a++

[Goduak]

Je ne sais pas comment tu gère ton serveur, mais normalement il devrait utiliser une ServerSocket et la méthode accept().

A chaque fois qu'un client se connecte une nouvelle socket est créé, et le traitement s'effectue dans un thread. Pendant ce temps la le thread principal du serveur peut revenir sur la méthode accept() afin d'attendre d'autre client...


Tu peux t'inspirer de ce tutoriel : Développement d'un serveur Java multi-thread simple

a++

Oui en fait j'ai bien compris le principe c'est ce que je fais d'ailleurs.
Mais quand un client1 veut télécharger un fichier qui se trouve chez un client2, il fait sa demande au serveur et le serveur récuèpre le fichier du client 2 pour le renvoyer au client1. C'est pas comme ça que marche un peer to peer ?
C'est pour ça que le serveur doit pouvoir répondre à chaque nouvelle requête d'un client. ( si demande d'un nouveau fichier par ex, ou de voir qui est connecté au serveur )

[adiGuba]

Mais quand un client1 veut télécharger un fichier qui se trouve chez un client2, il fait sa demande au serveur et le serveur récuèpre le fichier du client 2 pour le renvoyer au client1. C'est pas comme ça que marche un peer to peer ?

Si je ne me trompe pas : le serveur P2P met directement en relation le client1 et le client2. Les fichiers ne transites pas par le serveur.

C'est pour ça que le serveur doit pouvoir répondre à chaque nouvelle requête d'un client. ( si demande d'un nouveau fichier par ex, ou de voir qui est connecté au serveur )

Dans ce cas c'est normal que le read() soit bloquant car le serveur n'envoi rien !

[list][*]Soit tu utilises des requêtes simples en mode "déconnecté" comme HTTP : le client demande quelque chose, et le serveur répond. Toutes les connections sont "coupé" et le client effectue une nouvelle connection en cas de besoin. Chaque opération est indépendante de la précédente.[*]Soit tu utilises un mode "connecté" (comme FTP par exemple), et dans ce cas là tu dois mettre en place un protocole plus complexe, par exemple :

1. Le client effectue une demande.
2. Le serveur donne une réponse qui peut être soit un code d'erreur, soit une réponse positive avec la taille des données qu'il va envoyer.
3. Le client lit alors seulement les données dont il a besoin. Il n'est donc pas bloquer par le read() même si le serveur n'écrit plus rien.
4. Le client peut alors envoyer une nouvelle demande sur la même socket.

Mais dans ce cas là les flux des sockets ne devraient pas être ouvert dans tes méthodes d'envoi/réception sinon tu ne pourra jamais les fermer...

a++

[Deadpool]

J'ajouterais qu'il y a un article sur Developpez ayant pour theme le peer to peer

http://schuler.developpez.com/articles/p2p/