[Debutant] Sockets: le schéma est-il vrai ou faux?

Bonjour,

Voici le schéma que j'ai trouvé sur le net, et je pense qu'il est faux.

http://www-igm.univ-mlv.fr/~roussel/...AVA/Socket.gif

Pourquoi?

Si j'ai bien compris, sur le dessin, le client envoie (write) ses données sur l'input stream et reçoit (read) sur l'outputsteam !! C'est pas le contraire?

Une question bonus :yaisse2: qui me turlipine depuis ce matin :bug:
reprenons ce même schéma (en faisant comme s'il était juste), maintenant imaginons que le serveur puisse gérer plusieurs connections clientes, c'est à dire qu'il accepte les sockets qui se connectent à lui.

Quand un socket client se connecte sur un serverSocket.
en faisant "socketClient.getOutputStream()" , on peut envoyer des données vers le serveur.

Maintenant, est-ce que pour tous les clients, qui se connectent sur le serveur avec un socket client, la valeur de socketClient.getOutputStream() sera le même pour tous les clients?

Est-ce que pour deux sockets clients qui se connectent au meme serveurSocket, le flux d'écriture pour écrire au serveur est le meme, c'est à dire socketClient1.getOutputStream() équivaut à socketClient2.getOutptSteam() ?

ca revient au meme de dire, que le flux inputStream sur le serverSocket.accept() du Serveur est le même pour tous les clients s'y connectant?


Merci :D
Cécilia

C'est vrai qu'il est faux. Un OutputStream ne possède pas de méthode read. Le type s'est mélangé les pinceaux.

En revanche, le flux InputStream du socket serveur est le même pour tous les clients, mais chaque client possède son propre OutputStream.

Citation:

---

chaque client possède son propre OutputStream

---

D'accord, mais étant donné que TOUS les cliens communiquent avec le même serveur, alors le outputStream mène dans tous les cas vers le InputStream du serveur? (même si le outputStream n'est pas le même)

J'attends ta réponse pour confirmer ça :resolu:

Merci Rayndell

Cécilia

Oui, bien sûr, le processus serveur ne possède qu'un seul flux d'entrée.

Ce fut un plaisir.

Merci !!!

Je vais pouvoir avancer un peu plus...mais j'ai enfin piger le concept de socket.

Merci Rayndell :love2::oops:
Bonne journée

Cécilia

Plus précisément, les OutputStream de chaque client sont effectivement dirigés vers le même Stream, c'est-à-dire l'InputStream du serveur. Mais il ne faut pas dire que ce sont les même OutputStream. (J'insiste)

Ceci dit, ravi d'avoir pu t'aider.

(Tant de reconnaissance... C'est trop ! Y'a même des petits coeurs,wouahou !)

Salut :oops:

Petite rectification, je ne sais pas si je me suis mal exprimée, mais je viens de comprendre une chose que je n'avais pas saisi...concernant les "inputstream".

L'InputStream coté serveur est associé à un SEUL socket client, donc le serveur a autant d'InputStream que de client.

Je voulais en faite créer un seul InputStream (coté serveur) commun à tous les clients afin de ne pas lancer un thread pour chaque client.

Mais, je viens de voir que celà n'est pas possible.

Est-ce normal?

Je pense que oui, je vais m'orienter vers la nouveau API NIO (depuis la 1.4).

Cécilia.

Je ne saisis pas bien ton problème, tu voudrais que tous les clients écrivent sur la même InputStream ? Je n'en vois pas l'intérêt, si c'était le cas cela voudrait dire qu'il y aurait des écritures concurrentes en cas de clients simultanés. De toutes façons, un serveur est obligé de lancer un Thread à la réception d'un client pour ne pas se bloquer et accueillir de nouveaux clients.

Citation:

---

tu voudrais que tous les clients écrivent sur la même InputStream ?

---

Coté serveur oui...:oops: c'était mon idée. Je m'explique..j'imaginais créer un protocole.

Par exemple, les clients communiquent avec le serveur via une string.
Le premier "token" serait l'eméteur, et le second le message

Exemple: "client12 | salut à vous"

Le serveur lui régarde les messages arrivant sur son InputStream, il le lit, et l'analyse (ah tiens ! c'est client12 qui me l'a envoyé et il dit "salut à vous").

Le serveur a 2 thread
- le 1er qui accepte les connections
- le 2eme qui écoute sur son inputStream (et donc lit les messages)

Dans ce cas, le serveur ne se bloque pas.
Mais de tte façon, le serveur ne pas peut lire les messages de tous les clients sur un SEUL inputstream...j'ai essayé, quand je me connecte, le premier client communique bien avec lui, quand je lance un deuxieme client, le serveur l'accept bien, mais quand j'essaye d'envoyer des messages avec le client2, le server lui ne les récéptionne pas. Alors que le client1 oui.
D'ou ma conclusion, un socket est une sorte de tunnel entre 2 machines. On peut pas atteindre la sortie d'un autre tunnel à partir d'un autre tunnel (même si la destination est la même).

Voilà j'espère que tu saisies ma logique...:oops:

Cela dit, je sais désormais que ce que j'avais entrepris de faire n'est pas possible...
je voulais également te remercier, en tout honneté pour le dialogue que tu me fais.
Et pour en revenir à nos montons, je voulais absolument éviter de passer par des threads...car si j'ai 500 connections, cela me fera 500 threads..ce qui d'après certaines personnes ralenti la machine (et surtout que si c'est juste pour envoyer des messages de temps en temps..c'est pas forcement un bon choix)

Encore merci Rayndell

Voilà une solution que je te propose :

Met en place une ressource commune qui symbolisera les messages en attente d'être traités. Tu as un thread qui attend les connections (socket.accept()). Lors de la réception d'un message, celui-ci est inséré dans la ressource commune (qui peut être une simple ArrayList). Le serveur retourne ensuite au travail et attends les messages.

Tu as ensuite un autre thread qui lit en permanence la ressource commune, et qui teste qi elle est vide. Si elle ne l'est pas, c'est qu'il y a un message à traiter. On enlève donc ce message de la ressource commune et on le traite.

Il y a deux Threads en tout, je pense que ma solution se rapproche beaucoup de ce que tu voulais. N'oublie pas de synchroniser les accès à ta ressource commune en créant une ArrayList synchronisée (Collections.synchronizedList(...)) pour éviter les problèmes d'accès concurrents.

Merci je vais voir avec ça :love:

Merci encore

En fait j'ai vu récemment que ma solution dépend de tes besoins. Dans mon cas, il y avait des messages reçus en permanence, ce qui impliquait que le thread de traitement était en permanence en train de bosser. Cela dépend donc de la fréquence de l'arrivée des messages. Si un message arrive toutes les secondes (par exemple), il vaudrait mieux alors mettre le thread en attente (Thread.wait()) et le réveiller chaque fois qu'un message arrive (notify()). En effet, ma solution a malheureusement tendance à occuper les deux tiers du processeur...