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
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Quentin Pouplard
Bruno Nogent wrote:
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 ?
Euh... TCP?
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
Ah non les trucs à trois, ça le fait pas ;) Si par connexion tu entends la connexion physique, soit, mais niveau logique, tu auras deux connexions une vers ton serveur A et une vers ton serveur B.
Comment fragmenter les grands messages et traiter les messages destines aux services differents
En général, c'est la pile TCP/IP qui gère ça pour toi, côté application tu vois un stream continu de donnée, l'os s'occupe pour toi de couper en paquet, les recevoir, les reconstituer et garantir (dans une certaines mesures) leur validité.
Enfin, amha, la question réellement intéressante: quelle service veux tu faire fonctionner? Parce qu'il y'a de forte chance qu'il existe déjà un protocole de plus haut niveau adapté à ton problème.
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 ?
Euh... TCP?
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
Ah non les trucs à trois, ça le fait pas ;) Si par connexion tu entends
la connexion physique, soit, mais niveau logique, tu auras deux
connexions une vers ton serveur A et une vers ton serveur B.
Comment fragmenter les grands messages et traiter les messages
destines aux services differents
En général, c'est la pile TCP/IP qui gère ça pour toi, côté application
tu vois un stream continu de donnée, l'os s'occupe pour toi de couper en
paquet, les recevoir, les reconstituer et garantir (dans une certaines
mesures) leur validité.
Enfin, amha, la question réellement intéressante: quelle service veux tu
faire fonctionner? Parce qu'il y'a de forte chance qu'il existe déjà un
protocole de plus haut niveau adapté à ton problème.
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 ?
Euh... TCP?
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
Ah non les trucs à trois, ça le fait pas ;) Si par connexion tu entends la connexion physique, soit, mais niveau logique, tu auras deux connexions une vers ton serveur A et une vers ton serveur B.
Comment fragmenter les grands messages et traiter les messages destines aux services differents
En général, c'est la pile TCP/IP qui gère ça pour toi, côté application tu vois un stream continu de donnée, l'os s'occupe pour toi de couper en paquet, les recevoir, les reconstituer et garantir (dans une certaines mesures) leur validité.
Enfin, amha, la question réellement intéressante: quelle service veux tu faire fonctionner? Parce qu'il y'a de forte chance qu'il existe déjà un protocole de plus haut niveau adapté à ton problème.
Exemple : Telecharger en parallele (plusiseurs thread) plusieurs fichiers mais avec une seule connection (socket)
- Le serveur enverrai de gros fichiers qui seront obligatoirment morceles, par TCP/IP, mais par l'application egalement car les fichiers sont plus gros que la taille de reception du client (buffer) ?
- Les messages pasant entre les deux sockets doivent contenir l'information permettant d'identifier a quel fichier correpondent les donnees du message. ?
- Les messages individuels ne seront peut etre pas recus dans l'ordre ?
Merci
"Quentin Pouplard" wrote in message news:
Bruno Nogent wrote: > 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 ?
Euh... TCP?
> 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
Ah non les trucs à trois, ça le fait pas ;) Si par connexion tu entends la connexion physique, soit, mais niveau logique, tu auras deux connexions une vers ton serveur A et une vers ton serveur B.
> Comment fragmenter les grands messages et traiter les messages > destines aux services differents
En général, c'est la pile TCP/IP qui gère ça pour toi, côté application tu vois un stream continu de donnée, l'os s'occupe pour toi de couper en paquet, les recevoir, les reconstituer et garantir (dans une certaines mesures) leur validité.
Enfin, amha, la question réellement intéressante: quelle service veux tu faire fonctionner? Parce qu'il y'a de forte chance qu'il existe déjà un protocole de plus haut niveau adapté à ton problème.
Exemple :
Telecharger en parallele (plusiseurs thread) plusieurs fichiers mais avec
une seule connection (socket)
- Le serveur enverrai de gros fichiers qui seront obligatoirment morceles,
par TCP/IP, mais par l'application egalement car les fichiers sont plus gros
que la taille de reception du client (buffer) ?
- Les messages pasant entre les deux sockets doivent contenir l'information
permettant d'identifier a quel fichier correpondent les donnees du message.
?
- Les messages individuels ne seront peut etre pas recus dans l'ordre ?
Merci
"Quentin Pouplard" <poubelle@alrj.org> wrote in message
news:99_2004_164240_146330516_MYOE@news.free.fr...
Bruno Nogent wrote:
> 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 ?
Euh... TCP?
> 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
Ah non les trucs à trois, ça le fait pas ;) Si par connexion tu entends
la connexion physique, soit, mais niveau logique, tu auras deux
connexions une vers ton serveur A et une vers ton serveur B.
> Comment fragmenter les grands messages et traiter les messages
> destines aux services differents
En général, c'est la pile TCP/IP qui gère ça pour toi, côté application
tu vois un stream continu de donnée, l'os s'occupe pour toi de couper en
paquet, les recevoir, les reconstituer et garantir (dans une certaines
mesures) leur validité.
Enfin, amha, la question réellement intéressante: quelle service veux tu
faire fonctionner? Parce qu'il y'a de forte chance qu'il existe déjà un
protocole de plus haut niveau adapté à ton problème.
Exemple : Telecharger en parallele (plusiseurs thread) plusieurs fichiers mais avec une seule connection (socket)
- Le serveur enverrai de gros fichiers qui seront obligatoirment morceles, par TCP/IP, mais par l'application egalement car les fichiers sont plus gros que la taille de reception du client (buffer) ?
- Les messages pasant entre les deux sockets doivent contenir l'information permettant d'identifier a quel fichier correpondent les donnees du message. ?
- Les messages individuels ne seront peut etre pas recus dans l'ordre ?
Merci
"Quentin Pouplard" wrote in message news:
Bruno Nogent wrote: > 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 ?
Euh... TCP?
> 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
Ah non les trucs à trois, ça le fait pas ;) Si par connexion tu entends la connexion physique, soit, mais niveau logique, tu auras deux connexions une vers ton serveur A et une vers ton serveur B.
> Comment fragmenter les grands messages et traiter les messages > destines aux services differents
En général, c'est la pile TCP/IP qui gère ça pour toi, côté application tu vois un stream continu de donnée, l'os s'occupe pour toi de couper en paquet, les recevoir, les reconstituer et garantir (dans une certaines mesures) leur validité.
Enfin, amha, la question réellement intéressante: quelle service veux tu faire fonctionner? Parce qu'il y'a de forte chance qu'il existe déjà un protocole de plus haut niveau adapté à ton problème.
Exemple : Telecharger en parallele (plusiseurs thread) plusieurs fichiers mais avec une seule connection (socket)
- Le serveur enverrai de gros fichiers qui seront obligatoirment morceles, par TCP/IP, mais par l'application egalement car les fichiers sont plus gros que la taille de reception du client (buffer) ?
- Les messages pasant entre les deux sockets doivent contenir l'information permettant d'identifier a quel fichier correpondent les donnees du message. ?
- Les messages individuels ne seront peut etre pas recus dans l'ordre
OK. Je crois que tu as un certain nombre d'idées fausses sur les sockets TCP/IP. Tu peux parfaitement envoyer un message d'un giga-octet sur une socket TCP/IP. La taille des "buffers", on s'en tape, et les octets émis à un bout du tuyau arriveront dans le même ordre à l'autre bout.
Bruno Nogent a écrit :
Exemple :
Telecharger en parallele (plusiseurs thread)
plusieurs fichiers mais avec une seule connection
(socket)
- Le serveur enverrai de gros fichiers qui seront
obligatoirment morceles, par TCP/IP, mais par
l'application egalement car les fichiers sont plus
gros que la taille de reception du client (buffer) ?
- Les messages pasant entre les deux sockets doivent
contenir l'information permettant d'identifier a quel
fichier correpondent les donnees du message. ?
- Les messages individuels ne seront peut etre pas
recus dans l'ordre
OK. Je crois que tu as un certain nombre d'idées fausses
sur les sockets TCP/IP. Tu peux parfaitement envoyer
un message d'un giga-octet sur une socket TCP/IP. La
taille des "buffers", on s'en tape, et les octets émis
à un bout du tuyau arriveront dans le même ordre à l'autre
bout.
Exemple : Telecharger en parallele (plusiseurs thread) plusieurs fichiers mais avec une seule connection (socket)
- Le serveur enverrai de gros fichiers qui seront obligatoirment morceles, par TCP/IP, mais par l'application egalement car les fichiers sont plus gros que la taille de reception du client (buffer) ?
- Les messages pasant entre les deux sockets doivent contenir l'information permettant d'identifier a quel fichier correpondent les donnees du message. ?
- Les messages individuels ne seront peut etre pas recus dans l'ordre
OK. Je crois que tu as un certain nombre d'idées fausses sur les sockets TCP/IP. Tu peux parfaitement envoyer un message d'un giga-octet sur une socket TCP/IP. La taille des "buffers", on s'en tape, et les octets émis à un bout du tuyau arriveront dans le même ordre à l'autre bout.
Quentin Pouplard
Bruno Nogent wrote:
Exemple : Telecharger en parallele (plusiseurs thread) plusieurs fichiers mais avec une seule connection (socket)
Pourquoi utiliser une seule connexion?
- Le serveur enverrai de gros fichiers qui seront obligatoirment morceles, par TCP/IP, mais par l'application egalement car les fichiers sont plus gros que la taille de reception du client (buffer) ?
???? Qu'est ce que tu appelles la "taille de réception du client (buffer)"? Il est clair que tu recevras le fichier petit à petit, c'est le principe d'un stream...
- Les messages pasant entre les deux sockets doivent contenir l'information permettant d'identifier a quel fichier correpondent les donnees du message. ?
Tout dépend de ce que tu fais...
- Les messages individuels ne seront peut etre pas recus dans l'ordre ?
TCP garantit l'ordre de réception des paquets.
Parle nous plutôt de l'objectif réel, pas de ce que tu penses être un bout de solution... là tu veux vaguement faire du TCP dans du TCP ça s'appelle du tunneling. Si c'est uniquement le transfert de fichier, le FTP en mode passif et actif devrait te fournir ce dont tu as besoin... bref...
Exemple :
Telecharger en parallele (plusiseurs thread) plusieurs fichiers mais
avec une seule connection (socket)
Pourquoi utiliser une seule connexion?
- Le serveur enverrai de gros fichiers qui seront obligatoirment
morceles, par TCP/IP, mais par l'application egalement car les
fichiers sont plus gros que la taille de reception du client (buffer)
?
???? Qu'est ce que tu appelles la "taille de réception du client
(buffer)"? Il est clair que tu recevras le fichier petit à petit, c'est
le principe d'un stream...
- Les messages pasant entre les deux sockets doivent contenir
l'information permettant d'identifier a quel fichier correpondent les
donnees du message.
?
Tout dépend de ce que tu fais...
- Les messages individuels ne seront peut etre pas recus dans l'ordre
?
TCP garantit l'ordre de réception des paquets.
Parle nous plutôt de l'objectif réel, pas de ce que tu penses être un
bout de solution... là tu veux vaguement faire du TCP dans du TCP ça
s'appelle du tunneling. Si c'est uniquement le transfert de fichier, le
FTP en mode passif et actif devrait te fournir ce dont tu as besoin...
bref...
Exemple : Telecharger en parallele (plusiseurs thread) plusieurs fichiers mais avec une seule connection (socket)
Pourquoi utiliser une seule connexion?
- Le serveur enverrai de gros fichiers qui seront obligatoirment morceles, par TCP/IP, mais par l'application egalement car les fichiers sont plus gros que la taille de reception du client (buffer) ?
???? Qu'est ce que tu appelles la "taille de réception du client (buffer)"? Il est clair que tu recevras le fichier petit à petit, c'est le principe d'un stream...
- Les messages pasant entre les deux sockets doivent contenir l'information permettant d'identifier a quel fichier correpondent les donnees du message. ?
Tout dépend de ce que tu fais...
- Les messages individuels ne seront peut etre pas recus dans l'ordre ?
TCP garantit l'ordre de réception des paquets.
Parle nous plutôt de l'objectif réel, pas de ce que tu penses être un bout de solution... là tu veux vaguement faire du TCP dans du TCP ça s'appelle du tunneling. Si c'est uniquement le transfert de fichier, le FTP en mode passif et actif devrait te fournir ce dont tu as besoin... bref...
Imaginons que j'ai un serveur ou plusieurs services tournent ( des threads font des calculs en boucle ) Le thread A fait un certain type de calculs Le thread B fait un certain type de calculs
Le client aurait la possibilite de s'abonner a differents services A ou B avec une seule connection ( une seule connection socket sur le serveur)
-> Les messages renvoyes serait plus gros que le buffer de reception du client -> L'ordre des resultats renvoyes par le serveur devrait etre maintenu
Il faut bien identifier quel service repond ?
"Quentin Pouplard" wrote in message news:
Bruno Nogent wrote: > Exemple : > Telecharger en parallele (plusiseurs thread) plusieurs fichiers mais > avec une seule connection (socket)
Pourquoi utiliser une seule connexion?
> - Le serveur enverrai de gros fichiers qui seront obligatoirment > morceles, par TCP/IP, mais par l'application egalement car les > fichiers sont plus gros que la taille de reception du client (buffer) > ?
???? Qu'est ce que tu appelles la "taille de réception du client (buffer)"? Il est clair que tu recevras le fichier petit à petit, c'est le principe d'un stream...
> - Les messages pasant entre les deux sockets doivent contenir > l'information permettant d'identifier a quel fichier correpondent les > donnees du message. > ?
Tout dépend de ce que tu fais...
> - Les messages individuels ne seront peut etre pas recus dans l'ordre > ?
TCP garantit l'ordre de réception des paquets.
Parle nous plutôt de l'objectif réel, pas de ce que tu penses être un bout de solution... là tu veux vaguement faire du TCP dans du TCP ça s'appelle du tunneling. Si c'est uniquement le transfert de fichier, le FTP en mode passif et actif devrait te fournir ce dont tu as besoin... bref...
Imaginons que j'ai un serveur ou plusieurs services tournent ( des threads
font des calculs en boucle )
Le thread A fait un certain type de calculs
Le thread B fait un certain type de calculs
Le client aurait la possibilite de s'abonner a differents services A ou B
avec une seule connection ( une seule connection socket sur le serveur)
-> Les messages renvoyes serait plus gros que le buffer de reception du
client
-> L'ordre des resultats renvoyes par le serveur devrait etre maintenu
Il faut bien identifier quel service repond ?
"Quentin Pouplard" <poubelle@alrj.org> wrote in message
news:99_2004_171210_1914970388_MYOE@news.free.fr...
Bruno Nogent wrote:
> Exemple :
> Telecharger en parallele (plusiseurs thread) plusieurs fichiers mais
> avec une seule connection (socket)
Pourquoi utiliser une seule connexion?
> - Le serveur enverrai de gros fichiers qui seront obligatoirment
> morceles, par TCP/IP, mais par l'application egalement car les
> fichiers sont plus gros que la taille de reception du client (buffer)
> ?
???? Qu'est ce que tu appelles la "taille de réception du client
(buffer)"? Il est clair que tu recevras le fichier petit à petit, c'est
le principe d'un stream...
> - Les messages pasant entre les deux sockets doivent contenir
> l'information permettant d'identifier a quel fichier correpondent les
> donnees du message.
> ?
Tout dépend de ce que tu fais...
> - Les messages individuels ne seront peut etre pas recus dans l'ordre
> ?
TCP garantit l'ordre de réception des paquets.
Parle nous plutôt de l'objectif réel, pas de ce que tu penses être un
bout de solution... là tu veux vaguement faire du TCP dans du TCP ça
s'appelle du tunneling. Si c'est uniquement le transfert de fichier, le
FTP en mode passif et actif devrait te fournir ce dont tu as besoin...
bref...
Imaginons que j'ai un serveur ou plusieurs services tournent ( des threads font des calculs en boucle ) Le thread A fait un certain type de calculs Le thread B fait un certain type de calculs
Le client aurait la possibilite de s'abonner a differents services A ou B avec une seule connection ( une seule connection socket sur le serveur)
-> Les messages renvoyes serait plus gros que le buffer de reception du client -> L'ordre des resultats renvoyes par le serveur devrait etre maintenu
Il faut bien identifier quel service repond ?
"Quentin Pouplard" wrote in message news:
Bruno Nogent wrote: > Exemple : > Telecharger en parallele (plusiseurs thread) plusieurs fichiers mais > avec une seule connection (socket)
Pourquoi utiliser une seule connexion?
> - Le serveur enverrai de gros fichiers qui seront obligatoirment > morceles, par TCP/IP, mais par l'application egalement car les > fichiers sont plus gros que la taille de reception du client (buffer) > ?
???? Qu'est ce que tu appelles la "taille de réception du client (buffer)"? Il est clair que tu recevras le fichier petit à petit, c'est le principe d'un stream...
> - Les messages pasant entre les deux sockets doivent contenir > l'information permettant d'identifier a quel fichier correpondent les > donnees du message. > ?
Tout dépend de ce que tu fais...
> - Les messages individuels ne seront peut etre pas recus dans l'ordre > ?
TCP garantit l'ordre de réception des paquets.
Parle nous plutôt de l'objectif réel, pas de ce que tu penses être un bout de solution... là tu veux vaguement faire du TCP dans du TCP ça s'appelle du tunneling. Si c'est uniquement le transfert de fichier, le FTP en mode passif et actif devrait te fournir ce dont tu as besoin... bref...
Daccord mais avec plusieurs threads qui lisent sur la meme socket comment savoir a quel fichier appartiennent les donnees ?
"Manuel Leclerc" wrote in message news:40756ae5$
Bruno Nogent a écrit :
> Exemple : > Telecharger en parallele (plusiseurs thread) > plusieurs fichiers mais avec une seule connection > (socket) > > - Le serveur enverrai de gros fichiers qui seront > obligatoirment morceles, par TCP/IP, mais par > l'application egalement car les fichiers sont plus > gros que la taille de reception du client (buffer) ? > > - Les messages pasant entre les deux sockets doivent > contenir l'information permettant d'identifier a quel > fichier correpondent les donnees du message. ? > > - Les messages individuels ne seront peut etre pas > recus dans l'ordre
OK. Je crois que tu as un certain nombre d'idées fausses sur les sockets TCP/IP. Tu peux parfaitement envoyer un message d'un giga-octet sur une socket TCP/IP. La taille des "buffers", on s'en tape, et les octets émis à un bout du tuyau arriveront dans le même ordre à l'autre bout.
Daccord mais avec plusieurs threads qui lisent sur la meme socket
comment savoir a quel fichier appartiennent les donnees ?
"Manuel Leclerc" <manuel.leclerc@alussinan.org> wrote in message
news:40756ae5$1@neottia.net...
Bruno Nogent a écrit :
> Exemple :
> Telecharger en parallele (plusiseurs thread)
> plusieurs fichiers mais avec une seule connection
> (socket)
>
> - Le serveur enverrai de gros fichiers qui seront
> obligatoirment morceles, par TCP/IP, mais par
> l'application egalement car les fichiers sont plus
> gros que la taille de reception du client (buffer) ?
>
> - Les messages pasant entre les deux sockets doivent
> contenir l'information permettant d'identifier a quel
> fichier correpondent les donnees du message. ?
>
> - Les messages individuels ne seront peut etre pas
> recus dans l'ordre
OK. Je crois que tu as un certain nombre d'idées fausses
sur les sockets TCP/IP. Tu peux parfaitement envoyer
un message d'un giga-octet sur une socket TCP/IP. La
taille des "buffers", on s'en tape, et les octets émis
à un bout du tuyau arriveront dans le même ordre à l'autre
bout.
Daccord mais avec plusieurs threads qui lisent sur la meme socket comment savoir a quel fichier appartiennent les donnees ?
"Manuel Leclerc" wrote in message news:40756ae5$
Bruno Nogent a écrit :
> Exemple : > Telecharger en parallele (plusiseurs thread) > plusieurs fichiers mais avec une seule connection > (socket) > > - Le serveur enverrai de gros fichiers qui seront > obligatoirment morceles, par TCP/IP, mais par > l'application egalement car les fichiers sont plus > gros que la taille de reception du client (buffer) ? > > - Les messages pasant entre les deux sockets doivent > contenir l'information permettant d'identifier a quel > fichier correpondent les donnees du message. ? > > - Les messages individuels ne seront peut etre pas > recus dans l'ordre
OK. Je crois que tu as un certain nombre d'idées fausses sur les sockets TCP/IP. Tu peux parfaitement envoyer un message d'un giga-octet sur une socket TCP/IP. La taille des "buffers", on s'en tape, et les octets émis à un bout du tuyau arriveront dans le même ordre à l'autre bout.
Quentin Pouplard
Bruno Nogent wrote:
Imaginons que j'ai un serveur ou plusieurs services tournent ( des threads font des calculs en boucle ) Le thread A fait un certain type de calculs Le thread B fait un certain type de calculs
Le client aurait la possibilite de s'abonner a differents services A ou B avec une seule connection ( une seule connection socket sur le serveur)
Rapport? tu mélanges un peu tout là... peu importe d'où viennent les données, ce n'est pas parce que c'est 2 threads qui les calculent que tu as 2 serveurs... Demande toi ce que le client voit et ce qu'il attends, pas ce qu'il croit connaître du serveur...
-> Les messages renvoyes serait plus gros que le buffer de reception du client
Mais qu'est ce que "le buffer de reception du client" ?
-> L'ordre des resultats renvoyes par le serveur devrait etre maintenu
RTFM TCP...
Il faut bien identifier quel service repond ?
Tu mélanges serveurs, threads, services, calculs, ...
Imaginons que j'ai un serveur ou plusieurs services tournent ( des
threads font des calculs en boucle ) Le thread A fait un certain type
de calculs Le thread B fait un certain type de calculs
Le client aurait la possibilite de s'abonner a differents services A
ou B avec une seule connection ( une seule connection socket sur le
serveur)
Rapport? tu mélanges un peu tout là... peu importe d'où viennent les
données, ce n'est pas parce que c'est 2 threads qui les calculent que tu
as 2 serveurs... Demande toi ce que le client voit et ce qu'il attends,
pas ce qu'il croit connaître du serveur...
-> Les messages renvoyes serait plus gros que le buffer de reception
du client
Mais qu'est ce que "le buffer de reception du client" ?
-> L'ordre des resultats renvoyes par le serveur devrait
etre maintenu
RTFM TCP...
Il faut bien identifier quel service repond ?
Tu mélanges serveurs, threads, services, calculs, ...
Imaginons que j'ai un serveur ou plusieurs services tournent ( des threads font des calculs en boucle ) Le thread A fait un certain type de calculs Le thread B fait un certain type de calculs
Le client aurait la possibilite de s'abonner a differents services A ou B avec une seule connection ( une seule connection socket sur le serveur)
Rapport? tu mélanges un peu tout là... peu importe d'où viennent les données, ce n'est pas parce que c'est 2 threads qui les calculent que tu as 2 serveurs... Demande toi ce que le client voit et ce qu'il attends, pas ce qu'il croit connaître du serveur...
-> Les messages renvoyes serait plus gros que le buffer de reception du client
Mais qu'est ce que "le buffer de reception du client" ?
-> L'ordre des resultats renvoyes par le serveur devrait etre maintenu
RTFM TCP...
Il faut bien identifier quel service repond ?
Tu mélanges serveurs, threads, services, calculs, ...
D'accord mais avec plusieurs threads qui lisent sur la meme socket comment savoir a quel fichier appartiennent les donnees ?
Si tu veux faire passer plusieurs tuyaux logiques dans un même tuyau physique, tu dois effectivement mettre en place un protocole, et là je n'ai pas d'idées particulière sur la question, ça dépends un peu du genre de "propriétés" que tu souhaites obtenir.
La question IMPORTANTE avant de se lancer dans l'étude d'un tel protocole : POURQUOI un seul tuyau physique ?
-- I don't believe Microsoft SHOULD have a right to prevent me from distributing an application that calls some internal functions in one of Excel's DLL files, period. Why is it a "Good Thing" if GPL authors are allowed to restrict me in this way? --Michael Weiss-Malik
Bruno Nogent a écrit :
D'accord mais avec plusieurs threads qui lisent sur la
meme socket comment savoir a quel fichier appartiennent
les donnees ?
Si tu veux faire passer plusieurs tuyaux logiques dans
un même tuyau physique, tu dois effectivement mettre en
place un protocole, et là je n'ai pas d'idées particulière
sur la question, ça dépends un peu du genre de "propriétés"
que tu souhaites obtenir.
La question IMPORTANTE avant de se lancer dans l'étude d'un
tel protocole : POURQUOI un seul tuyau physique ?
--
I don't believe Microsoft SHOULD have a right to prevent me from
distributing an application that calls some internal functions in one
of Excel's DLL files, period. Why is it a "Good Thing" if GPL authors
are allowed to restrict me in this way? --Michael Weiss-Malik
D'accord mais avec plusieurs threads qui lisent sur la meme socket comment savoir a quel fichier appartiennent les donnees ?
Si tu veux faire passer plusieurs tuyaux logiques dans un même tuyau physique, tu dois effectivement mettre en place un protocole, et là je n'ai pas d'idées particulière sur la question, ça dépends un peu du genre de "propriétés" que tu souhaites obtenir.
La question IMPORTANTE avant de se lancer dans l'étude d'un tel protocole : POURQUOI un seul tuyau physique ?
-- I don't believe Microsoft SHOULD have a right to prevent me from distributing an application that calls some internal functions in one of Excel's DLL files, period. Why is it a "Good Thing" if GPL authors are allowed to restrict me in this way? --Michael Weiss-Malik
