¿Qué tan lentos son los sockets TCP en comparación con las tuberías con nombre en Windows para localhost IPC?

Estoy desarrollando un Proxy TCP para ser puesto frente a un servicio TCP que debe manejar entre 500 y 1000 conexiones activas desde Internet.

El proxy se ejecuta en la misma máquina que el servicio, y es en su mayoría transparente. El servicio, en su mayor parte, desconoce el proxy, y la única excepción es la notificación de la dirección IP remota real de los clientes.

Esto significa que, para cada socket TCP abierto entrante, hay dos sockets más en el servidor: el segundo del par en el Proxy y el del servicio real detrás del proxy.

Los tamaños de las ventanas de envío y recepción en los dos sockets de Proxy se establecen en 1024 bytes.

¿Cuáles son las implicaciones de rendimiento en esto? ¿Qué tan lenta es esta configuración? ¿Debo esforzarme en cambiar el servicio para usar Canalizaciones con nombre (u otro mecanismo de IPC), o un socket TCP localhost es en su mayor parte un IPC eficiente?

La fusión de las dos aplicaciones no es una opción. En este momento estamos atrapados con la configuración de dos procesos.

EDITAR: La razón para tener dos procesos separados en el mismo hardware es 100% económico. Solo tenemos un servidor y no estamos planeando obtener más (sin dinero).

El servicio TCP es un software heredado en Visual Basic 6 que superó nuestras expectativas. El proxy es C ++. No tenemos el tiempo, el dinero ni la mano de obra para volver a escribir y migrar el código VB6 a un entorno de programación moderno.

El proxy es nuestro intento de mitigar un problema de rendimiento específico en el servicio, unAtaque DDoS Estamos recibiendo de vez en cuando.

El proxy es de código abierto,Y aquí está el código fuente del proyecto..

Respuestas a la pregunta(6)

Su respuesta a la pregunta