¿Alguien me puede decir cuál es más estable? Sé que cada uno tiene sus propias ventajas y desventajas. ¿Pero cuál es mejor para http, etc.?Indy o ICS o?
En mi aplicación anterior, utilicé indy9 pero no estaba satisfecho con él, ya que a veces recibía errores extraños.
¿Alguien puede recomendar uno?
Uso Indy en muchos proyectos. Usé tanto 9 como 10 principalmente como servidor HTTP y proxy. Los proyectos reciben tráfico muy intenso a veces (HTTP). Indy nunca me decepcionó. Funciona muy estable.
Pero también tuve algunas situaciones "extrañas" donde tuve que cavar profundo para encontrar el problema subyacente. Tampoco me gusta la forma en que Indy tiende a manejar muchas cosas a través de excepciones. En general, me gusta más el estilo de codificación ICS. Pero déjame ir a ICS.
ICS usa sockets no bloqueantes, mientras que indy usa el bloqueo. Aunque no bloquear está bien y parece ser mejor a primera vista, me pareció 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 biblioteca de procedimientos. Además, no me gusta cómo se maneja todo a través de los mensajes. Para mí, se vuelve muy rápido cuando se mezcla con multihilo. Y multihilo es la corriente principal en estos días.
Así que, 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 gusta depende de ti, pero ambas bibliotecas son maduras y estables.
Estos son mis dos centavos.
He usado Indy 9 y 10 para TCP, HTTP y FTP con muy pocos problemas. ICS es una buena opción, también. No es un bloqueo, lo que cambiará la forma en que lo usa.
No lo he usado, pero he oído cosas buenas sobre Synapse, que también es un bloqueo.
Cuál es mejor realmente depende del caso de uso específico, pero no estaba contento con indy como cliente http y ICS terminó siendo exactamente lo que necesitaba, con muchos menos caprichos aleatorios.
Tenga en cuenta que no es un bloqueo, por lo que no se trata solo de una sustitución.
Uso Indy 9 para código de producción estable, lanzado, a más de 1 millón de usuarios, y nunca he recibido ningún error extraño.
También uso tanto Indy como ICS.
La mayoría de las veces prefiero Indy porque la implementación de protocolos secuenciales con él es muy fácil (la solicitud se ejecuta en su propio hilo para que simplemente lea/escriba la conexión, realmente fácil). El uso de Indy requiere un conocimiento sólido de enhebrado y sincronización. A diferencia de Runner, me gusta cómo Indy usa Exceptions para manejar cosas "excepcionales" porque me permite concentrarme en el flujo normal del protocolo (utilizo los bloques try-finally para asegurarme de que desalojo los recursos).
También utilicé ICS en una aplicación donde Indy simplemente falló: la usé para una aplicación que implementa un proxy TCP/IP. El uso de ICS fue más simple debido a su naturaleza no bloqueante. Pude "proxy" protocolos TCP/IP de los que no sé nada, así que no tengo idea de cómo los bytes fluirían de un extremo a otro. Indy fracasó en ese escenario porque en Indy estás leyendo o estás escribiendo, no puedes hacer ambas cosas al mismo tiempo.El uso de ICS para implementar un protocolo de tipo secuencial es un poco doloroso: básicamente necesitas usar la lógica de máquina de estados, frenar el protocolo en pedacitos pequeños, mantener las banderas sobre ti para que sepas dónde estás en el protocolo. Una gran ventaja: François Piette, el autor de ICS, es activo y muy útil en una serie de 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!
Recuerda que Indy siempre está en fase beta. A veces necesitas trabajar con compilaciones nocturnas.
Diría que la respuesta depende de lo que quieras hacer con Internet. Indy está bien si está preparado para involucrarse con la comprensión de cómo funciona, y es muy capaz. ICS es una visión diferente de las cosas, y la he usado con eficacia para muchos sistemas de conexión. Pero para el día a día "agarrar un archivo o enviar un correo electrónico", donde quiera hacer una tarea básica, casi siempre uso Clever Components Internet Suite, ya que acaba de crear el componente, establece las opciones, y funciona. El conjunto es bastante completo y obtiene actualizaciones útiles.
Probamos Indy10 IdTCPClient para recibir la transmisión de video desde el servidor remoto, está bien. Pero cuando recibe la transmisión, al mismo tiempo, utilícela y envíe algunos datos al servidor; después de un minuto, los datos de transmisión recibidos comienzan a perder bytes de datos. Usamos la herramienta sniffer para rastrear este problema, confirmamos que IdTCPClient perdió algunos bytes en la transmisión de recepción.
Por lo tanto, probamos Indy9.018, el mismo problema ocurrió pero unas pocas veces VS. Indy 10.
Si bien también estoy a favor de Indy, creo que los exámenes de ICS son superiores. Especialmente Indy10 –
Totalmente de acuerdo. Indy10 es muy pobre en ejemplos. – Runner
@Runner Solo mira ASÍ QUE hay más preguntas relacionadas con el problema Indy que ICS. Tú eres el juez que es más estable. –