protocolos - Wiki: estado del arte actual de las bibliotecas de componentes TCP/IP de terceros de Delphi

tcp/ip caracteristicas

Question

No he estado haciendo TCP / IP desnudo durante unos 18 meses, así que me pregunto cuál es el estado del arte actual.

Estoy buscando aspectos positivos y negativos, con el desarrollo del software del servidor y del cliente.
Realizaré un proyecto que necesita una capa sólida de TCP / IP, por lo que para mí ese es un aspecto importante :)

Para que esto se convierta en una wiki de la comunidad, estoy buscando respuestas más amplias que solo ''roca sólida''. Entonces, por ejemplo, también se agradece la información sobre el ancho de las características.

Actualizaré la pregunta con los aspectos relevantes encontrados en las respuestas para obtener una entrada wiki que tenga una visión general equilibrada de esas bibliotecas.

Por ejemplo, vea mi respuesta a continuación con mi experiencia pasada con Indy. Soy ambivalente en el manejo de excepciones y el anticongelante en Indy, aunque me acostumbré a él, todavía me parecía antinatural.

En este momento desarrollo en Delphi 2007 (no Unicode) y XE (Unicode), por lo que las bibliotecas que estoy considerando deberían admitir al menos esas dos versiones de Delphi.

Answer 1

ICS: la suite de componentes de Internet

ICS - ver www.overbyte.be . Fuente abierta por François Piette. Para mí, esta ha sido siempre la alternativa número 1 a Indy. Es el punto de venta más interesante: hace que usar cosas asíncronas sea fácil, y ser asincrónico parece estar más cerca de la programación de sockets "bare metal".

Lo he usado para construir un proxy VNC bastante complejo donde el propio proxy (servidor) está construido con ICS y los clientes son una mezcla de Indy e ICS. En períodos de gran demanda, el proxy maneja aproximadamente 100 conexiones simultáneas y aproximadamente 10 sesiones simultáneas de pantallas VNC. Come un promedio de 5 mbit / s, maneja conexiones a través de dos conexiones de Internet distintas. No creo que el 100 + 10 sea el límite, porque el servidor maneja eso sin ningún problema y el uso de la CPU es demasiado bajo como para mencionarlo.

Pros:

• Funciona de forma asíncrona
• Algo más fácil para los principiantes porque no necesita hilos
• Admite una buena cantidad de protocolos

Contras:

• Se basa en los mensajes de Windows. Simplemente no estoy cómodo con eso.
• El comportamiento asincrónico hace que la implementación de la mayoría de los protocolos sea un poco difícil (porque la mayoría de los protocolos son en forma de comando de envío / respuesta de recepción ). Esto no debería importar para la mayoría de las personas, ya que ICS ofrece una implementación ya hecha para los protocolos más utilizados.

Dicho todo esto, no he usado ICS en mucho tiempo, no estoy actualizado con todos los detalles. Esto es CW, así que por favor edita y expande!

Answer 2

La respuesta realmente depende de muchos factores y sus requisitos, como

1. qué capas son necesarias (TCP, SSL / TLS, protocolos de nivel de aplicación)
2. si necesita un cliente o servidor también (el servidor es una tarea mucho más complicada)
3. si cuentas las opciones pagas

En general, no sucedió mucho (positivo) en 18 meses o incluso en 3 años, ya que la mayoría de los desarrolladores ven a .NET como plataforma de desarrollo primario.

Clever Internet Suite mencionó en otra respuesta y DevArt''s SecureBridge obtuvo algunas funcionalidades nuevas.

Nuestro SecureBlackbox ofrece soporte para las características más avanzadas (además del SSL / TLS nativo): IPv6, HTTPS Proxy con autenticación básica, digestiva y NTLM (comenzando con SecureBlackbox 9), nombres de dominio internacionales (comenzando con SecureBlackbox 9), DNSSEC, control de ancho de banda y Más.

Los protocolos de nivel de aplicación compatibles con SecureBlackbox son HTTP (cliente y servidor), WebDAV (cliente y servidor), FTP (cliente y servidor), SSH y SFTP (cliente y servidor), clientes SMTP y POP3, cliente DNS, AS2 y AS3. Todos los protocolos (además de SSH y SFTP, por supuesto) tienen soporte completo para SSL / TLS.

La lista de protocolos compatibles se puede encontrar en la página Packages . Las funciones de protocolo compatibles se enumeran en la página de Especificaciones técnicas para cada paquete.

Answer 3

Podría considerar usar un nivel de protocolo más alto como HTTP, porque:

• Es más compatible con firewall y VPN;
• Está bien documentado y es conocido como un buen protocolo;
• Ya tiene la versión segura de HTTPS;
• Tiene una sobrecarga muy baja sobre la fila TCP / IP;
• Está listo para usar en un entorno AJAX (si lo necesita en el futuro);
• Microsoft ya hizo el ajuste de bajo nivel para usted en la versión moderna de Windows.

En este caso, puedes echar un vistazo a dos clases de código abierto que funcionan desde Delphi 6 hasta XE:

THttpApiServer que implementa un servidor HTTP usando el rápido servidor http.sys kernel-mode:

• La API del servidor HTTP permite que las aplicaciones se comuniquen a través de HTTP sin utilizar Microsoft Internet Information Server (IIS). Las aplicaciones pueden registrarse para recibir solicitudes HTTP para URL particulares, recibir solicitudes HTTP y enviar respuestas HTTP. La API del servidor HTTP incluye soporte SSL para que las aplicaciones puedan intercambiar datos a través de conexiones HTTP seguras sin IIS. También está diseñado para trabajar con puertos de terminación de E / S.
• La API del servidor HTTP es compatible con los sistemas operativos Windows Server 2003 y Windows XP con el Service Pack 2 (SP2). Tenga en cuenta que Microsoft IIS 5 que se ejecuta en Windows XP con SP2 no puede compartir el puerto 80 con otras aplicaciones HTTP que se ejecutan simultáneamente.

TWinHTTP que maneja la solicitud HTTP / 1.1 del lado del cliente utilizando la API de WinHTTP:

• Los Servicios HTTP de Microsoft Windows (WinHTTP) están destinados a aplicaciones de servidores de nivel medio y de servicios de fondo que requieren acceso a una pila de clientes HTTP;
• Es mucho más rápido que la API WinINet anterior.

La velocidad resultante es muy buena (especialmente el servidor), y dependerá de la implementación de Microsoft. El primero es el núcleo de IIS, y el segundo se utiliza en las últimas versiones de Internet Explorer.

Answer 4

Recomiendo encarecidamente Clever Internet Suite , es de lejos el conjunto mejor diseñado y escrito de componentes de comunicación. No es gratis y tampoco tan conocido, pero vale la pena investigarlo.

Pro:

• bien diseñado y escrito
• contiene muchos components e implementa varios protocolos.
• admite un amplio conjunto de versiones de Delphi (incluidos 2007 y XE)
• Soporte de SSL
• producto maduro como el historial de lanzamiento indica

Estafa:

• no fuente abierta

Answer 5

Trabajé con los componentes de NetMaster en forma (¡camino!) En las versiones antiguas de Delphi (¡2! 3! 4!)

Algunos trabajaron con Indy, pero también tenían la sensación antinatural (de hecho, lo describiría más como voluminoso)

Tropecé con Synapse cuando estaba buscando solo una capa ligera alrededor de la API de red de Windows,

Y luego redescubrió el antiguo TTcpClient / TTcpServer. ¡Son envoltorios propios de Delphi alrededor de winsock! Los uso bloqueando, con un TThread inheritant dedicado para cada TTcpClient, y dejo que TTcpServer haga los hilos y haga todo el trabajo en DoAccept, mire here para ver un ejemplo.

Esto, ahora, me dio la sensación sólida que estamos buscando. Si desea admitir una gran carga, intentaría crear un administrador de subprocesos que maneje varios sockets / conexiones por subproceso, o que tenga dos conjuntos de subprocesos: unos que escuchan un mayor número de conexiones "latentes" y los otros que manejan conexiones ''activas'' menores, cambiando las conexiones entre los hilos dependiendo de si se está manejando una solicitud o respuesta. (por ejemplo, Connection: keep-alive de HTTP Connection: keep-alive )

Answer 6

Utilizo Indy desde 2003 para mi propio marco de comunicaciones TCP. Es sólido como una roca, tengo una versión utilizada con Delphi 2007 y otra con Delphi 2010, si manejas el hilo correctamente no hay necesidad de usar el material anticongelante, y tengo un manejo de excepción consistente en el cliente y el servidor implementando mi propio envoltorio alrededor de esto.

Puede descargarlo aquí ( http://www.csinnovations.com/framework_delphi.htm ) - busque las unidades Tcp , principalmente AppTcpServerUnt y AppTcpClientUnt.

Answer 7

Editar: Resumen de mi experiencia pasada con Indy, y los comentarios (gracias Eugene , Marjan ) (actualice con el estado actual de Indy):

Pro:

• se envía con Delphi
• maduro
• comunidad de desarrollo
• de código abierto, por lo que muchos ojos escudriñan esas fuentes
• un camión cargado de valiosa documentación de comentarios en el código fuente
• Soporte OpenSSL
• admite un amplio conjunto de versiones de Delphi (incluidos 2007 y XE)
• amplia elección de protocolos

Estafa:

• la versión de envío con Delphi no siempre fue la más estable; descargar de las fuentes generalmente se requiere para obtener una construcción estable
• (mientras tanto) mucha duplicación de código que ahora está en Delphi (pero Indy requiere compatibilidad con versiones anteriores de Delphi)
• no todos los componentes TCP / IP estaban actualizados (por ejemplo, en aquel entonces, el componente cliente POP3 no era compatible con algunos comandos POP3 básicos)
• la interoperabilidad de la versión era un problema: la actualización de una versión de Indy a otra podría llevar mucho tiempo
• Soy ambivalente en el manejo de las excepciones y el anticongelante en Indy, aunque me acostumbré a él, todavía me parecía antinatural.
• se realizan cambios bruscos entre las actualizaciones de compilación; ifdefs requerido para acomodar esos
• Estado de liberación poco claro, si hay alguno, sin RC por un tiempo prolongado, la obtención del enlace puede hacer que su copia local sea inestable