bon je ne suis pas trop callé en socket, mais j'aimerai savoir quel est
l'impact de la taille du buffer dans le fonction recv
int dl_block = 512;
while (size != 0)
{
err = recv(sock, page, dl_block, 0);
page += dl_block;
}
J'explique un peu plus mon problème.
Je développe un truc qui va utiliser une connexion EDGE.
je réalise le téléchargement des données via un thread, ce qui me permet
avec un peu d'effort de commencer à analyser les données reçues dès
avant d'avoir la totalité du fichier.
Donc j'aurai envie de réduire au maximum dl_block afin de pouvoir
commencer plus tôt le travail.
Ce que j'aimerai savoir c'est s'il y a moyen de trouver la bonne valeur
pour dl_block ?
Et si en terme de réseau il y a des échanges qui se font à chaque fois
que j'appelle la fonction recv (hors transfert des données) et qui donc
pourrait militer en faveur de block plus gros pour un nombre d'appels
moins grand !!!
Merci.
Etienne
bon je ne suis pas trop callé en socket, mais j'aimerai savoir quel est
l'impact de la taille du buffer dans le fonction recv
int dl_block = 512;
while (size != 0)
{
err = recv(sock, page, dl_block, 0);
page += dl_block;
}
J'explique un peu plus mon problème.
Je développe un truc qui va utiliser une connexion EDGE.
je réalise le téléchargement des données via un thread, ce qui me permet
avec un peu d'effort de commencer à analyser les données reçues dès
avant d'avoir la totalité du fichier.
Donc j'aurai envie de réduire au maximum dl_block afin de pouvoir
commencer plus tôt le travail.
Ce que j'aimerai savoir c'est s'il y a moyen de trouver la bonne valeur
pour dl_block ?
Et si en terme de réseau il y a des échanges qui se font à chaque fois
que j'appelle la fonction recv (hors transfert des données) et qui donc
pourrait militer en faveur de block plus gros pour un nombre d'appels
moins grand !!!
Merci.
Etienne
bon je ne suis pas trop callé en socket, mais j'aimerai savoir quel est
l'impact de la taille du buffer dans le fonction recv
int dl_block = 512;
while (size != 0)
{
err = recv(sock, page, dl_block, 0);
page += dl_block;
}
J'explique un peu plus mon problème.
Je développe un truc qui va utiliser une connexion EDGE.
je réalise le téléchargement des données via un thread, ce qui me permet
avec un peu d'effort de commencer à analyser les données reçues dès
avant d'avoir la totalité du fichier.
Donc j'aurai envie de réduire au maximum dl_block afin de pouvoir
commencer plus tôt le travail.
Ce que j'aimerai savoir c'est s'il y a moyen de trouver la bonne valeur
pour dl_block ?
Et si en terme de réseau il y a des échanges qui se font à chaque fois
que j'appelle la fonction recv (hors transfert des données) et qui donc
pourrait militer en faveur de block plus gros pour un nombre d'appels
moins grand !!!
Merci.
Etienne
Ton code est faux, et pas qu'un peu.
Independamment de ce que tu veux faire, ca serait plus du:
int dl_block = 512;
do
{
sz = recv(sock, page, dl_block, 0);
if (sz == -1) {
throw something;
}
page += sz;
} while (err != 0);
e.g., c'est bloquant si tu socket est bloquante, mais il suffit qu'il y ait
des choses arrivees pour que ca te donne quelque chose.
C'est tres suffisant en general. On peut parametrer les choses differemment,
surtout en rendant la socket non bloquante, ou en jouant avec select/poll,
mais aussi en jouant avec setsockopt, tout particulierement, SO_RCVLOWAT,
SO_RCVTIMEO, SO_RCVBUF (ca, ca peut etre sympa si on attend de gros bursts
de donnees et qu'on risque de prendre du temps a les traiter).
Ton code est faux, et pas qu'un peu.
Independamment de ce que tu veux faire, ca serait plus du:
int dl_block = 512;
do
{
sz = recv(sock, page, dl_block, 0);
if (sz == -1) {
throw something;
}
page += sz;
} while (err != 0);
e.g., c'est bloquant si tu socket est bloquante, mais il suffit qu'il y ait
des choses arrivees pour que ca te donne quelque chose.
C'est tres suffisant en general. On peut parametrer les choses differemment,
surtout en rendant la socket non bloquante, ou en jouant avec select/poll,
mais aussi en jouant avec setsockopt, tout particulierement, SO_RCVLOWAT,
SO_RCVTIMEO, SO_RCVBUF (ca, ca peut etre sympa si on attend de gros bursts
de donnees et qu'on risque de prendre du temps a les traiter).
Ton code est faux, et pas qu'un peu.
Independamment de ce que tu veux faire, ca serait plus du:
int dl_block = 512;
do
{
sz = recv(sock, page, dl_block, 0);
if (sz == -1) {
throw something;
}
page += sz;
} while (err != 0);
e.g., c'est bloquant si tu socket est bloquante, mais il suffit qu'il y ait
des choses arrivees pour que ca te donne quelque chose.
C'est tres suffisant en general. On peut parametrer les choses differemment,
surtout en rendant la socket non bloquante, ou en jouant avec select/poll,
mais aussi en jouant avec setsockopt, tout particulierement, SO_RCVLOWAT,
SO_RCVTIMEO, SO_RCVBUF (ca, ca peut etre sympa si on attend de gros bursts
de donnees et qu'on risque de prendre du temps a les traiter).
bon je ne suis pas trop call en socket, mais j'aimerai savoir quel est
l'impact de la taille du buffer dans le fonction recv
[snip] code corrigé elsethread
Ce que j'aimerai savoir c'est s'il y a moyen de trouver la bonne valeur
pour dl_block ?
Et si en terme de r seau il y a des changes qui se font chaque fois
que j'appelle la fonction recv (hors transfert des donn es) et qui donc
pourrait militer en faveur de block plus gros pour un nombre d'appels
moins grand !!!
bon je ne suis pas trop call en socket, mais j'aimerai savoir quel est
l'impact de la taille du buffer dans le fonction recv
[snip] code corrigé elsethread
Ce que j'aimerai savoir c'est s'il y a moyen de trouver la bonne valeur
pour dl_block ?
Et si en terme de r seau il y a des changes qui se font chaque fois
que j'appelle la fonction recv (hors transfert des donn es) et qui donc
pourrait militer en faveur de block plus gros pour un nombre d'appels
moins grand !!!
bon je ne suis pas trop call en socket, mais j'aimerai savoir quel est
l'impact de la taille du buffer dans le fonction recv
[snip] code corrigé elsethread
Ce que j'aimerai savoir c'est s'il y a moyen de trouver la bonne valeur
pour dl_block ?
Et si en terme de r seau il y a des changes qui se font chaque fois
que j'appelle la fonction recv (hors transfert des donn es) et qui donc
pourrait militer en faveur de block plus gros pour un nombre d'appels
moins grand !!!
On 27 déc, 18:50, WebShaker wrote:
Ca dépends de la couche application, si tu reconstitue le buffer par
la suite à ça importe peu; et si tu reçoit par trame il suffit que tu
aies la taille du message maximal.
Un read de 1 octet à chaque fois n'est pas forcément choquant mais pas
très efficace.
Et si en terme de r seau il y a des changes qui se font chaque fois
que j'appelle la fonction recv (hors transfert des donn es) et qui donc
pourrait militer en faveur de block plus gros pour un nombre d'appels
moins grand !!!
Non, recv n'est qu'une interface avec l'OS et est plus ou moins
déconnecté du protocole sous jacent (à moins que tu ne travailles en
zero-copy). Par contre, tu sollicites un appel système donc c'est
couteux.
On 27 déc, 18:50, WebShaker<etie...@tlk.fr> wrote:
Ca dépends de la couche application, si tu reconstitue le buffer par
la suite à ça importe peu; et si tu reçoit par trame il suffit que tu
aies la taille du message maximal.
Un read de 1 octet à chaque fois n'est pas forcément choquant mais pas
très efficace.
Et si en terme de r seau il y a des changes qui se font chaque fois
que j'appelle la fonction recv (hors transfert des donn es) et qui donc
pourrait militer en faveur de block plus gros pour un nombre d'appels
moins grand !!!
Non, recv n'est qu'une interface avec l'OS et est plus ou moins
déconnecté du protocole sous jacent (à moins que tu ne travailles en
zero-copy). Par contre, tu sollicites un appel système donc c'est
couteux.
On 27 déc, 18:50, WebShaker wrote:
Ca dépends de la couche application, si tu reconstitue le buffer par
la suite à ça importe peu; et si tu reçoit par trame il suffit que tu
aies la taille du message maximal.
Un read de 1 octet à chaque fois n'est pas forcément choquant mais pas
très efficace.
Et si en terme de r seau il y a des changes qui se font chaque fois
que j'appelle la fonction recv (hors transfert des donn es) et qui donc
pourrait militer en faveur de block plus gros pour un nombre d'appels
moins grand !!!
Non, recv n'est qu'une interface avec l'OS et est plus ou moins
déconnecté du protocole sous jacent (à moins que tu ne travailles en
zero-copy). Par contre, tu sollicites un appel système donc c'est
couteux.
Surtout que j'ai un peu regardé select et pool, et j'ai rien compris,
j'ai plutôt le sensation que les gens l'utilisent avec les applis serveur.
Moi c'est un client tout bête.
Surtout que j'ai un peu regardé select et pool, et j'ai rien compris,
j'ai plutôt le sensation que les gens l'utilisent avec les applis serveur.
Moi c'est un client tout bête.
Surtout que j'ai un peu regardé select et pool, et j'ai rien compris,
j'ai plutôt le sensation que les gens l'utilisent avec les applis serveur.
Moi c'est un client tout bête.
In article <4d19f2fb$0$5881$,
WebShaker wrote:
>Surtout que j'ai un peu regardé select et pool, et j'ai rien compris,
>j'ai plutôt le sensation que les gens l'utilisent avec les applis serv eur.
Non, ils s'en servent des qu'ils doivent multiplexer des entrees-sorties
sur plusieurs flux.
In article <4d19f2fb$0$5881$426a7...@news.free.fr>,
WebShaker <etie...@tlk.fr> wrote:
>Surtout que j'ai un peu regardé select et pool, et j'ai rien compris,
>j'ai plutôt le sensation que les gens l'utilisent avec les applis serv eur.
Non, ils s'en servent des qu'ils doivent multiplexer des entrees-sorties
sur plusieurs flux.
In article <4d19f2fb$0$5881$,
WebShaker wrote:
>Surtout que j'ai un peu regardé select et pool, et j'ai rien compris,
>j'ai plutôt le sensation que les gens l'utilisent avec les applis serv eur.
Non, ils s'en servent des qu'ils doivent multiplexer des entrees-sorties
sur plusieurs flux.
On 28 déc, 16:13, (Marc Espie) wrote:In article <4d19f2fb$0$5881$,
WebShaker wrote:
>Surtout que j'ai un peu regardé select et pool, et j'ai rien compris,
>j'ai plutôt le sensation que les gens l'utilisent avec les applis serveur.
Non, ils s'en servent des qu'ils doivent multiplexer des entrees-sorties
sur plusieurs flux.
Ou alors si ils ont besoin d'un timeout sur la réception de donnée, ce
qui est généralement une bonne idée.
On 28 déc, 16:13, es...@lain.home (Marc Espie) wrote:
In article <4d19f2fb$0$5881$426a7...@news.free.fr>,
WebShaker <etie...@tlk.fr> wrote:
>Surtout que j'ai un peu regardé select et pool, et j'ai rien compris,
>j'ai plutôt le sensation que les gens l'utilisent avec les applis serveur.
Non, ils s'en servent des qu'ils doivent multiplexer des entrees-sorties
sur plusieurs flux.
Ou alors si ils ont besoin d'un timeout sur la réception de donnée, ce
qui est généralement une bonne idée.
On 28 déc, 16:13, (Marc Espie) wrote:In article <4d19f2fb$0$5881$,
WebShaker wrote:
>Surtout que j'ai un peu regardé select et pool, et j'ai rien compris,
>j'ai plutôt le sensation que les gens l'utilisent avec les applis serveur.
Non, ils s'en servent des qu'ils doivent multiplexer des entrees-sorties
sur plusieurs flux.
Ou alors si ils ont besoin d'un timeout sur la réception de donnée, ce
qui est généralement une bonne idée.
In article .com>,
Michael Doubez wrote:
>On 28 d c, 16:13, (Marc Espie) wrote:
>> In article <4d19f2fb$0$5881$,
>> WebShaker wrote:
>> >Surtout que j'ai un peu regard select et pool, et j'ai rien compris,
>> >j'ai plut t le sensation que les gens l'utilisent avec les applis ser veur.
>> Non, ils s'en servent des qu'ils doivent multiplexer des entrees-sorti es
>> sur plusieurs flux.
>Ou alors si ils ont besoin d'un timeout sur la r ception de donn e, ce
>qui est g n ralement une bonne id e.
Ca depend. Ca impose quand meme d'avoir beaucoup plus de code, et de
savoir ce que tu fais lorsque tu te prends un timeout...
La gestion d'erreurs, c'est toujours complique, rarement suffisamment
teste, et c'est toujours la que tu vas trouver les bugs qui vont te pourr ir
ton logiciel. Particulierement cote securite. En plus, on parle d'un soft
reseau, la... (enfin bon, le posteur original avait regarde en diagonale
le fonctionnement de recv, je ne donne pas cher de son code cote robustes se).
On pourrait penser que les exceptions vont simplifier la chose, sauf que
la litterature sur le sujet (Sutter) montre assez nettement que... ca
reste toujours tres complique. Peut-etre un tantinet moins penible a
organiser, mais toujours difficile a faire marcher convenablement.
Il semble bien que l'esprit humain a du mal a valider plusieurs chemins d ans
le meme code simultanement.
In article <4697ed1a-5b2b-40a0-be3a-9803b08c8...@l24g2000vby.googlegroups .com>,
Michael Doubez <michael.dou...@free.fr> wrote:
>On 28 d c, 16:13, es...@lain.home (Marc Espie) wrote:
>> In article <4d19f2fb$0$5881$426a7...@news.free.fr>,
>> WebShaker <etie...@tlk.fr> wrote:
>> >Surtout que j'ai un peu regard select et pool, et j'ai rien compris,
>> >j'ai plut t le sensation que les gens l'utilisent avec les applis ser veur.
>> Non, ils s'en servent des qu'ils doivent multiplexer des entrees-sorti es
>> sur plusieurs flux.
>Ou alors si ils ont besoin d'un timeout sur la r ception de donn e, ce
>qui est g n ralement une bonne id e.
Ca depend. Ca impose quand meme d'avoir beaucoup plus de code, et de
savoir ce que tu fais lorsque tu te prends un timeout...
La gestion d'erreurs, c'est toujours complique, rarement suffisamment
teste, et c'est toujours la que tu vas trouver les bugs qui vont te pourr ir
ton logiciel. Particulierement cote securite. En plus, on parle d'un soft
reseau, la... (enfin bon, le posteur original avait regarde en diagonale
le fonctionnement de recv, je ne donne pas cher de son code cote robustes se).
On pourrait penser que les exceptions vont simplifier la chose, sauf que
la litterature sur le sujet (Sutter) montre assez nettement que... ca
reste toujours tres complique. Peut-etre un tantinet moins penible a
organiser, mais toujours difficile a faire marcher convenablement.
Il semble bien que l'esprit humain a du mal a valider plusieurs chemins d ans
le meme code simultanement.
In article .com>,
Michael Doubez wrote:
>On 28 d c, 16:13, (Marc Espie) wrote:
>> In article <4d19f2fb$0$5881$,
>> WebShaker wrote:
>> >Surtout que j'ai un peu regard select et pool, et j'ai rien compris,
>> >j'ai plut t le sensation que les gens l'utilisent avec les applis ser veur.
>> Non, ils s'en servent des qu'ils doivent multiplexer des entrees-sorti es
>> sur plusieurs flux.
>Ou alors si ils ont besoin d'un timeout sur la r ception de donn e, ce
>qui est g n ralement une bonne id e.
Ca depend. Ca impose quand meme d'avoir beaucoup plus de code, et de
savoir ce que tu fais lorsque tu te prends un timeout...
La gestion d'erreurs, c'est toujours complique, rarement suffisamment
teste, et c'est toujours la que tu vas trouver les bugs qui vont te pourr ir
ton logiciel. Particulierement cote securite. En plus, on parle d'un soft
reseau, la... (enfin bon, le posteur original avait regarde en diagonale
le fonctionnement de recv, je ne donne pas cher de son code cote robustes se).
On pourrait penser que les exceptions vont simplifier la chose, sauf que
la litterature sur le sujet (Sutter) montre assez nettement que... ca
reste toujours tres complique. Peut-etre un tantinet moins penible a
organiser, mais toujours difficile a faire marcher convenablement.
Il semble bien que l'esprit humain a du mal a valider plusieurs chemins d ans
le meme code simultanement.