tags:

views:

196

answers:

3

I have a WCF webservice, a number of webservices actually, all using net.tcp and hosted in IIS through WAS. Multiple clients are calling these services, all are known but cannot be controlled (that is, I cannot change their code and therefore I cannot change the services either). Some of these clients are not very nice to the service and cause a lot of errors, and I would like to find out which are the problematic ones. I cannot look at the credentials passed as they do not use authentication, I cannot use ip/port as they are all coming from the same place. My challenge is now to find some way of distinguishing between these clients, for example by looking at the calling assembly or something on the remote system that identifies the client. Anyone aware of any such information? I have access to the IIS log, event viewer, trace-files and the services them selves (i can put anything into the code that does not interrupt normal flow).

+1  A: 

You could to write some custom behavior to inspect your service received messages; a sample can be found here: Writing a WCF Message Inspector and Simple WCF Service Behavior: Inspect Messages Through Debug Output

Rubens Farias
There doesen't seem to be anything on the message object that distinguishes the client...
dphreak
+1  A: 

Check out the WCF built-in logging and tracing mechanisms:

Plenty more when you search for "WCF, tracing, logging". The support built right into WCF is quite extensive - you can easily log the messages, see where they came from, analyze them - and you can turn it on or off as needed.

marc_s
What exactly in the messeges shows where they came from? I tried tracing "verbose, activitytracing" but that does not reveal anything about the client, only the method called, responses and so on.
dphreak
A: 

It seems that your problem is not with the logging mechanism; it's with finding a way to distinguish among the clients.

If you cannot control the code of the clients, can you at least change the URL they use for the endpoint? If so, then I recommend you expose the service at multiple endpoint addresses, then have each client use a unique address. The address will then stand as a proxy for the client.

John Saunders
You are absolutely right. The only thing i really control on the client is the web.config/app.config and doing something with the url might actually be possible. I wonder if i can in some way insert something into the url itself that does not change the address of the service but is still passed to the server...
dphreak
Based on your idea i came up with a solution. After the service url i add ?client=something in the web/app.config. This means absolutely nothing to the service, but it is included in the service traces. Simple and effective and it doesn't require any change to the actual code.
dphreak