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 ?
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 ?
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 ?
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/
Salut,
On Thu, 8 Apr 2004 15:04:58 +0200, Bruno Nogent <bruno.nogent@metaxis.fr>
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/
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/
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 ?
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 ?
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 ?
"Bruno Nogent" a écrit dans le message de news:
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" <bruno.nogent@metaxis.fr> a écrit dans le message de news:
c53p7m$e36$1@s1.read.news.oleane.net...
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 : sebf@frameip.com.pas.de.spam
H323 : h323.frameip.com
"Bruno Nogent" a écrit dans le message de news:
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
Une application cliente qui souhaiterais telecherger 100 fichiers en
parallele (threads)
Je ne vais pas ouvrir 100 connections distinctes au serveur ?
Une application cliente qui souhaiterais telecherger 100 fichiers en
parallele (threads)
Je ne vais pas ouvrir 100 connections distinctes au serveur ?
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.
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.
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.
On Thu, 8 Apr 2004 17:00:31 +0200, www.frameip.com
wrote:
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...
On Thu, 8 Apr 2004 17:00:31 +0200, www.frameip.com
<sebf@frameip.com.pas.de.spam> wrote:
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...
On Thu, 8 Apr 2004 17:00:31 +0200, www.frameip.com
wrote:
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...
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/
On Thu, 8 Apr 2004 16:56:40 +0200, Bruno Nogent <bruno.nogent@metaxis.fr>
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/
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/
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.
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.
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.
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/
On Fri, 9 Apr 2004 00:19:35 +0200, Bruno Nogent <bruno.nogent@metaxis.fr>
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/
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/