Bonjour =E0 tous, je fais un serveur de synchronisation SyncML pour
synchroniser des t=E9l=E9phones mobiles.
lorsque le mobile demande une synchronisation au serveur, le serveur
fait un accept() sur la socket qui correspond, lit la demande du
mobile et g=E9n=E8re une r=E9ponse (jusque l=E0, =E7a fonctionne imp=E9cabl=
e)
Le probl=E8me c'est pour envoyer la r=E9ponse, l=E0 je fait la chose
suivante :
(je me suis inspir=E9 des trames sniff=E9es entre le t=E9l=E9phone et un si=
te
de synchronisation).
Sauf que =E7a ne doit pas =EAtre la bonne m=E9thode car quand je sniffe les
trames, ma trame (qui contient les flags PSH et ACK) est suivie d'une
trame provenant du t=E9l=E9phone et contenant les flags FIN et ACK et
aucune donn=E9e. La connection s'arr=EAte alors =E0 ce point.
et quand je compare mes donn=E9es avec celle sinff=E9es entre le mobile et
le site de synchronisation, le contenu de la r=E9ponse est identique, je
pense donc que le probl=E8me vient de la m=E9thode d'envoi.
Pouvez vous m'aider, j'ai un peut de mal =E0 r=E9soudre moi m=EAme...
Bonjour à tous, je fais un serveur de synchronisation SyncML pour synchroniser des téléphones mobiles.
lorsque le mobile demande une synchronisation au serveur, le serveur fait un accept() sur la socket qui correspond, lit la demande du mobile et génère une réponse (jusque là, ça fonctionne impécable) Le problème c'est pour envoyer la réponse, là je fait la chose suivante :
Bonjour à tous, je fais un serveur de synchronisation SyncML pour
synchroniser des téléphones mobiles.
lorsque le mobile demande une synchronisation au serveur, le serveur
fait un accept() sur la socket qui correspond, lit la demande du
mobile et génère une réponse (jusque là, ça fonctionne impécable)
Le problème c'est pour envoyer la réponse, là je fait la chose
suivante :
Bonjour à tous, je fais un serveur de synchronisation SyncML pour synchroniser des téléphones mobiles.
lorsque le mobile demande une synchronisation au serveur, le serveur fait un accept() sur la socket qui correspond, lit la demande du mobile et génère une réponse (jusque là, ça fonctionne impécable) Le problème c'est pour envoyer la réponse, là je fait la chose suivante :
Le n change de valeur selon la plateforme (012 sur Unix, 015 sur Mac et 015 suivi de 012 sur Windows). Il se trouve que sur Unix, ça marche. Mais ce n'est pas propre.
merci pour tes conseil, je remplace donc les rn par des 15 12. J'y gagne un peut en portabilité comme ça. Pour gérer ça proprement, j'ai pas trouvé sur le coup, mais bon maitenant que ça marche, ça m'a permis de mieux comprendre le fonctionnement de tous ça :)
En tout cas, merci à tous, j'ai réussi ce soir ma première synchro avec le téléphonne mobile, preuve que mon serveur de synchronisation fonctionne !
Bingo ! Tu paie le champagne ?-)
Le n change de valeur selon la plateforme (012 sur Unix, 015 sur Mac
et 015 suivi de 012 sur Windows). Il se trouve que sur Unix, ça
marche. Mais ce n'est pas propre.
merci pour tes conseil, je remplace donc les rn par des 15 12.
J'y gagne un peut en portabilité comme ça.
Pour gérer ça proprement, j'ai pas trouvé sur le coup, mais bon
maitenant que ça marche, ça m'a permis de mieux comprendre le
fonctionnement de tous ça :)
En tout cas, merci à tous, j'ai réussi ce soir ma première synchro
avec le téléphonne mobile, preuve que mon serveur de synchronisation
fonctionne !
Le n change de valeur selon la plateforme (012 sur Unix, 015 sur Mac et 015 suivi de 012 sur Windows). Il se trouve que sur Unix, ça marche. Mais ce n'est pas propre.
merci pour tes conseil, je remplace donc les rn par des 15 12. J'y gagne un peut en portabilité comme ça. Pour gérer ça proprement, j'ai pas trouvé sur le coup, mais bon maitenant que ça marche, ça m'a permis de mieux comprendre le fonctionnement de tous ça :)
En tout cas, merci à tous, j'ai réussi ce soir ma première synchro avec le téléphonne mobile, preuve que mon serveur de synchronisation fonctionne !
Bingo ! Tu paie le champagne ?-)
Amaury Forgeot d'Arc
Bonjour,
Bonjour à tous, je fais un serveur de synchronisation SyncML pour synchroniser des téléphones mobiles.
lorsque le mobile demande une synchronisation au serveur, le serveur fait un accept() sur la socket qui correspond, lit la demande du mobile et génère une réponse (jusque là, ça fonctionne impécable) Le problème c'est pour envoyer la réponse, là je fait la chose suivante :
(je me suis inspiré des trames sniffées entre le téléphone et un site de synchronisation).
Sauf que ça ne doit pas être la bonne méthode car quand je sniffe les trames, ma trame (qui contient les flags PSH et ACK) est suivie d'une trame provenant du téléphone et contenant les flags FIN et ACK et aucune donnée. La connection s'arrête alors à ce point.
et quand je compare mes données avec celle sinffées entre le mobile et le site de synchronisation, le contenu de la réponse est identique, je pense donc que le problème vient de la méthode d'envoi.
Pouvez vous m'aider, j'ai un peut de mal à résoudre moi même...
Apès avoir jeté un oeil dans httplib.py, je suggère de remplacer les n par des rn
Au cas où...
-- Amaury
Bonjour,
Bonjour à tous, je fais un serveur de synchronisation SyncML pour
synchroniser des téléphones mobiles.
lorsque le mobile demande une synchronisation au serveur, le serveur
fait un accept() sur la socket qui correspond, lit la demande du
mobile et génère une réponse (jusque là, ça fonctionne impécable)
Le problème c'est pour envoyer la réponse, là je fait la chose
suivante :
(je me suis inspiré des trames sniffées entre le téléphone et un site
de synchronisation).
Sauf que ça ne doit pas être la bonne méthode car quand je sniffe les
trames, ma trame (qui contient les flags PSH et ACK) est suivie d'une
trame provenant du téléphone et contenant les flags FIN et ACK et
aucune donnée. La connection s'arrête alors à ce point.
et quand je compare mes données avec celle sinffées entre le mobile et
le site de synchronisation, le contenu de la réponse est identique, je
pense donc que le problème vient de la méthode d'envoi.
Pouvez vous m'aider, j'ai un peut de mal à résoudre moi même...
Apès avoir jeté un oeil dans httplib.py, je suggère de remplacer les n
par des rn
Bonjour à tous, je fais un serveur de synchronisation SyncML pour synchroniser des téléphones mobiles.
lorsque le mobile demande une synchronisation au serveur, le serveur fait un accept() sur la socket qui correspond, lit la demande du mobile et génère une réponse (jusque là, ça fonctionne impécable) Le problème c'est pour envoyer la réponse, là je fait la chose suivante :
(je me suis inspiré des trames sniffées entre le téléphone et un site de synchronisation).
Sauf que ça ne doit pas être la bonne méthode car quand je sniffe les trames, ma trame (qui contient les flags PSH et ACK) est suivie d'une trame provenant du téléphone et contenant les flags FIN et ACK et aucune donnée. La connection s'arrête alors à ce point.
et quand je compare mes données avec celle sinffées entre le mobile et le site de synchronisation, le contenu de la réponse est identique, je pense donc que le problème vient de la méthode d'envoi.
Pouvez vous m'aider, j'ai un peut de mal à résoudre moi même...
Apès avoir jeté un oeil dans httplib.py, je suggère de remplacer les n par des rn
Au cas où...
-- Amaury
n
Apès avoir jeté un oeil dans httplib.py, je suggère de remplacer le s n par des rn
J'ai oublié de précisé, je suis sous linux. Je ne suis pas certain, mais je crois que c'est seulement sous windows qu'il faut utiliser rn sous linux, le n fait les deux (à confirmer).
Fabien
Apès avoir jeté un oeil dans httplib.py, je suggère de remplacer le s n
par des rn
J'ai oublié de précisé, je suis sous linux.
Je ne suis pas certain, mais je crois que c'est seulement sous windows
qu'il faut utiliser rn sous linux, le n fait les deux (à
confirmer).
Apès avoir jeté un oeil dans httplib.py, je suggère de remplacer le s n par des rn
J'ai oublié de précisé, je suis sous linux. Je ne suis pas certain, mais je crois que c'est seulement sous windows qu'il faut utiliser rn sous linux, le n fait les deux (à confirmer).
Fabien
n
On 22 juil, 08:57, Bruno Desthuilliers wrote:
Bonjour à tous, je fais un serveur de synchronisation SyncML pour synchroniser des téléphones mobiles.
lorsque le mobile demande une synchronisation au serveur, le serveur fait un accept() sur la socket qui correspond, lit la demande du mobile et génère une réponse (jusque là, ça fonctionne impé cable) Le problème c'est pour envoyer la réponse, là je fait la chose suivante :
Je viens de tester avec ce que tu as écris, et ça fonctionne mieux, le mobile ne me répond plus par un FIN et ACK, seulement le ACK (du coup la connexion n'est pas fermée) le problème c'est qu'il devrais me renvoyer sa réponse et qu'il ne le fait pas. Je ne sais pas pourquoi. Donc apparement, il faut vraiment des 'rn' et non pas seulement des 'n'.
Bon ba merci bien en tout cas, il ne me reste plus qu'a comprendre pourquoi ce mobile ne veut pas me répondre alors qu'il veut bien répondre au site de synchronisation :(
Fabien
On 22 juil, 08:57, Bruno Desthuilliers
<bdesth.quelquech...@free.quelquepart.fr> wrote:
Bonjour à tous, je fais un serveur de synchronisation SyncML pour
synchroniser des téléphones mobiles.
lorsque le mobile demande une synchronisation au serveur, le serveur
fait un accept() sur la socket qui correspond, lit la demande du
mobile et génère une réponse (jusque là, ça fonctionne impé cable)
Le problème c'est pour envoyer la réponse, là je fait la chose
suivante :
Je viens de tester avec ce que tu as écris, et ça fonctionne mieux, le
mobile ne me répond plus par un FIN et ACK, seulement le ACK (du coup
la connexion n'est pas fermée) le problème c'est qu'il devrais me
renvoyer sa réponse et qu'il ne le fait pas. Je ne sais pas pourquoi.
Donc apparement, il faut vraiment des 'rn' et non pas seulement des
'n'.
Bon ba merci bien en tout cas, il ne me reste plus qu'a comprendre
pourquoi ce mobile ne veut pas me répondre alors qu'il veut bien
répondre au site de synchronisation :(
Bonjour à tous, je fais un serveur de synchronisation SyncML pour synchroniser des téléphones mobiles.
lorsque le mobile demande une synchronisation au serveur, le serveur fait un accept() sur la socket qui correspond, lit la demande du mobile et génère une réponse (jusque là, ça fonctionne impé cable) Le problème c'est pour envoyer la réponse, là je fait la chose suivante :
Je viens de tester avec ce que tu as écris, et ça fonctionne mieux, le mobile ne me répond plus par un FIN et ACK, seulement le ACK (du coup la connexion n'est pas fermée) le problème c'est qu'il devrais me renvoyer sa réponse et qu'il ne le fait pas. Je ne sais pas pourquoi. Donc apparement, il faut vraiment des 'rn' et non pas seulement des 'n'.
Bon ba merci bien en tout cas, il ne me reste plus qu'a comprendre pourquoi ce mobile ne veut pas me répondre alors qu'il veut bien répondre au site de synchronisation :(
Fabien
Amaury Forgeot d'Arc
On 22 juil, 08:57, Bruno Desthuilliers wrote:
Bonjour à tous, je fais un serveur de synchronisation SyncML pour synchroniser des téléphones mobiles. lorsque le mobile demande une synchronisation au serveur, le serveur fait un accept() sur la socket qui correspond, lit la demande du mobile et génère une réponse (jusque là, ça fonctionne impécable) Le problème c'est pour envoyer la réponse, là je fait la chose suivante : length = len(response) head = [] head.append("HTTP/1.1 200 OKn") head.append("Server: myPythonServern") head.append("Cache-Control: no-store, no-cache, must-revalidate, post- check=0, pre-check=0n") head.append("Pragma: no-cachen") head.append("Content-Length: "+str(length)+"n") head.append("Content-Type: application/vnd.syncml+wbxmlnn") head = ''.join(head) client.send(head+response) Ca ne répond pas forcément à ta question, mais:
Je viens de tester avec ce que tu as écris, et ça fonctionne mieux, le mobile ne me répond plus par un FIN et ACK, seulement le ACK (du coup la connexion n'est pas fermée) le problème c'est qu'il devrais me renvoyer sa réponse et qu'il ne le fait pas. Je ne sais pas pourquoi. Donc apparement, il faut vraiment des 'rn' et non pas seulement des 'n'.
Apparemment, ftp et smtp fonctionnent aussi à coups de CRLF. Ce sont sans doute des Windowsiens qui ont inventé ces protocoles...
Bon ba merci bien en tout cas, il ne me reste plus qu'a comprendre pourquoi ce mobile ne veut pas me répondre alors qu'il veut bien répondre au site de synchronisation :(
Fabien
On 22 juil, 08:57, Bruno Desthuilliers
<bdesth.quelquech...@free.quelquepart.fr> wrote:
Bonjour à tous, je fais un serveur de synchronisation SyncML pour
synchroniser des téléphones mobiles.
lorsque le mobile demande une synchronisation au serveur, le serveur
fait un accept() sur la socket qui correspond, lit la demande du
mobile et génère une réponse (jusque là, ça fonctionne impécable)
Le problème c'est pour envoyer la réponse, là je fait la chose
suivante :
length = len(response)
head = []
head.append("HTTP/1.1 200 OKn")
head.append("Server: myPythonServern")
head.append("Cache-Control: no-store, no-cache, must-revalidate, post-
check=0, pre-check=0n")
head.append("Pragma: no-cachen")
head.append("Content-Length: "+str(length)+"n")
head.append("Content-Type: application/vnd.syncml+wbxmlnn")
head = ''.join(head)
client.send(head+response)
Ca ne répond pas forcément à ta question, mais:
Je viens de tester avec ce que tu as écris, et ça fonctionne mieux, le
mobile ne me répond plus par un FIN et ACK, seulement le ACK (du coup
la connexion n'est pas fermée) le problème c'est qu'il devrais me
renvoyer sa réponse et qu'il ne le fait pas. Je ne sais pas pourquoi.
Donc apparement, il faut vraiment des 'rn' et non pas seulement des
'n'.
Apparemment, ftp et smtp fonctionnent aussi à coups de CRLF.
Ce sont sans doute des Windowsiens qui ont inventé ces protocoles...
Bon ba merci bien en tout cas, il ne me reste plus qu'a comprendre
pourquoi ce mobile ne veut pas me répondre alors qu'il veut bien
répondre au site de synchronisation :(
Bonjour à tous, je fais un serveur de synchronisation SyncML pour synchroniser des téléphones mobiles. lorsque le mobile demande une synchronisation au serveur, le serveur fait un accept() sur la socket qui correspond, lit la demande du mobile et génère une réponse (jusque là, ça fonctionne impécable) Le problème c'est pour envoyer la réponse, là je fait la chose suivante : length = len(response) head = [] head.append("HTTP/1.1 200 OKn") head.append("Server: myPythonServern") head.append("Cache-Control: no-store, no-cache, must-revalidate, post- check=0, pre-check=0n") head.append("Pragma: no-cachen") head.append("Content-Length: "+str(length)+"n") head.append("Content-Type: application/vnd.syncml+wbxmlnn") head = ''.join(head) client.send(head+response) Ca ne répond pas forcément à ta question, mais:
Je viens de tester avec ce que tu as écris, et ça fonctionne mieux, le mobile ne me répond plus par un FIN et ACK, seulement le ACK (du coup la connexion n'est pas fermée) le problème c'est qu'il devrais me renvoyer sa réponse et qu'il ne le fait pas. Je ne sais pas pourquoi. Donc apparement, il faut vraiment des 'rn' et non pas seulement des 'n'.
Apparemment, ftp et smtp fonctionnent aussi à coups de CRLF. Ce sont sans doute des Windowsiens qui ont inventé ces protocoles...
Bon ba merci bien en tout cas, il ne me reste plus qu'a comprendre pourquoi ce mobile ne veut pas me répondre alors qu'il veut bien répondre au site de synchronisation :(
Fabien
Bruno Desthuilliers
Apès avoir jeté un oeil dans httplib.py, je suggère de remplacer les n par des rn
J'ai oublié de précisé, je suis sous linux. Je ne suis pas certain, mais je crois que c'est seulement sous windows qu'il faut utiliser rn sous linux, le n fait les deux (à confirmer).
Effectivement, Windows et Unix n'utilisent pas la même convention pour les fins de lignes. Mais c'est indépendant de ton problème, puisque le marquage de fin de ligne à utiliser ici est celui déterminé par le protocole HTTP.
Apès avoir jeté un oeil dans httplib.py, je suggère de remplacer les n
par des rn
J'ai oublié de précisé, je suis sous linux.
Je ne suis pas certain, mais je crois que c'est seulement sous windows
qu'il faut utiliser rn sous linux, le n fait les deux (à
confirmer).
Effectivement, Windows et Unix n'utilisent pas la même convention pour
les fins de lignes. Mais c'est indépendant de ton problème, puisque le
marquage de fin de ligne à utiliser ici est celui déterminé par le
protocole HTTP.
Apès avoir jeté un oeil dans httplib.py, je suggère de remplacer les n par des rn
J'ai oublié de précisé, je suis sous linux. Je ne suis pas certain, mais je crois que c'est seulement sous windows qu'il faut utiliser rn sous linux, le n fait les deux (à confirmer).
Effectivement, Windows et Unix n'utilisent pas la même convention pour les fins de lignes. Mais c'est indépendant de ton problème, puisque le marquage de fin de ligne à utiliser ici est celui déterminé par le protocole HTTP.
Bruno Desthuilliers
(snip)
Donc apparement, il faut vraiment des 'rn' et non pas seulement des 'n'.
Apparemment, ftp et smtp fonctionnent aussi à coups de CRLF. Ce sont sans doute des Windowsiens qui ont inventé ces protocoles...
Lol !-)
Mais PAQJS, non.
(snip)
Donc apparement, il faut vraiment des 'rn' et non pas seulement des
'n'.
Apparemment, ftp et smtp fonctionnent aussi à coups de CRLF.
Ce sont sans doute des Windowsiens qui ont inventé ces protocoles...
ok, et entre le head et la réponse, n'est il pas nécéssaire d'insér er des 'rn' ? Est ce que je dois envoyer en deux paquet différents : dabort le head et ensuite la réponse (avec deux send donc) ou est ce que je dois tout concaténer dans un même paquet ? (et dans ce cas, comment dois-je séparer les données du head ?)
ok, et entre le head et la réponse, n'est il pas nécéssaire d'insér er
des 'rn' ?
Est ce que je dois envoyer en deux paquet différents : dabort le head
et ensuite la réponse (avec deux send donc) ou est ce que je dois tout
concaténer dans un même paquet ? (et dans ce cas, comment dois-je
séparer les données du head ?)
ok, et entre le head et la réponse, n'est il pas nécéssaire d'insér er des 'rn' ? Est ce que je dois envoyer en deux paquet différents : dabort le head et ensuite la réponse (avec deux send donc) ou est ce que je dois tout concaténer dans un même paquet ? (et dans ce cas, comment dois-je séparer les données du head ?)
Apparemment, ftp et smtp fonctionnent aussi à coups de CRLF. Ce sont sans doute des Windowsiens qui ont inventé ces protocoles...
Pas du tout.
Mais quand il a fallut choisir une fin de ligne "réseau", ceux qui l'on fait se sont dit (avec raison) qu'en mettant les deux caractères, la fin de ligne serait reconnu par tout le monde (avec parfois un caractère parasite avant ou après mais c'est moins grave que de ne pas voir de fin de ligne du tout).
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Apparemment, ftp et smtp fonctionnent aussi à coups de CRLF.
Ce sont sans doute des Windowsiens qui ont inventé ces protocoles...
Pas du tout.
Mais quand il a fallut choisir une fin de ligne "réseau", ceux qui
l'on fait se sont dit (avec raison) qu'en mettant les deux caractères,
la fin de ligne serait reconnu par tout le monde (avec parfois un
caractère parasite avant ou après mais c'est moins grave que de ne pas
voir de fin de ligne du tout).
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Apparemment, ftp et smtp fonctionnent aussi à coups de CRLF. Ce sont sans doute des Windowsiens qui ont inventé ces protocoles...
Pas du tout.
Mais quand il a fallut choisir une fin de ligne "réseau", ceux qui l'on fait se sont dit (avec raison) qu'en mettant les deux caractères, la fin de ligne serait reconnu par tout le monde (avec parfois un caractère parasite avant ou après mais c'est moins grave que de ne pas voir de fin de ligne du tout).
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
