protocole de comunication reseau

Le
Bruno Nogent
Bonjour,
Je dois realiser un protocole entre deux programme ( un client et un
serveur)
en utilisant des sockets.

Connaitriez-vous des exemples de protocole de communication qui prennent en
charge des messages d'une taille superieure au buffers de reception et
pouvant traiter un echange de donnees oriente service ?
ex :
le client se connecte au serveur
le client discute avec un service serveur A via cette connection
le client discute avec un service serveur B via cette meme connection
Comment fragmenter les grands messages et traiter les messages destines aux
services differents

Sinon comment cela est-il generalement implemente ?

Merci
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Jacques Caron
Le #521518
Salut,

On Thu, 8 Apr 2004 15:04:58 +0200, Bruno Nogent wrote:

Je dois realiser un protocole entre deux programme ( un client et un
serveur) en utilisant des sockets.


Plutôt classique.

Connaitriez-vous des exemples de protocole de communication qui prennent
en charge des messages d'une taille superieure au buffers de reception


Euh... SMTP, HTTP, FTP, NNTP, POP3, IMAP... et plus généralement tous les
protocoles basés sur TCP.

et pouvant traiter un echange de donnees oriente service ?


Mmmm?

ex :
le client se connecte au serveur
le client discute avec un service serveur A via cette connection
le client discute avec un service serveur B via cette meme connection


Pourquoi ne pas faire deux connexions? TCP (comme UDP d'ailleurs)
fournissent déjà le nécéssaire pour faire le multiplexage (les ports),
pourquoi ré-inventer la roue?

Comment fragmenter les grands messages


Avec TCP pas besoin de les fragmenter, il s'en occupera tout seul.

et traiter les messages destines aux
services differents


Utiliser des connexions sur des ports différents.

Sinon comment cela est-il generalement implemente ?


Des connexion TCP, une par service. Reste ensuite à définir la tête du
protocole utilisé par dessus TCP, qu'il soit de type texte (comme SMTP,
HTTP, FTP, NTTP, POP3, IMAP) ou binaire (comme les protocoles d'accès aux
bases SQL, en général, ou comme SSL/TLS...).

Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/

Bruno Nogent
Le #521516
Oui mais par exemple :
Une application cliente qui souhaiterais telecherger 100 fichiers en
parallele (threads)
Je ne vais pas ouvrir 100 connections distinctes au serveur ?

Merci

"Jacques Caron" news:
Salut,

On Thu, 8 Apr 2004 15:04:58 +0200, Bruno Nogent wrote:

Je dois realiser un protocole entre deux programme ( un client et un
serveur) en utilisant des sockets.


Plutôt classique.

Connaitriez-vous des exemples de protocole de communication qui prennent
en charge des messages d'une taille superieure au buffers de reception


Euh... SMTP, HTTP, FTP, NNTP, POP3, IMAP... et plus généralement tous les
protocoles basés sur TCP.

et pouvant traiter un echange de donnees oriente service ?


Mmmm?

ex :
le client se connecte au serveur
le client discute avec un service serveur A via cette connection
le client discute avec un service serveur B via cette meme connection


Pourquoi ne pas faire deux connexions? TCP (comme UDP d'ailleurs)
fournissent déjà le nécéssaire pour faire le multiplexage (les ports),
pourquoi ré-inventer la roue?

Comment fragmenter les grands messages


Avec TCP pas besoin de les fragmenter, il s'en occupera tout seul.

et traiter les messages destines aux
services differents


Utiliser des connexions sur des ports différents.

Sinon comment cela est-il generalement implemente ?


Des connexion TCP, une par service. Reste ensuite à définir la tête du
protocole utilisé par dessus TCP, qu'il soit de type texte (comme SMTP,
HTTP, FTP, NTTP, POP3, IMAP) ou binaire (comme les protocoles d'accès aux
bases SQL, en général, ou comme SSL/TLS...).

Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/



www.frameip.com
Le #519902
"Bruno Nogent" c53p7m$e36$

Oui mais par exemple :
Une application cliente qui souhaiterais telecherger 100 fichiers en
parallele (threads)
Je ne vais pas ouvrir 100 connections distinctes au serveur ?


Pas de soucis, si ton application ouvre une socket tcp et que chaque threads
s'appuis sur cette socket. Tu auras alors une seule connexion via le
serveur.

Cependant, il faut que l'application serveur le supporte et que ton
utilisation de la socket soit en mode non bloquant.

--
SebF

http://www.frameip.com
Pour ceux qui aiment TCPIP

Email :
H323 : h323.frameip.com

Bruno Nogent
Le #519900
Comment savoir a quel fichier appartiennent les donnees recues ?
Comment traiter les fichiers de grande taille (plus grand que le buffer de
reception du client ) ?


"www.frameip.com" news:c53pkj$41c$
"Bruno Nogent" c53p7m$e36$

Oui mais par exemple :
Une application cliente qui souhaiterais telecherger 100 fichiers en
parallele (threads)
Je ne vais pas ouvrir 100 connections distinctes au serveur ?


Pas de soucis, si ton application ouvre une socket tcp et que chaque
threads

s'appuis sur cette socket. Tu auras alors une seule connexion via le
serveur.

Cependant, il faut que l'application serveur le supporte et que ton
utilisation de la socket soit en mode non bloquant.

--
SebF

http://www.frameip.com
Pour ceux qui aiment TCPIP

Email :
H323 : h323.frameip.com





Jacques Caron
Le #519899
On Thu, 8 Apr 2004 16:56:40 +0200, Bruno Nogent wrote:

Une application cliente qui souhaiterais telecherger 100 fichiers en
parallele (threads)
Je ne vais pas ouvrir 100 connections distinctes au serveur ?


Pourquoi pas? Le seul inconvénient c'est l'overhead d'ouverture d'une
connexion TCP, et éventuellement la gestion de la congestion, mais l'un
comme l'autre ne sont un problème que pour des tous petits échanges. S'il
s'agit de 100 transferts de fichiers un tant soit peu importants (quelques
dizaines de Ko), autant les faire séparément.

Sinon il faudra construire sa propre solution de multiplexage sur la
connexion TCP, et bien entendu, comme un seul thread à la fois peut lire
sur un socket donné, il faudra un thread (ou un autre processus) pour
faire le tri et tout renvoyer aux différents threads par un autre moyen
d'IPC. Ou alors introduire un système par lequel un thread lit un peu de
données, trouve à qui ça va, et indique au thread de destination combien
il doit lire avant de repasser la main. Bref, des trucs tordus.

Si tu avais plus de détails sur l'application on pourrait peut-être
t'aiguiller vers la meilleure solution, mais pour le moment il me semble
que le plus simple est d'avoir une connexion par thread.

Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/

Jacques Caron
Le #519898
On Thu, 8 Apr 2004 17:00:31 +0200, www.frameip.com

Pas de soucis, si ton application ouvre une socket tcp et que chaque
threads s'appuis sur cette socket. Tu auras alors une seule connexion
via le serveur.


Euh, moi je vois tout plein de soucis en perspective: il faut bien gérer
la façon dont les différents threads vont se "partager" les données
reçues, et faire en sorte que les données émises restent cohérentes... Ce
serait un peu comme avoir plusieurs threads qui essaient de lire stdin en
même temps...

Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/

www.frameip.com
Le #519897
"Jacques Caron"
On Thu, 8 Apr 2004 17:00:31 +0200, www.frameip.com

Euh, moi je vois tout plein de soucis en perspective: il faut bien gérer
la façon dont les différents threads vont se "partager" les données
reçues, et faire en sorte que les données émises restent cohérentes... Ce
serait un peu comme avoir plusieurs threads qui essaient de lire stdin en
même temps...


Oui c'est ça, mais je le voyais avec un seul thread qui lit le buffer et qui
dispatch aux autres. Il faut bien entendu que le serveur soit compatible,
car n'ayant plus le numéro du port source pour distinguer l'application, il
faudra bien le gérer autrement.

Sinon, tu as raison, c'est juste une possibilité exposé afin de démontrer la
faisabilité. Elle est fonctionnelle avec beaucoup de soucis en perspective.

Et vaut mieux gérer les problèmes que tu as cités précédemment plutôt que
les problèmes des threads.

--
SebF

http://www.frameip.com
Pour ceux qui aiment TCPIP

Email :
H323 : h323.frameip.com

Bruno Nogent
Le #519685
Imaginons une application qui permet de se connecter a un serveur
de donnees boursieres.

Avec une connection (socket), le client veut pouvoir s'abonner a recevoir
les changments de cours boursiers de differentes entreprises.

Inaginons que l'on lance les requettes (logiques) suivantes sur le serveur
'Register me on Microsoft'
et
'Register me on Yahoo'

-> le serveur renverrai des donnees ordonnees (contrainte de temps des
evenements) et pour differentes requettes.

Merci



"Jacques Caron" news:
On Thu, 8 Apr 2004 16:56:40 +0200, Bruno Nogent wrote:

Une application cliente qui souhaiterais telecherger 100 fichiers en
parallele (threads)
Je ne vais pas ouvrir 100 connections distinctes au serveur ?


Pourquoi pas? Le seul inconvénient c'est l'overhead d'ouverture d'une
connexion TCP, et éventuellement la gestion de la congestion, mais l'un
comme l'autre ne sont un problème que pour des tous petits échanges. S'il
s'agit de 100 transferts de fichiers un tant soit peu importants (quelques
dizaines de Ko), autant les faire séparément.

Sinon il faudra construire sa propre solution de multiplexage sur la
connexion TCP, et bien entendu, comme un seul thread à la fois peut lire
sur un socket donné, il faudra un thread (ou un autre processus) pour
faire le tri et tout renvoyer aux différents threads par un autre moyen
d'IPC. Ou alors introduire un système par lequel un thread lit un peu de
données, trouve à qui ça va, et indique au thread de destination combien
il doit lire avant de repasser la main. Bref, des trucs tordus.

Si tu avais plus de détails sur l'application on pourrait peut-être
t'aiguiller vers la meilleure solution, mais pour le moment il me semble
que le plus simple est d'avoir une connexion par thread.

Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/



Jacques Caron
Le #519684
On Fri, 9 Apr 2004 00:19:35 +0200, Bruno Nogent wrote:

Imaginons une application qui permet de se connecter a un serveur
de donnees boursieres.

Avec une connection (socket), le client veut pouvoir s'abonner a recevoir
les changments de cours boursiers de differentes entreprises.

Inaginons que l'on lance les requettes (logiques) suivantes sur le
serveur
'Register me on Microsoft'
et
'Register me on Yahoo'

-> le serveur renverrai des donnees ordonnees (contrainte de temps des
evenements) et pour differentes requettes.


Mais je ne vois pas où sont les threads multiples côté client? Ou côté
serveur pour une connexion unique, d'ailleurs...

A part ça c'est plutôt simple, il suffit de définir des commandes pour
demander les cours de tel ou tel symbole (après bien entendu quelques
commandes d'authentification), genre "REGISTER YHOO"+CR+LF (et quelques
autres commandes genre annuler un symbole, quitter...), et dans l'autre
sens un format standard de données (genre
"DATA:YHOO,08/04/2004,12:00,123.45"+CR+LF et quelques autres formats pour
les "réponses" aux requêtes). Et voilà. Non?

Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/

Bruno Nogent
Le #519683
mais pour la gestion ordonnee des messages successifs ?

"Jacques Caron" news:
On Fri, 9 Apr 2004 00:19:35 +0200, Bruno Nogent wrote:

Imaginons une application qui permet de se connecter a un serveur
de donnees boursieres.

Avec une connection (socket), le client veut pouvoir s'abonner a
recevoir


les changments de cours boursiers de differentes entreprises.

Inaginons que l'on lance les requettes (logiques) suivantes sur le
serveur
'Register me on Microsoft'
et
'Register me on Yahoo'

-> le serveur renverrai des donnees ordonnees (contrainte de temps des
evenements) et pour differentes requettes.


Mais je ne vois pas où sont les threads multiples côté client? Ou côté
serveur pour une connexion unique, d'ailleurs...

A part ça c'est plutôt simple, il suffit de définir des commandes pour
demander les cours de tel ou tel symbole (après bien entendu quelques
commandes d'authentification), genre "REGISTER YHOO"+CR+LF (et quelques
autres commandes genre annuler un symbole, quitter...), et dans l'autre
sens un format standard de données (genre
"DATA:YHOO,08/04/2004,12:00,123.45"+CR+LF et quelques autres formats pour
les "réponses" aux requêtes). Et voilà. Non?

Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/



Publicité
Poster une réponse
Anonyme