title: How slow are TCP sockets compared to named pipes on Windows for localhost IPC?
body: <p>I am developing a TCP Proxy to be put in front of a TCP service that should handle between 500 and 1000 active connections from the wild Internet. </p>
  
  <p>The proxy is running on the same machine as the service, and is mostly-transparent. The service is for the most part unaware of the proxy, the only exception being the notification of the real remote IP address of the clients.</p>
  
  <p>This means that, for every inbound open TCP socket, there are two more sockets on the server: the secondth of the pair in the Proxy, and the one on the real service behind the proxy.</p>
  
  <p>The send and recv window sizes on the two Proxy sockets are set to 1024 bytes.</p>
  
  <p>What are the performance implications on this? How slow is this configuration? Should I put some effort on changing the service to use Named Pipes (or other IPC mechanism), or a localhost TCP socket is for the most part an efficient IPC?</p>
  
  <p>The merge of the two apps is not an option. Right now we are stuck with the two process configuration.</p>
  
  <p><strong>EDIT</strong>: The reason for having two separate process on the same hardware is 100% economics. We have one server only, and we are not planning on getting more (no money). </p>
  
  <p>The TCP service is a legacy software in Visual Basic 6 which grew beyond our expectations. The proxy is C++. We don't have the time, money nor manpower to rewrite and migrate the VB6 code to a modern programming environment.</p>
  
  <p>The proxy is our attempt to mitigate a specific performance issue on the service, a <a href="http://en.wikipedia.org/wiki/Denial-of-service_attack">DDoS attack</a> we are getting from time to time.</p>
  
  <p>The proxy is open source, <a href="http://code.google.com/p/mago-blanco-proxy/">and here is the project source code</a>.</p>