FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
||||
|
||||
Hola,
No sé si al final lograré algo mejor que lo que tengo ahora, empero, me parece más menos claro que el "cuello de botella" está a la hora de recibir el texto enviado. Dicho texto se "recorre byte a byte", puesto que el "protocolo" manda, y, es preciso buscar los dos últimos "bytes" del final, que, son los que nos sirven para determinar que el texto se terminó de enviar. Parece claro que el asunto sería mejor si en lugar de necesitar leer "byte a byte" pudiéramos leer directamente un "stream" mayor. Pero hete aquí que el problema sigue siendo que es menester conocer el tamaño de nuestro "stream", y, para esto sólo parece haber dos soluciones: enviar primero el tamaño de nuestro "stream" y a continuación enviar el "stream" mismo. Sin embargo lo dicho no parece sencillo (para mí) de llevar a cabo. Tal como está ahora, incluso cuando el código no es mío y hay bastantes cosas que se me escapan, por lo menos creo comprender lo que se trata de hacer. Es lento, sí, pero, funciona. Lo malo es que en mi proyecto (una DLL que se encaja en otro programa) no funciona tan bien como en una aplicación de Delphi. Aún cuando tenemos que recorrer byte a byte el texto que se envía, una aplicación Delphi puede hacerlo relativamente rápido incluso cuando hablamos de una cadena de texto de más de 100 MB... pero mi proyecto DLL no puede siquiera recibir 1 MB sin colgar a la aplicación en cuya DLL reside. De ahí la necesidad de probar con "streams", de enviar "algo" y sobre todo recibir "algo" que no tengamos que revisar "byte a byte". Y en esas estamos... no sé si alguien ha leído todos estos mensajes y si me explico lo suficiente. En todo caso si logro algún avance lo comentaré por aquí. Y si alguien puede y quiere echarme una mano será bienvenida. |
#2
|
||||
|
||||
Hola,
Parece claro que esto:
... no tiene mucho sentido. Funciona, porque, las pruebas las estoy haciendo "en local", y, en realidad TODO el texto se envía a la vez, porque, en realidad es lo que estamos haciendo ahí... es decir, la primera llamada tendría sentido, pero, una segunda llamada no lo tendría. El error no se ve (si no es a simple vista, pero, a mí se me escapa) si no se sabe que, en verdad, dicha instrucción se ejecuta una sola vez y no, como se espera, varias veces. Las sucesivas llamadas no tendrían sentido, pues estaríamos enviando de nuevo TODO el texto... peor aún, todo el texto "menos idx"... Es decir, que el código de Remy:
... tiene otro sentido. No compila, seguramente, porque está escrito sin probarlo, pero, el sentido está claro: enviar a cada llamada únicamente el texto restante, o sea, el que no se haya enviado ya. Así que, tratando de remediar dicho asunto, he escrito algo como esto:
Y, aunque ahora sí se supone que estamos haciendo las cosas mejor, lo cierto es que tampoco me termina de convencer, puesto que en realidad estamos forzando el envío de 1024 bytes cada vez, sin contar acaso conque a veces podría enviarse más... y a veces también menos... En definitiva no soy capaz de dar con la tecla. No digamos ya implementar el asunto utilizando "streams", a cuyo inicio añadamos el tamaño del mismo. Lo sigo intentando, pero, no hay manera. |
#3
|
||||
|
||||
Hola,
Seguimos avanzando... De nuevo utilizando código de Remy (hablo de él como si le conociese de algo... je je je) creo, repito, creo haber conseguido que el envío se realice correctamente, esto es, teniendo en cuenta posibles errores y el hecho crucial: que no siempre se enviará TODO el texto de golpe, sino que dependerá de las necesidades del "socket" en cuestión. Todo (el envío) funciona como se espera, excepto por el hecho de que realmente no puedo comprobar qué ocurriría de veras si el "socket" no admitiese todo el texto de golpe, porque, aunque todavía no me lo explico, al menos en las pruebas que hago (con servidor y cliente en la misma máquina) TODO el contenido se consigue enviar al mismo tiempo, de manera que el código añadido no llega realmente a comprobarse... aunque todo parezca indicar que funcionará. Adjunto la actualización del programa de ejemplo, aunque, lo cierto es que seguimos con el mismo "cuello de botella" al recibir el texto. Y mientras siga leyendo lo que se recibe "byte a byte" voy a seguir con el mismo problema, me temo. En fin... seguiremos intentándolo a ver. |
#4
|
|||
|
|||
Buenas noches Dec,
De antemano gracias por el recurso compartido de transferencia de archivos. Me tome el atrevimiento de tomar el código que adjuntaste para revisar su comportamiento porque necesito realizar algo similar. Sin embargo, a pesar de que realizo los pasos tal cual como los indicas en un mensaje anterior para el envío de archivos, no logro que se cree el archivo b.txt (ni en el computador local como en otro de la misma red). Sé que esta discusión es algo avanzada (llevo poco programando Delphi) pero me gustaría poder realizar esa transferencia de archivos. No he modificado el código que adjuntaste. Con respecto al problema, el código indicado en la parte inferior perteneciente al método ServerClientRead. Este código nunca es ejecutado porque la cadena s llega vacía, pero no encuentro el motivo.
Entiendo que este post es un poco viejo pero agradezco si me puedes orientar en algun paso adicional que sea necesario realizar para que la transferencia del archivo sea satisfactoria. |
#5
|
||||
|
||||
Hola,
Probando el archivo adjunto de mi último mensaje el ejemplo no parece funcionar bien, al menos aquí en Windows 10. Sin embargo, probando el programa en que estoy usando "Sockets" y que originó este hilo sí que puedo enviar y recibir cadenas de un cliente a un servidor y viceversa. Lo cierto es que ahora mismo on sabría bien qué responderte. Quizá el código de abajo, usado en mi programa, te dé una idea y te sirva de algo:
Ese es el código que uso en mi programa para enviar cadenas en ambos cliente y servidor. Dicho código parece el resumen de este hilo, en el sentido de que es el que al final estoy usando en mi programa, y, como digo, este funciona como se espera incluso aquí en Windows 10. |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
El programa se queda "colgado" mientras copia y luego "despierta" | NeWsP | OOP | 5 | 10-03-2010 22:05:40 |
"OBJECT OR CLASS TYPE REQUIRED" en "APPLICATION EXENAME" | Xavierator | Varios | 3 | 27-10-2008 09:09:50 |
Necesito llamar a métodos de clases "hija" desde su clase "padre" | Flecha | OOP | 17 | 20-04-2007 00:03:53 |
Firebir y usar "IF" en la clausula "SELECT" | papulo | SQL | 6 | 25-07-2006 21:38:04 |
|