Temps d'acces de lecture sur socket
LaTatadu91
Messages postés
968
Date d'inscription
jeudi 20 mai 2004
Statut
Membre
Dernière intervention
26 avril 2013
-
27 août 2007 à 13:24
LaTatadu91 Messages postés 968 Date d'inscription jeudi 20 mai 2004 Statut Membre Dernière intervention 26 avril 2013 - 27 août 2007 à 16:41
LaTatadu91 Messages postés 968 Date d'inscription jeudi 20 mai 2004 Statut Membre Dernière intervention 26 avril 2013 - 27 août 2007 à 16:41
A voir également:
- Temps d'acces de lecture sur socket
- Compteur de temps - Forum C# / .NET
- Créer emploi du temps en ligne - Forum Java
- Python socket timeout - Forum Python
- Diagramme de classe emploi du temps ✓ - Forum Java
- Emploi du temps scolaire à remplir - Forum PHP
3 réponses
cs_vicenzo
Messages postés
178
Date d'inscription
mardi 16 août 2005
Statut
Membre
Dernière intervention
25 août 2010
1
27 août 2007 à 13:58
27 août 2007 à 13:58
Tu peux enchainer chaque transmission par un send /recv (envoi du message, attente acquittement).
Comme ca aucun souci..
Comme ca aucun souci..
cs_aardman
Messages postés
1905
Date d'inscription
mercredi 22 janvier 2003
Statut
Membre
Dernière intervention
17 septembre 2012
3
27 août 2007 à 16:29
27 août 2007 à 16:29
Salut,
Il faut avoir une vision plus générale du probleme (qui n'en est pas
un): rien ne te dis qu'un send sur un socket provoquera un recv a
l'autre bout du socket. Ca veut dire que tu peux recevoir un ou
plusieur 'messages' lors d'un recv, voire même un morceau de 'message'
incomplet. Ce concept de message n'existe pas au niveau TCP, c'est donc
a ton application de gerer tout ca.
Généralement on envoie la taille du message avant celui ci ou alors on
utilise des separateurs de messages (comme \r\n, utilise par plein de
protocols de type texte). Mettre en place un systeme d'acquittement ca
marcherait, mais ca ralentirait inutilement le prog.
Il faut avoir une vision plus générale du probleme (qui n'en est pas
un): rien ne te dis qu'un send sur un socket provoquera un recv a
l'autre bout du socket. Ca veut dire que tu peux recevoir un ou
plusieur 'messages' lors d'un recv, voire même un morceau de 'message'
incomplet. Ce concept de message n'existe pas au niveau TCP, c'est donc
a ton application de gerer tout ca.
Généralement on envoie la taille du message avant celui ci ou alors on
utilise des separateurs de messages (comme \r\n, utilise par plein de
protocols de type texte). Mettre en place un systeme d'acquittement ca
marcherait, mais ca ralentirait inutilement le prog.
LaTatadu91
Messages postés
968
Date d'inscription
jeudi 20 mai 2004
Statut
Membre
Dernière intervention
26 avril 2013
1
27 août 2007 à 16:41
27 août 2007 à 16:41
yes effectivement, j'ai donc coder en qlq lignes si la taille du message reçu n'est aps celle attendu on decrypte la fin de la trame...
ca semble etre le mieux!
par contre heureusement je ne suis aps tomber sur un cas inverse avec un message incomplet. je ne peux aps faire du send receive car je ne peux pas faire un truc bloquant il faut que mon appli tourne meme si des messages n'arrivent pas ...
merci pr vos explications
ca semble etre le mieux!
par contre heureusement je ne suis aps tomber sur un cas inverse avec un message incomplet. je ne peux aps faire du send receive car je ne peux pas faire un truc bloquant il faut que mon appli tourne meme si des messages n'arrivent pas ...
merci pr vos explications