Winsock y los ficheros binarios

tener en cuenta:
*) si enviás 1 solo byte
y otros 10 bytes detrás inmediatamente
TCP envía un solo paquete de 11 bytes
*) si envias un archivo de 1 MB
TCP "parte el archivo en pedazos"
el socket remoto va a recibir
una cantidad no determinada de paquetes
y que van a llegar en distinto orden


tendrías que etiquetar cada paquete
y ordenarlos una vez que hayas juntado
todas las partes...
esto sucede porque TCP
no se hizo para enviar archivos
sino "mensajes"
(aunque es posible hacerlo)

espero te sirva

atte,
Hernán Castelo
UTN - Buenos Aires
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . .

"Jose Luis Muñoz" escribió en el mensaje
news:03ca01c35fd5$150aadc0$
Quiero enviar y recibir ficheros binarios (ejecutables y
otros) mediante Winsock, pero los ficheros recibidos
tienen bloques de bytes incorrectos. En la ayuda de
Winsock en el método Senddata se recomienda: "Para los
datos binarios, debería usar matrices de datos". ¿ Alguien
sabe cómo hacer esto o cómo evitar este problema ? Gracias
anticipiadas .

después de aprender a usar los sockets
tuve que aprender bastante de TCP
no soy el gran experto

No seras el gran experto pero lo que has dicho es muy cierto. Los paquetes
enviados sobre TCP/IP recorren diferentes rutas de la trama llegando este a
dar la vuelta al mundo como dices; yo tuve un problema similar con los
binarios, pero como solo era una prueba lo deje de ese tamaño, ya que la
transmision de texto plano funcionaba de maravilla. Lo que me llamo la
atencion de tu mensaje es lo siguiente:

>esto sucede porque TCP
>no se hizo para enviar archivos
>sino "mensajes"
>(aunque es posible hacerlo)

AFAIK TCP/IP es la capa de transporte sobre la cual viajan otros protocolos
como HTTP, FTP, NNTP, etc. ¿podrias explicar un poco mas eso? Ah y si tienes
la fuente de intenet para leerlo pues mucho mejor. (eso en el caso de que el
documento este publicado).
Saludos.
T.S.U. Harold Godefroy. Caracas - Venezuela
Coordinador Portalfox Venezuela
http://venezuela.portalfox.com
h a r o l d g o d e f r o y @ p o r t a l f o x . c o m

"Sí, soy un criminal, mi crimen es la curiosidad.
Mi crimen es juzgar a la gente por lo que dice y
piensa, no por lo que parece. Mi crimen es que
soy más listo que tu, algo que no me puedes perdonar."
The Mentor



"Hernán Castelo" escribió en el mensaje
news:

por un lado:
cuántos bytes de mensaje intentas enviar?

y por otro
no te fíes de que los paquetes
llegan siempre en el orden correcto
cada paquete puede recorrer el mundo
por miles de rutas distintas

TCP tiene un tamaño máximo
no tiene uno mínimo
lo que yo te decía es que si enviás
un paquete con 1 solo byte
y detrás de inmediato otro paquete con 4 bytes
lo más seguro es que te envíe
un solo paquete de 5 bytes
( porque TCP, por default, no te envía
el mensaje M+2 si no ha recibido
respuesta del mensaje M)

los bytes chr(0) y 32
pueden aparecer por eso
tratá de enviar el archivo en partes
(hay código para partir archivo en portalFox)
y enviarlo cada parte con un delay
considerable (1 seg),
solo para comprobar qué es lo que sucede

yo utilizo sockets
en varias aplicaciones
después de aprender a usar los sockets
tuve que aprender bastante de TCP
no soy el gran experto
pero bueno, es mi colaboración
espero te ayude

atte,
Hernán Castelo
UTN - Buenos Aires
. . . . . . . . . . . . . . . . . . . . . . . . .

.

. . . .

"José Luis Muñoz" escribió en el mensaje
news:02af01c3609d$72bac2c0$
He comprobado que los paquetes se reciben en el orden
correcto, el problema es que se corrompen bloques de bytes
y aparecen cadenas de chr(0) o chr(32). Creo que está
relacionado con ciertos valores de bytes. No con el tamaño.
Gracias

>tener en cuenta:
>*) si enviás 1 solo byte
>y otros 10 bytes detrás inmediatamente
>TCP envía un solo paquete de 11 bytes
>*) si envias un archivo de 1 MB
>TCP "parte el archivo en pedazos"
>el socket remoto va a recibir
>una cantidad no determinada de paquetes
>y que van a llegar en distinto orden
>
>
>tendrías que etiquetar cada paquete
>y ordenarlos una vez que hayas juntado
>todas las partes...
>esto sucede porque TCP
>no se hizo para enviar archivos
>sino "mensajes"
>(aunque es posible hacerlo)
>
>espero te sirva
>
>atte,
>Hernán Castelo
>UTN - Buenos Aires
>.. . . . . . . . . . . . . . . . . . .
. . . . . . .
>.. . . .
>
>"Jose Luis Muñoz" escribió en el mensaje
>news:03ca01c35fd5$150aadc0$
>Quiero enviar y recibir ficheros binarios (ejecutables y
>otros) mediante Winsock, pero los ficheros recibidos
>tienen bloques de bytes incorrectos. En la ayuda de
>Winsock en el método Senddata se recomienda: "Para los
>datos binarios, debería usar matrices de datos". ¿ Alguien
>sabe cómo hacer esto o cómo evitar este problema ? Gracias
>anticipiadas .
>
>
>
>.
>

por un lado:
cuántos bytes de mensaje intentas enviar?

y por otro
no te fíes de que los paquetes
llegan siempre en el orden correcto
cada paquete puede recorrer el mundo
por miles de rutas distintas

TCP tiene un tamaño máximo
no tiene uno mínimo
lo que yo te decía es que si enviás
un paquete con 1 solo byte
y detrás de inmediato otro paquete con 4 bytes
lo más seguro es que te envíe
un solo paquete de 5 bytes
( porque TCP, por default, no te envía
el mensaje M+2 si no ha recibido
respuesta del mensaje M)

los bytes chr(0) y 32
pueden aparecer por eso
tratá de enviar el archivo en partes
(hay código para partir archivo en portalFox)
y enviarlo cada parte con un delay
considerable (1 seg),
solo para comprobar qué es lo que sucede

yo utilizo sockets
en varias aplicaciones
después de aprender a usar los sockets
tuve que aprender bastante de TCP
no soy el gran experto
pero bueno, es mi colaboración
espero te ayude

atte,
Hernán Castelo
UTN - Buenos Aires
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . .

"José Luis Muñoz" escribió en el mensaje
news:02af01c3609d$72bac2c0$
He comprobado que los paquetes se reciben en el orden
correcto, el problema es que se corrompen bloques de bytes
y aparecen cadenas de chr(0) o chr(32). Creo que está
relacionado con ciertos valores de bytes. No con el tamaño.
Gracias

tener en cuenta:
*) si enviás 1 solo byte
y otros 10 bytes detrás inmediatamente
TCP envía un solo paquete de 11 bytes
*) si envias un archivo de 1 MB
TCP "parte el archivo en pedazos"
el socket remoto va a recibir
una cantidad no determinada de paquetes
y que van a llegar en distinto orden


tendrías que etiquetar cada paquete
y ordenarlos una vez que hayas juntado
todas las partes...
esto sucede porque TCP
no se hizo para enviar archivos
sino "mensajes"
(aunque es posible hacerlo)

espero te sirva

atte,
Hernán Castelo
UTN - Buenos Aires
.. . . . . . . . . . . . . . . . . . .

. . . . . . .

.. . . .

"Jose Luis Muñoz" escribió en el mensaje
news:03ca01c35fd5$150aadc0$
Quiero enviar y recibir ficheros binarios (ejecutables y
otros) mediante Winsock, pero los ficheros recibidos
tienen bloques de bytes incorrectos. En la ayuda de
Winsock en el método Senddata se recomienda: "Para los
datos binarios, debería usar matrices de datos". ¿ Alguien
sabe cómo hacer esto o cómo evitar este problema ? Gracias
anticipiadas .



.

bueno solo me refería
a que para transmitir archivos existe FTP
y que implementando uno mismo sockets sobre TCP
para enviar archivos hay que hacer
control de secuencia por nuestros medios
por lo tanto etiquetar c/paquete, etc
FTP lo hace más fácil (sendfile, getfile o algo así no recuerdo)
pero es algo inseguro, por lo que leí
(en mi curso de redes
en la facultad nos decían
directamente deshabilitar los puertos FTP ...)

lo que recuerdo es que buscando
"Nagle socket" en un buscador
obtenía bastante información y muy interesante
donde encontré algunas respuestas
a los inconvenientes que iban surgiendo

atte,
Hernán Castelo
UTN - Buenos Aires
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . .

"Harold Godefroy" escribió en el mensaje
news:e$

> después de aprender a usar los sockets
> tuve que aprender bastante de TCP
> no soy el gran experto

No seras el gran experto pero lo que has dicho es muy cierto. Los paquetes
enviados sobre TCP/IP recorren diferentes rutas de la trama llegando este

a

dar la vuelta al mundo como dices; yo tuve un problema similar con los
binarios, pero como solo era una prueba lo deje de ese tamaño, ya que la
transmision de texto plano funcionaba de maravilla. Lo que me llamo la
atencion de tu mensaje es lo siguiente:

> >esto sucede porque TCP
> >no se hizo para enviar archivos
> >sino "mensajes"
> >(aunque es posible hacerlo)

AFAIK TCP/IP es la capa de transporte sobre la cual viajan otros

protocolos

como HTTP, FTP, NNTP, etc. ¿podrias explicar un poco mas eso? Ah y si

tienes

la fuente de intenet para leerlo pues mucho mejor. (eso en el caso de que

el

documento este publicado).
> Saludos.
T.S.U. Harold Godefroy. Caracas - Venezuela
Coordinador Portalfox Venezuela
http://venezuela.portalfox.com
h a r o l d g o d e f r o y @ p o r t a l f o x . c o m

"Sí, soy un criminal, mi crimen es la curiosidad.
Mi crimen es juzgar a la gente por lo que dice y
piensa, no por lo que parece. Mi crimen es que
soy más listo que tu, algo que no me puedes perdonar."
The Mentor



"Hernán Castelo" escribió en el mensaje
news:
> por un lado:
> cuántos bytes de mensaje intentas enviar?
>
> y por otro
> no te fíes de que los paquetes
> llegan siempre en el orden correcto
> cada paquete puede recorrer el mundo
> por miles de rutas distintas
>
> TCP tiene un tamaño máximo
> no tiene uno mínimo
> lo que yo te decía es que si enviás
> un paquete con 1 solo byte
> y detrás de inmediato otro paquete con 4 bytes
> lo más seguro es que te envíe
> un solo paquete de 5 bytes
> ( porque TCP, por default, no te envía
> el mensaje M+2 si no ha recibido
> respuesta del mensaje M)
>
> los bytes chr(0) y 32
> pueden aparecer por eso
> tratá de enviar el archivo en partes
> (hay código para partir archivo en portalFox)
> y enviarlo cada parte con un delay
> considerable (1 seg),
> solo para comprobar qué es lo que sucede
>
> yo utilizo sockets
> en varias aplicaciones
> después de aprender a usar los sockets
> tuve que aprender bastante de TCP
> no soy el gran experto
> pero bueno, es mi colaboración
> espero te ayude
>
> atte,
> Hernán Castelo
> UTN - Buenos Aires
> . . . . . . . . . . . . . . . . . . . . . . . .

.

.
> . . . .
>
> "José Luis Muñoz" escribió en el mensaje
> news:02af01c3609d$72bac2c0$
> He comprobado que los paquetes se reciben en el orden
> correcto, el problema es que se corrompen bloques de bytes
> y aparecen cadenas de chr(0) o chr(32). Creo que está
> relacionado con ciertos valores de bytes. No con el tamaño.
> Gracias
>
> >tener en cuenta:
> >*) si enviás 1 solo byte
> >y otros 10 bytes detrás inmediatamente
> >TCP envía un solo paquete de 11 bytes
> >*) si envias un archivo de 1 MB
> >TCP "parte el archivo en pedazos"
> >el socket remoto va a recibir
> >una cantidad no determinada de paquetes
> >y que van a llegar en distinto orden
> >
> >
> >tendrías que etiquetar cada paquete
> >y ordenarlos una vez que hayas juntado
> >todas las partes...
> >esto sucede porque TCP
> >no se hizo para enviar archivos
> >sino "mensajes"
> >(aunque es posible hacerlo)
> >
> >espero te sirva
> >
> >atte,
> >Hernán Castelo
> >UTN - Buenos Aires
> >.. . . . . . . . . . . . . . . . . . .
> . . . . . . .
> >.. . . .
> >
> >"Jose Luis Muñoz" escribió en el mensaje
> >news:03ca01c35fd5$150aadc0$
> >Quiero enviar y recibir ficheros binarios (ejecutables y
> >otros) mediante Winsock, pero los ficheros recibidos
> >tienen bloques de bytes incorrectos. En la ayuda de
> >Winsock en el método Senddata se recomienda: "Para los
> >datos binarios, debería usar matrices de datos". ¿ Alguien
> >sabe cómo hacer esto o cómo evitar este problema ? Gracias
> >anticipiadas .
> >
> >
> >
> >.
> >
>
>