Après avoir tester les webservices de windev et m'être rendu compte que
cela ne collé pas vraiment à mes besoins, j'ai testé l'utilisation des
sockets qui me donne pleine satisfaction.
Juste 2 petites questions :
- Est-ce possible d'avoir une information de type "chargement" ? Par
exemple si un buffer d'une certaine taille est un train d'arrivé,
peut-on évaluer le temps qu'il reste avant la fin de réception ?
- Des précautions particulières ? Est-ce possible de perdre des données
lors de transfert d'information ?
Ou petits pièges / astuces que vous avez découvert avec le temps.
TCP_NODELAY garantie t'il aussi la réception physique. (les packets tcp ne sont ils pas empilés chez le destinataire en attente du traitement par la couche applicative ?)
Non, cette option indique seuelement à l'émetteur qu'il faut envoyer les paquets sans passer par l'algo de Nagle (qui sert en gros à optimiser la taille des paquets : les données de petites tailles sont concaténées).
Par contre, TCP (pas UDP) est un protocole orienté connexion, ce qui implique que le récepteur envoie des accusés de réception automatiquement et remet en ordre les éventuels paquets arrivés dans le désordre. http://www.commentcamarche.net/internet/tcp.php3
A+
-- Romain PETIT http://cerbermail.com/?O16kfXOFcq (cliquez sur le lien ci-dessus pour me contacter en privé)
patrice a pensé très fort :
TCP_NODELAY garantie t'il aussi la réception physique.
(les packets tcp ne sont ils pas empilés chez le destinataire en attente du
traitement par la couche applicative ?)
Non, cette option indique seuelement à l'émetteur qu'il faut envoyer
les paquets sans passer par l'algo de Nagle (qui sert en gros à
optimiser la taille des paquets : les données de petites tailles sont
concaténées).
Par contre, TCP (pas UDP) est un protocole orienté connexion, ce qui
implique que le récepteur envoie des accusés de réception
automatiquement et remet en ordre les éventuels paquets arrivés dans le
désordre.
http://www.commentcamarche.net/internet/tcp.php3
A+
--
Romain PETIT
http://cerbermail.com/?O16kfXOFcq
(cliquez sur le lien ci-dessus pour me contacter en privé)
TCP_NODELAY garantie t'il aussi la réception physique. (les packets tcp ne sont ils pas empilés chez le destinataire en attente du traitement par la couche applicative ?)
Non, cette option indique seuelement à l'émetteur qu'il faut envoyer les paquets sans passer par l'algo de Nagle (qui sert en gros à optimiser la taille des paquets : les données de petites tailles sont concaténées).
Par contre, TCP (pas UDP) est un protocole orienté connexion, ce qui implique que le récepteur envoie des accusés de réception automatiquement et remet en ordre les éventuels paquets arrivés dans le désordre. http://www.commentcamarche.net/internet/tcp.php3
A+
-- Romain PETIT http://cerbermail.com/?O16kfXOFcq (cliquez sur le lien ci-dessus pour me contacter en privé)
Romain PETIT
En fait, il y a 2 façons de procéder : - soit l'émetteur envoie la totalité de son message à partir d'une seule socket, TCP fait tout le boulot (mise en paquets, ordre à l'arrivée, cheksum etc) et le récepteur est assuré de recevoir la totalité du message (ou rien). - soit l'émetteur fractionne le message logique et attend du récepteur un acquittement pour chaque message logique envoyé (ce qu'on fait en général avec des liaisons séries en répondant avec des ACK/NACK).
A mon avis, en TCP/IP, il faut travailler avec la 1ère solution (elle est faite pour ça), mais le problème, c'est qu'on n'est pas à l'abri d'interprétations de la part des programmes avec lesquels on doit dialoguer...
A+
-- Romain PETIT http://cerbermail.com/?O16kfXOFcq (cliquez sur le lien ci-dessus pour me contacter en privé)
En fait, il y a 2 façons de procéder :
- soit l'émetteur envoie la totalité de son message à partir d'une
seule socket, TCP fait tout le boulot (mise en paquets, ordre à
l'arrivée, cheksum etc) et le récepteur est assuré de recevoir la
totalité du message (ou rien).
- soit l'émetteur fractionne le message logique et attend du récepteur
un acquittement pour chaque message logique envoyé (ce qu'on fait en
général avec des liaisons séries en répondant avec des ACK/NACK).
A mon avis, en TCP/IP, il faut travailler avec la 1ère solution (elle
est faite pour ça), mais le problème, c'est qu'on n'est pas à l'abri
d'interprétations de la part des programmes avec lesquels on doit
dialoguer...
A+
--
Romain PETIT
http://cerbermail.com/?O16kfXOFcq
(cliquez sur le lien ci-dessus pour me contacter en privé)
En fait, il y a 2 façons de procéder : - soit l'émetteur envoie la totalité de son message à partir d'une seule socket, TCP fait tout le boulot (mise en paquets, ordre à l'arrivée, cheksum etc) et le récepteur est assuré de recevoir la totalité du message (ou rien). - soit l'émetteur fractionne le message logique et attend du récepteur un acquittement pour chaque message logique envoyé (ce qu'on fait en général avec des liaisons séries en répondant avec des ACK/NACK).
A mon avis, en TCP/IP, il faut travailler avec la 1ère solution (elle est faite pour ça), mais le problème, c'est qu'on n'est pas à l'abri d'interprétations de la part des programmes avec lesquels on doit dialoguer...
A+
-- Romain PETIT http://cerbermail.com/?O16kfXOFcq (cliquez sur le lien ci-dessus pour me contacter en privé)
patrice
"Romain PETIT" a écrit dans le message de news:
En fait, il y a 2 façons de procéder : - soit l'émetteur envoie la totalité de son message à partir d'une seule socket, TCP fait tout le boulot (mise en paquets, ordre à l'arrivée, cheksum etc) et le récepteur est assuré de recevoir la totalité du message (ou rien). - soit l'émetteur fractionne le message logique et attend du récepteur un acquittement pour chaque message logique envoyé (ce qu'on fait en général avec des liaisons séries en répondant avec des ACK/NACK).
A mon avis, en TCP/IP, il faut travailler avec la 1ère solution (elle est faite pour ça), mais le problème, c'est qu'on n'est pas à l'abri d'interprétations de la part des programmes avec lesquels on doit dialoguer...
A+
vi vi il faut laisser le nagle optimiser la connexion, envoyer les paquets et controler que le serveur est bien fait le traitement avec une demande d'ack sur la globalité du traitement
"Romain PETIT" <VoirM@Signature.fin> a écrit dans le message de
news:mn.8a517d86703ee6a3.2248@Signature.fin...
En fait, il y a 2 façons de procéder :
- soit l'émetteur envoie la totalité de son message à partir d'une
seule socket, TCP fait tout le boulot (mise en paquets, ordre à
l'arrivée, cheksum etc) et le récepteur est assuré de recevoir la
totalité du message (ou rien).
- soit l'émetteur fractionne le message logique et attend du récepteur
un acquittement pour chaque message logique envoyé (ce qu'on fait en
général avec des liaisons séries en répondant avec des ACK/NACK).
A mon avis, en TCP/IP, il faut travailler avec la 1ère solution (elle
est faite pour ça), mais le problème, c'est qu'on n'est pas à l'abri
d'interprétations de la part des programmes avec lesquels on doit
dialoguer...
A+
vi vi
il faut laisser le nagle optimiser la connexion, envoyer les paquets
et controler que le serveur est bien fait le traitement avec une demande
d'ack sur la globalité du traitement
En fait, il y a 2 façons de procéder : - soit l'émetteur envoie la totalité de son message à partir d'une seule socket, TCP fait tout le boulot (mise en paquets, ordre à l'arrivée, cheksum etc) et le récepteur est assuré de recevoir la totalité du message (ou rien). - soit l'émetteur fractionne le message logique et attend du récepteur un acquittement pour chaque message logique envoyé (ce qu'on fait en général avec des liaisons séries en répondant avec des ACK/NACK).
A mon avis, en TCP/IP, il faut travailler avec la 1ère solution (elle est faite pour ça), mais le problème, c'est qu'on n'est pas à l'abri d'interprétations de la part des programmes avec lesquels on doit dialoguer...
A+
vi vi il faut laisser le nagle optimiser la connexion, envoyer les paquets et controler que le serveur est bien fait le traitement avec une demande d'ack sur la globalité du traitement
JB
Le Tue, 17 Jun 2008 09:44:36 +0200, Romain PETIT a écrit:
patrice a pensé très fort :
TCP_NODELAY garantie t'il aussi la réception physique. (les packets tcp ne sont ils pas empilés chez le destinataire en attente du traitement par la couche applicative ?)
Non, cette option indique seuelement à l'émetteur qu'il faut envoyer les paquets sans passer par l'algo de Nagle (qui sert en gros à optimiser la taille des paquets : les données de petites tailles sont concaténées).
Par contre, TCP (pas UDP) est un protocole orienté connexion, ce qui implique que le récepteur envoie des accusés de réception automatiquement et remet en ordre les éventuels paquets arrivés dans le désordre. http://www.commentcamarche.net/internet/tcp.php3
A+
Oui
-- JB
Le Tue, 17 Jun 2008 09:44:36 +0200, Romain PETIT <VoirM@Signature.fin> a
écrit:
patrice a pensé très fort :
TCP_NODELAY garantie t'il aussi la réception physique.
(les packets tcp ne sont ils pas empilés chez le destinataire en
attente du traitement par la couche applicative ?)
Non, cette option indique seuelement à l'émetteur qu'il faut envoyer les
paquets sans passer par l'algo de Nagle (qui sert en gros à optimiser la
taille des paquets : les données de petites tailles sont concaténées).
Par contre, TCP (pas UDP) est un protocole orienté connexion, ce qui
implique que le récepteur envoie des accusés de réception
automatiquement et remet en ordre les éventuels paquets arrivés dans le
désordre.
http://www.commentcamarche.net/internet/tcp.php3
Le Tue, 17 Jun 2008 09:44:36 +0200, Romain PETIT a écrit:
patrice a pensé très fort :
TCP_NODELAY garantie t'il aussi la réception physique. (les packets tcp ne sont ils pas empilés chez le destinataire en attente du traitement par la couche applicative ?)
Non, cette option indique seuelement à l'émetteur qu'il faut envoyer les paquets sans passer par l'algo de Nagle (qui sert en gros à optimiser la taille des paquets : les données de petites tailles sont concaténées).
Par contre, TCP (pas UDP) est un protocole orienté connexion, ce qui implique que le récepteur envoie des accusés de réception automatiquement et remet en ordre les éventuels paquets arrivés dans le désordre. http://www.commentcamarche.net/internet/tcp.php3
