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).
views:
196answers:
3You 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
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.
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.