FTP con Winsock
Hola.
Estoy desarrollando una aplicación de FTP con Winsock Control y en Visual Basic 6, probándola en Windows 2000 Server con IIS 5).
Tengo dos funciones para los callback de los eventos DataArrival de dos sockets, el socket de control (que está abierto durante toda la sesión) y el socket de datos (que se abre al iniciar una transferencia de datos y se cierra por parte del servidor FTP cuando ya se ha hecho la transferencia). De esta forma cada vez que, por ejemplo, descargo un fichero, se ha de abrir un socket de datos (ya sea activo, yo indico la IP y puerto; o pasivo, el servidor me indica la IP y puerto).
Problema: Te describo el proceso:
1. El servidor comienza a enviar un fichero tras enviarme por el socket de control un mensaje de código 125 (inicio de transferencia).
2. Se reciben los datos y se van guardando en cada llamada a la función callback del evento DataArrival del socket de datos recién abierto.
3. Se recibe un mensaje 226 (transferencia acabada) del servidor, que nada más dejar de enviar datos por el socket de datos, lo manda por el socket de control.
4. El problema es que al ir la conexión tan rápida, cuando el servidor ha enviado todos los datos y después el mensaje de control, el cliente recibe el mensaje de control antes de terminar de recibir datos, pero el problema no es ese, sino que una vez que el servidor envía el mensaje de control indicando que ha terminado de transferir datos, cierra el socket de datos (CREO QUE ESO ES LO QUE PASA). Y el error que da es al llamar a socketDatos.GetData dentro de la función del evento DataArrival.
¿Me podrías dar algún consejo? Ya he probado de todo y sigue sin ir, justo en el último paquete de datos da ese error, y pasa cuando el fichero tiene más de 7 u 8 megas y la conexión es rápida. Además, me he dado cuenta de que a veces el mensaje 226 se recibe cuando aún quedan por recibir 10 o 12 paquetes de datos, de los que se llegan a recibir 7 u 8 antes de que de el error.
Muchas gracias.
Estoy desarrollando una aplicación de FTP con Winsock Control y en Visual Basic 6, probándola en Windows 2000 Server con IIS 5).
Tengo dos funciones para los callback de los eventos DataArrival de dos sockets, el socket de control (que está abierto durante toda la sesión) y el socket de datos (que se abre al iniciar una transferencia de datos y se cierra por parte del servidor FTP cuando ya se ha hecho la transferencia). De esta forma cada vez que, por ejemplo, descargo un fichero, se ha de abrir un socket de datos (ya sea activo, yo indico la IP y puerto; o pasivo, el servidor me indica la IP y puerto).
Problema: Te describo el proceso:
1. El servidor comienza a enviar un fichero tras enviarme por el socket de control un mensaje de código 125 (inicio de transferencia).
2. Se reciben los datos y se van guardando en cada llamada a la función callback del evento DataArrival del socket de datos recién abierto.
3. Se recibe un mensaje 226 (transferencia acabada) del servidor, que nada más dejar de enviar datos por el socket de datos, lo manda por el socket de control.
4. El problema es que al ir la conexión tan rápida, cuando el servidor ha enviado todos los datos y después el mensaje de control, el cliente recibe el mensaje de control antes de terminar de recibir datos, pero el problema no es ese, sino que una vez que el servidor envía el mensaje de control indicando que ha terminado de transferir datos, cierra el socket de datos (CREO QUE ESO ES LO QUE PASA). Y el error que da es al llamar a socketDatos.GetData dentro de la función del evento DataArrival.
¿Me podrías dar algún consejo? Ya he probado de todo y sigue sin ir, justo en el último paquete de datos da ese error, y pasa cuando el fichero tiene más de 7 u 8 megas y la conexión es rápida. Además, me he dado cuenta de que a veces el mensaje 226 se recibe cuando aún quedan por recibir 10 o 12 paquetes de datos, de los que se llegan a recibir 7 u 8 antes de que de el error.
Muchas gracias.
1 Respuesta
Respuesta de abarquin
1
Casualmente el ejemplo que tengo es una pequeña modificación, intentando corregir los errores del cliente FTP que viene como ejemplo en www.vbip.com.
El error que te comento sucede en conexiones rápidas. Resulta que cuando ya ha llegado el comando de fin de transferencia por el socket de control, aún se reciben varios paquetes de datos correctamente, fallando en el último, que no se puede leer (da el error: "Error 40006 en Tiempo de Ejecución: Error en el método 'GetData' del objeto IMSWinsockControl") al intentar leerlo en el callback de DataArrival.
Tras este fallo parece que el servidor no recibe una notificación TCP de la llegada del último paquete y vuelve a enviar 3 o 4 veces la información, pero el socket sigue fallando al ejecutar su método GetData.
¿Alguna sugerencia?
Gracias.
El error que te comento sucede en conexiones rápidas. Resulta que cuando ya ha llegado el comando de fin de transferencia por el socket de control, aún se reciben varios paquetes de datos correctamente, fallando en el último, que no se puede leer (da el error: "Error 40006 en Tiempo de Ejecución: Error en el método 'GetData' del objeto IMSWinsockControl") al intentar leerlo en el callback de DataArrival.
Tras este fallo parece que el servidor no recibe una notificación TCP de la llegada del último paquete y vuelve a enviar 3 o 4 veces la información, pero el socket sigue fallando al ejecutar su método GetData.
¿Alguna sugerencia?
Gracias.
Joder tío, ahora me has pillado en offside. Me voy a tener que poner las pilas! Z;D
Veamos, los comandos TCP tienen un nivel de prioridad. Los comandos de control son más rápidos porque tienen preferencia en las transmisiones, lo cual es normal. El control de flujo debe estar por encima de los datos, sino se producirían overflows cada dos por tres. Que la conexión sea rápida no implica nada. Te daría más problema en conexiones lentas porque el paquete de control entraría antes todavía...
En el tema que tratas, deberías definir al principio un contador con el tamaño del archivo, mandarlo al otro extremo y en el otro extremo acumular paquetes hasta ese tamaño.
Si no te vale con esto voy a tener que empollarme el código contigo: [email protected]
Veamos, los comandos TCP tienen un nivel de prioridad. Los comandos de control son más rápidos porque tienen preferencia en las transmisiones, lo cual es normal. El control de flujo debe estar por encima de los datos, sino se producirían overflows cada dos por tres. Que la conexión sea rápida no implica nada. Te daría más problema en conexiones lentas porque el paquete de control entraría antes todavía...
En el tema que tratas, deberías definir al principio un contador con el tamaño del archivo, mandarlo al otro extremo y en el otro extremo acumular paquetes hasta ese tamaño.
Si no te vale con esto voy a tener que empollarme el código contigo: [email protected]
