Finding the time taken to send messages with WCF net.tcp

Question

I’m writing a prototype WCF enabled distributed app, to try and find out any issues I’ll have upgrading my existing “sending xml over tcp to communicate” apps I’ve got. I’m using Callback Contracts to register clients with a server (Singleton in ServiceHost) and so far all the communications between client and server work. I can connect multiple clients to the server and send a broadcast from the server that is received by all clients. I can block a particular client and the other clients still receive the calls. This is good.

To continue my learning and evaluation of performance I would like the client to record what time the server sends each message, as well as what time the client receives that same message. How should I best go about this?

Is there something similar to SOAP extensions, where I can add to the outgoing from the server and incoming to the client? Or would I need to add a “timeSent” parameter to every method that the server calls on the client and record the time received on the client (yuck!)? Is there a better way to accomplish this?

I am using net.tcp rather than wsDualHttpBinding (which also works but is less performant).

Answer 1

Hmmm... that's a difficult one. The problem here is you can't even make sure both the client and the server timers are in sync.

If what you want to do is send some out-of-band data, so that you don't need to modify your methods, you can use the method suggested here. I think it should be enough.

Answer 2

David is right about the problems with clock synchronization. However, adding the timestamp information outside of the service/client implementation is not hard at all on WCF.

You're right it doesn't support SoapExtensions, though, in fact, it has a much richer set of extensibility point. In your specific case, I think a custom behavior that adds a MessageInspector would probably work.

There are actually two message inspector interfaces: One for the client (IClientMessageInspector), and one for the server (IDispatchMessageInspector).

The easiest way to hook up a dispatch inspector on the service side is through a service behavior (IServiceBehavior), since you can hook that up to your service implementation as a custom attribute. Here's a simple example of how to do it. You can also hook it up through an IEndpointBehavior, but you need to do that either through code when setting up the service host or through configuration, which requires writing a bit more code.

On the client side, you still use an endpoint behavior, but introducing those through code is a lot easier since you have direct access to the ClientRuntime from the proxy client.

Anyway, I would think that something like a timestamp is better added to the message as a custom header so that it is not part directly of the message payload.