NetCom7
1.0.0
Las comunicaciones más rápidas posibles.
Esta es la versión 7.2 del paquete Netcom. ¡En esta versión, el paquete NetCom ahora es multiplataforma! ¡Puede compilar sus aplicaciones en todas las plataformas en Firemonkey!
Este conjunto de componentes es la implementación más rápida posible de las comunicaciones de socket, en cualquier idioma; Este es un código extremadamente optimizado en los sockets TCP/IP. Olvídese de usar un hilo por conexión: con esta suite puede tener tantas conexiones concurrentes con su servidor como desee. Los subprocesos se utilizan por solicitud y no por conexión, y se mantienen en una clase de piscina de subproces muy rápida.
La implementación comienza con TNCTCPServer y TNCTCPClient que implementa las comunicaciones básicas de socket. Puede usar TNCTCPClient y TNCTCPServer si todo lo que desea es implementar comunicaciones de socket estándar (pero muy rápidas).
Además de los sockets TCP/IP, se implementa un protocolo liviano para poder empacar y desempacar los buffers (TCP/IP simple se transmite y no tiene la noción de un búfer bien definido). El conjunto de componentes que implementan esta funcionalidad es TNCSerververSource y TNCClientSource. Ambos componentes implementan un ExecCommand (ACMD, ADATA) que desencadena un evento OnHandLecommand en el otro lado (un cliente puede execommand a un servidor, o un servidor puede execommand a cualquier cliente). ExecCommand puede estar bloqueando o no bloquear (async) dependiendo de cómo establezca su parámetro AreQuesResult. Si usa el comportamiento de bloqueo, el componente aún maneja las solicitudes entrantes de sus pares. Por ejemplo, una fuente de clientes podría estar esperando un execCommand del servidor, ¡pero mientras espera puede servir a las solicitudes de ExecCommand desde el servidor!
Senario simple: servidor:
- You put a TncServerSource on your form.
If you want you can change the port it is listening to via the
Port property.
- You implement an OnHandleCommand event handler and,
depending on aCmd parameter (integer), you respond the result of
the command via setting the Result of the OnHandleCommand to
anything you like (TBytes). If an exception is raised while in
HandleCommand, it is trapped, packed, transfered accross to the
calling peer, and raised at the peer's issued ExecCommand.
This way exceptions can be handled as if they were raised locally.
- You set the Active property to true. Your server is ready.
Cliente:
- You put a TncClientSource on your form.
You can set Host and Port to whatever you want.
- You set Active property to true.
Your client is now connected to the server.
- You call ExecCommand (on your TncClientSource), with any
command number and data that you like. This will send your
command and data over to the server, call its OnHandleCommand,
pack the response, and return it as a result to your ExecCommand.
- ExecCommand is blocking (if aRequiresResult parameter is set to true),
but only for the current command issued.
The TncClientSource's OnHandleCommand still executes, so,
while waiting for a command to return, your client socket may be
processing requests from your server (a server can also
ExecCommand to a client).
- If you have forgotten to set Active to true and call ExecCommand,
the TncClientSource will first try to connect, so you can ommit
setting this property. It will also try to connect if it knows
it has been disconnected (and the Reconnect property is set to true).
Este conjunto de componentes promete una velocidad inigualable y eso no es solo en palabras:
Una prueba de sincronización simple con la demostración de NetComvSindy ofrece los siguientes resultados:
Comenzando con la unidad base, NCSockets.pas, verá que la implementación no sufre de código flojo, es bastante inmediato. La convención de llamadas en línea se ha utilizado donde sea que se considere apropiado. Las mismas funciones centrales se han probado y optimizado al monitorear el rendimiento mediante el tiempo de bucles grandes e inspección de ensamblaje para exprimir hasta el último rendimiento.
La mayor diferencia en ganancia de velocidad se debe a la arquitectura. A diferencia de la mayoría de los enchufes típicos:
Este conjunto de enchufes no genera ni usa un hilo por conexión.
¡Esto significa que puede tener tantas conexiones en vivo como desee y no verá ninguna diferencia en el rendimiento! Una piscina de hilo solo espera cualquier solicitud; Si se creara un hilo por solicitud o por conexión, la velocidad sufriría mucho, ya que crear un hilo es bastante pesado en cuanto al tiempo. Si el número de subprocesos no puede manejar el número de solicitudes por segundo, el grupo de subprocesos crece hasta un tamaño máximo definido, y si aún no puede hacer frente, el cliente solo espera hasta que el servidor obtenga un hilo listo para procesar su solicitud.
También se ha prestado especial atención a los problemas de conexión. Por ejemplo, las desconexiones se recogen inmediatamente, y si una línea es tan mala que la desconexión no se puede recoger, lo aborda por un paquete de mantenimiento vivo por el cual conoce el estado real. Hay una propiedad de reconexión y una propiedad Keepalive. Cuando un cliente se desconecta, por cualquier razón, trata de reconectarse de manera transparente y sin afectar el rendimiento de la aplicación principal. De esta manera, no tiene que preocuparse por mantener a sus clientes conectados.
La compresión y el cifrado también son estándar con estos componentes sin que se requieren bibliotecas adicionales. Por supuesto, puede usar su propia compresión o cifrado si lo prefiere, pero es bastante útil tener solo una propiedad que puede configurar en el componente.
Este conjunto de componentes también puede tratar con los datos de basura que se les arrojan, se han utilizado y probado en enormes proyectos en todo el país donde se pueden ver todo tipo de ataques.
El esfuerzo que un programador tiene que hacer para usar estos componentes es mínimo en comparación con otros marcos. Consulte las demostraciones para obtener una mejor comprensión sobre cómo usar estos componentes.
Escrito por Bill Anastasios Demos. Un agradecimiento especial a Daniel Mauric, Tommi Prami, Roland Bengtsson por las extensas pruebas y sugerencias. ¡Muchas gracias!
Vasdemos [at] yahoo [dot] co [dot] uk
** Reglas de Delphi **
