Hi,
I have an existing application that uses both IPC and TCP client connection. The server is setup to create both IPC and TCP server channels to cater both IPC and TCP client connections.
The client app is also setup to create an IPC client channel if the server is the same as the client and TCP if the client is remote.
The problem that I have now is that the current design does not implement request timeout, in fact, request timeouts are being experienced in some users.
I checked MSDN (Client Channel Properties) and 'request' timeouts are available only for TCP but IPC timeouts only support connectionTimeout. If my understanding is correct, and as far as my testings are accurate, IPC does not support 'request' timeouts.
My plan is to scrap the IPC server and client and use solely TCP to be able to implement request timeouts. I am concerned of the performance.Is there a difference in terms of performance between IPC and TCP?
My server receives read and write requests from at least 2 clients. The write requests are done almost every 2 seconds and the read requests are the most frequent at almost at at least a thousand requests per second (or even faster at some times).
Please advise if using solely TCP connection can do given that I need to implement request timeouts in the client applications.
Thanks
JunPac
---------------------------------------------
Sorry for posting in the .NET Framework Class Library forum, I got warned for posting in the WCF forum the other time talking about 'legacy' .NET remoting.
