instalar indy 10 delphi
Indy o ICS o? (8)
Cuál es mejor depende realmente de un caso de uso específico, pero no estaba contento con indy como cliente http y ICS terminó siendo exactamente lo que necesitaba, con muchas menos peculiaridades aleatorias.
Tenga en cuenta que no está bloqueando, por lo que no es solo una caída en el reemplazo.
¿Alguien puede decirme cuál es más estable? Sé que cada uno tiene sus propias ventajas y desventajas. ¿Pero cuál es mejor para http, etc?
En mi aplicación anterior utilicé indy9 pero no estaba satisfecho con él, ya que a veces me salían errores extraños.
¿Alguien puede recomendar uno?
He usado Indy 9 y 10 para TCP, HTTP y FTP con muy pocos problemas. ICS también es una buena opción. Es no bloqueante, lo que cambiará cómo lo usas.
No lo he usado, pero he oído cosas buenas sobre Synapse , que también está bloqueando.
Probamos Indy10 IdTCPClient para recibir transmisión de video desde un servidor remoto, está bien. Pero cuando está recibiendo transmisión, al mismo tiempo que lo usa, envía algunos datos al servidor, después de un minuto, los datos recibidos comenzaron a perder bytes de datos. Usamos la herramienta sniffer para rastrear este problema, confirmamos que IdTCPClient perdió algunos bytes en la secuencia de recepción.
Entonces, probamos Indy9.018, el mismo problema sucedió pero algunas veces VS. Indy 10.
Recuerda que Indy siempre está en fase beta. A veces necesitas trabajar con construcciones nocturnas.
También uso tanto Indy como ICS.
La mayoría de las veces prefiero Indy porque implementar un tipo secuencial de protocolos con él es muy fácil (la solicitud se ejecuta en su propio subproceso, de modo que simplemente lea / escriba en la conexión, realmente fácil). El uso de Indy requiere un conocimiento sólido de subprocesos y sincronización. A diferencia de Runner, me gusta cómo Indy usa Excepciones para manejar cosas "excepcionales" porque me permite concentrarme en el flujo normal del protocolo (uso los bloques try-finally para asegurarme de desasignar recursos).
También usé ICS en una aplicación donde Indy simplemente falló: lo usé para una aplicación que implementa un proxy TCP / IP. Usar ICS fue más sencillo debido a su naturaleza no bloqueante. Pude "proxy" los protocolos TCP / IP de los que no sé nada, así que no tengo idea de cómo los bytes fluirían de un extremo al otro. Indy falló en ese escenario porque en Indy estás leyendo o escribiendo, no puedes hacer ambas cosas al mismo tiempo. Usar ICS para implementar un protocolo de tipo secuencial es un poco molesto: esencialmente necesita usar la lógica de la máquina de estados, frenar el protocolo en bits pequeños, mantener banderas alrededor para que sepa dónde se encuentra en el protocolo. Una gran ventaja: François Piette, el autor de ICS, es activo y muy útil en varios foros y listas de correo, y es muy rápido para ayudar con cualquier cosa relacionada con ICS.
Para mí, si necesito hacer algo con TCP / IP, la ruta de decisión es muy simple: ¿Se puede hacer con Indy? Entonces es Indy. ¡Si no se puede hacer con Indy, entonces se hará con ICS!
Utilizo Indy 9 para el código de producción, publicado y estable para más de 1 millón de usuarios, y nunca he recibido ningún error extraño.
Utilizo Indy en muchos proyectos. Utilicé tanto 9 como 10 principalmente como servidor HTTP y proxy. Los proyectos obtienen un tráfico muy intenso a veces (HTTP). Indy nunca me decepcionó. Funciona muy estable.
Pero también tuve algunas situaciones "extrañas" en las que tuve que profundizar para encontrar el problema subyacente. Tampoco me gusta la forma en que Indy tiende a manejar muchas cosas a través de las excepciones. En general me gusta más el estilo de codificación ICS. Pero déjame ir a ICS.
ICS utiliza conectores no bloqueantes, mientras que indy utiliza el bloqueo. Si bien el no bloqueo está bien y parece ser mejor a primera vista, lo encontré irritante en muchas situaciones. El problema es que el flujo natural del código se pierde debido a las funciones de devolución de llamada. Esto hace que sea más difícil escribir el tipo de procedimiento de las bibliotecas. Además no me gusta cómo todo se maneja a través de mensajes. Para mí se ensucia muy rápido cuando se mezcla con multiproceso. Y el multihilo es la corriente principal en estos días.
Entonces, aunque me gusta el estilo de codificación y la calidad del código en ICS, prefiero la simplicidad de uso y el modo de bloqueo de Indy. Lo que más te guste depende de ti, pero ambas bibliotecas son maduras y estables.
Estos son mis dos centavos.
Yo diría que la respuesta depende de lo que quieras hacer con internet. Indy está bien si estás preparado para involucrarte en la comprensión de cómo funciona, y es muy capaz. ICS es una versión diferente de las cosas, y lo he usado de manera efectiva para sistemas con muchas conexiones. Sin embargo, para el día a día "tome un archivo o envíe un correo electrónico", donde quiera realizar una tarea básica, casi siempre uso Clever Components Internet Suite, ya que solo crea el componente, configura las opciones y funciona. La suite es bastante completa, y obtiene actualizaciones útiles.