IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Java Discussion :

dupliquer socket.getInputStream() ?


Sujet :

Java

  1. #1
    Membre à l'essai
    Profil pro
    Inscrit en
    mars 2006
    Messages
    30
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2006
    Messages : 30
    Points : 19
    Points
    19
    Par défaut dupliquer socket.getInputStream() ?
    Bonsoir à tous,

    prenons cet extrait de début de code :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
     
    final Socket socket = new Socket (hostName, port);
    is = socket.getInputStream ();
    j'ai besoin qu'au moins deux threads traitent les infos du flux "is" genre :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    final Scanner scan = new Scanner(is, "UTF-8");
     
    				while (scan.hasNextLine()) {
    ...
     
    }
    chaque thread prend ce qu'il a besoin comme infos et effectue des actions en conséquence.

    Problème ; lorsque l'un thread lit une ligne d'is en quelque sortes il l'enlève à l'autre thread qui lit la suivante et qui a à son tour l'enlève à l'autre.

    Or j'aimerai que tous les threads aient à disposition toutes les infos d ' "is".

    Donc est-il possible de dupliquer le flux "is" afin que chaque thread possède le même flux ...

    Pour le moment j'ai du me faire un distributeur du flux avec des pools :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
     
    while (scan.hasNextLine()) {
    					final String line = scan.nextLine();
    					for (int i = 0; i < listeners.size(); i++) {
    						listeners.get(i).queue.add(line);
    					}
    }
    Dans ce code, il y a autant de listeners que de thread ce qui me permet d'imiter une duplication des flux.


    Mais est-ce une méthode normale je vois que Java ne propose rien quand à une duplication du flux d'entrée ou j'ai mal regardé ?

    Merci.

  2. #2
    Modérateur

    Profil pro
    Inscrit en
    septembre 2004
    Messages
    12 218
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2004
    Messages : 12 218
    Points : 20 686
    Points
    20 686
    Par défaut
    Hello,

    Disons qu'il est surtout extrêmement bizarre d'avoir ce besoin-là.

    Si l'un de tes threads s'occupe de consommer les données, pourquoi diable d'autres threads devraient-ils s'en occuper ? Un prédécoupage en messages individuels, qui peuvent être ensuite envoyés à tous les observateurs, ça peut encore se comprendre. Mais l'InputStream directement.... Pourquoi ?

    A ma connaissance Java ne propose pas de duplication de flux, mais il existe des bibliothèques tierces qui le font. Probablement pas pour les gens qui penseraient à une chose pareille, toutefois.
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  3. #3
    Membre à l'essai
    Profil pro
    Inscrit en
    mars 2006
    Messages
    30
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2006
    Messages : 30
    Points : 19
    Points
    19
    Par défaut
    Bon voilà qui répond à ma question, ma solution surprend donc.

    L'idée est qu'une fois connecté à un hôte, je puisse lancer toutes sortes de listener de courtes ou longues durées, par exemple pour récupérer ponctuellement des infos après une demande, ou un listener permanent qui sert à répondre présent à l'hôte.

    Chaque listener ne prend dont ce qu'il a besoin et sans enlever à son voisin ce que lui a besoin.

    Sachant que l'hôte n'a pas d'ordre de règles quand à l'envoie des messages ;
    - il peut très bien envoyer une longue liste durant jusqu'à 1 minute
    - pendant ce temps il demande si le client est toujours présent (réponse à un ping, il entre coupe donc sa liste)
    - et dans le même temps m'avertir par petites touches d'événements ponctuels

    Imaginons donc trois listener, chaqu'un traite son taf, s'éteind lorsqu'il a finit. etc ...

    ---

    ma soluce marche mais c'est vrai que ça fait un moment que je trouve bizarre de l'avoir fait artisanalement.

  4. #4
    Modérateur

    Profil pro
    Inscrit en
    septembre 2004
    Messages
    12 218
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2004
    Messages : 12 218
    Points : 20 686
    Points
    20 686
    Par défaut
    Disons que ça paraît plus logique de s'abstraire des InputStreams et de raisonner par messages, avec les listeners, comme tu as déjà.
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  5. #5
    Membre à l'essai
    Profil pro
    Inscrit en
    mars 2006
    Messages
    30
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2006
    Messages : 30
    Points : 19
    Points
    19
    Par défaut
    OK

    Entre-temps j'ai fait un truc rapide.

    Donc à quoi peut me servir de dupliquer un flux d'entrée ? pour éviter ça ...

    Nom : threads.JPG
Affichages : 25
Taille : 44,6 Ko

  6. #6
    Modérateur

    Profil pro
    Inscrit en
    septembre 2004
    Messages
    12 218
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2004
    Messages : 12 218
    Points : 20 686
    Points
    20 686
    Par défaut
    Oui mais c'est ce que je viens de dire en fait. Ne duplique pas le flux d'entrée.
    Lis les lignes du flux d'entrée, et envoie-les toutes aux concernés.
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  7. #7
    Membre à l'essai
    Profil pro
    Inscrit en
    mars 2006
    Messages
    30
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2006
    Messages : 30
    Points : 19
    Points
    19
    Par défaut
    Donc ma soluce n'est pas bizarre au final ... courante même dans d'autres contextes ?

  8. #8
    Modérateur

    Profil pro
    Inscrit en
    septembre 2004
    Messages
    12 218
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2004
    Messages : 12 218
    Points : 20 686
    Points
    20 686
    Par défaut
    Je t'avoue que je connais pas d'exemple, mais a priori ça peut s'imaginer.
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  9. #9
    Membre à l'essai
    Profil pro
    Inscrit en
    mars 2006
    Messages
    30
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2006
    Messages : 30
    Points : 19
    Points
    19
    Par défaut
    Il n'empêche que même en remaniant mon client pour le rendre plus simple et tant pis si moins efficace, je tombe toujours sur la même conclusion que dupliquer mon InputStream me simplifierai bien des problèmes.

    Pour ceux que ça intéresse :
    https://stackoverflow.com/questions/...an-inputstream

    Lui se prend pas la tête et copie carrément des blocs d'octets.
    Comme moi j'ai des lignes ASCII à traiter, je me suis fait des threads de pools de lignes dupliquables à volonté.

    Lui a un autre besoin, mais en tous cas être confronté au besoin ne semble pas être mon cas unique et pas non plus une bizarrerie.

  10. #10
    Modérateur

    Profil pro
    Inscrit en
    septembre 2004
    Messages
    12 218
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2004
    Messages : 12 218
    Points : 20 686
    Points
    20 686
    Par défaut
    Faudrait savoir, c'est la même chose ou pas la même chose ?

    En l'occurrence, ça l'est pas. Lui il a pas de thread. Il a besoin de faire une première chose avec son InputStream, et après que cette première chose soit terminée, d'en faire une deuxième.

    - besoin du truc deux fois, pas trois, pas quatre, pas autre chose que deux.
    - pas de thread. Une première étape, suivie d'une deuxième quand la première est terminée.

    Absolument rien à voir donc.

    En plus son raisonnement est ridicule, clairement il fait comme si l'informatique c'était magique.

    Dans ton cas on peut pas trop savoir, tu nous as juste parlé de threads et de listeners. On peut envisager des raisons logiques.
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  11. #11
    Membre à l'essai
    Profil pro
    Inscrit en
    mars 2006
    Messages
    30
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2006
    Messages : 30
    Points : 19
    Points
    19
    Par défaut
    En tous cas je suis content ; en affinant mon analyse je n'ai finalement plus besoin que d'UN seul thread qui attend en permanence l'InputStream, se charge de décoder les lignes selon le protocole et les distribue dans une liste de 1 à n objets de type "Events" dont l'appelant à tout le loisir de charger pour donner un comportement au client.

    Je m'aperçois donc que je n'ai pas besoin de plusieurs listeners qui faisaient donc un travail partiellement redondant puisqu'ils se chargeaient de décoder le protocole et d'enclencher les événements. Alors qu'en fait c'est juste le nombre et la nature d'événements qui est variable, le protocole peut être décodé une seule fois.

    ça parait tout con à dire, mais quand on a la tête dans le guidon, on le voit pas de suite ; on fonce à coder des listeners Thread pour être tranquille.

    Mon code est carrément simplifié et les choses se structurent d'elles-même.

    Et surtout je m'éloigne de ma problématique de vouloir dupliquer l'InputStream que Java ne propose pas de base et ça a un côté rassurant

    -----

    Cela dit, même après une 3éme 4éme version de mon client, remaniements et autres, j'en arrive à douter de mes certitudes et mes solutions. Je fais même volontairement le contraire pour confirmer ma solution de départ.

    Et il faut aller loin jusqu'à s'interroger pourquoi il n'était pas naturel à Java de proposer une duplication du flux d'entrée.

    -----

    Donc si je me mets volontairement moi-même en doute, tu comprendras qu'il n'est pas anormal que j'émette un doute des propos d'un autre même si celui-ci m'a pourtant très pédagogiquement mit sur la voie à propos des classes anonymes.

    -----

    Quand à StackOverflow, je maintiens qu'il n'est pas le seul à s'être interrogé sur la question et il y a d'autres forums de progs où d'autres se sont interrogés.

    Ce n'est pas parce qu'une solution est ignorée 9 / 10 par la masse, qu'il n'y a pas une fois où l'on aura pas d'autres choix que de s'y intéresser.

Discussions similaires

  1. getInputstream sur un socket en permanence
    Par maxigolo dans le forum API standards et tierces
    Réponses: 0
    Dernier message: 08/02/2015, 19h05
  2. [Socket] Récupérer chaine reçue (getInputStream)
    Par Nicolas74 dans le forum Entrée/Sortie
    Réponses: 5
    Dernier message: 02/12/2009, 14h22
  3. socket et in = service.getInputStream();
    Par andromeda dans le forum Entrée/Sortie
    Réponses: 2
    Dernier message: 24/07/2007, 03h15
  4. executer une application a distance : Sockets ? RPC ? CORBA?
    Par a_hic dans le forum Développement
    Réponses: 5
    Dernier message: 30/05/2006, 13h02
  5. transfert d'un fichier bitmap en socket tcp
    Par localhost dans le forum C++Builder
    Réponses: 5
    Dernier message: 29/07/2002, 00h40

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo