Your test is quite artificial. I'm not sure that is really very meaningful for an actual application. Given all the functionality of remoting, I'm quite impressed with its performance for both protocols. HTTP is built on top of TCP and has additional handshaking built into it. I would expect it to be at least marginally slower in most cases and significantly slower if you authenticate.
Both of these protocols are connection-oriented, so I wouldn't expect a huge improvement using the [OneWay] attribute when the message size is as small as yours. The slow down that you are seeing has been reported before, but I'm not convinced of its significance for a real world application. If you think it is important, I would suggest that you fire up your favorite network sniffer and see what's happening on the wire. If that's not instructive, you may want to spend some time with a monitoring tool. -----Original Message----- From: Nicko Cadell [mailto:discuss-develop-advanced-dotnet@;THEBAP.ORG] Sent: Monday, October 21, 2002 12:19 PM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] A performace comparison between the TCP and HTTP remoting channels. Well 5000 is just an arbitrary number to average the timing across. 10 is too small and throws up unpredictable effects, 1000000 takes too long to run. In this case 5000 gives nice repeatable results. As the TCP and HTTP channels both run over sockets they could be implemented similarly, just with different control syntax and error handleling, however the different in performance indicates that they are not similarly. Also a test like this shows up interesting stats, especially to do with the [OneWay] calls. One implementation detail is that the client does not guarantee that the server will receive a [OneWay] call. In fact if there is no server running at all the [OneWay] calls will be lost, however because the client waits for an ACK or a timeout it is very very slow to make [OneWay] calls without a server running to receive them. Surely if the client does not guarantee to deliver the [OneWay] call (or preserve the ordering of calls) then it could delegate the sending to a worker thread and return immediately even before it has tried to send the call? You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
