Low bandwidth on Windows Named Pipe Over WAN
I'm having poor performance issues using a Windows named pipe. Performance degrades rapidly as network latency increases. There is a roughly linear relationship between messages sent per second and round trip time. It seems like the client has to receive each message before the server sends the next one. This leads to very poor performance, I can only send 5 (~ 100 bytes) messages per second on a link with 200ms RTT.
The pipe is asynchronous, using multiple overlap writes (and multiple overlapped reads on the client side), but this does not improve throughput. Can I send messages in parallel over a named pipe? The pipe is created using PIPE_TYPE_MESSAGE, will PIPE_READMODE_BYTE perform better? Is there any other way to improve performance?
This is a deployed solution, so I can't just replace the pipe with a socket connection (I read that Windows named pipe is deprecated for WAN and I'm wondering if that's why). I would appreciate any help on this matter.
a source to share
I made it work by introducing a small (~ 1ms) fixed delay to buffer as much data as possible before writing to the pipe. Through a 200ms RTT network link, I can send ten times as much data in about a third.
I am sending a message down the pipe when it first connects, so the client can determine the communication mode supported by the server and send data accordingly.
a source to share
We found Named Pipes had poor performance from Windows XP .
I have no solution for you. But I agree that Named Pipes are useless with XP. Because of this, we completely changed our software (in terms of IPC).
Are your commits into a separate DLL? Perhaps you could replace the DLL with an interface that looks the same but behaves differently?
a source to share