David Wortendyke - MSFT:
The NetTcpBinding wraps a TCP socket as a channel and sockets don't have any built-in feature for for providing the sender's machine-name. In other words, it isn't povided by the underlying transport so we don't have a way to surface it to you.
Do you have the option of modifying your contract so it includes the client's machine-name as one of the parameters? Alternately, you could add a message-inspector that adds the machine-name as a custom header that you then extract in your service.
Clemens Vasters - MSFT :
What if you are using HTTP and the message is passing several proxies? What if you are using MSMQ? How about IPv6 addresses? What should be there when the message arrives via named pipes?
In other words: WCF abstracts away from the network details and provides a single programming model that's independent of what transport you choose. Some of those might be an abstraction over IP themselves or the concept of IP doesn't apply since they are a disk-based store & forward mechanism such as MSMQ. The additional issue of proxies and NATs adds an additional layer of complexity here. So while we might be able to give you some information bit in some cases, the quality of that information would vary from transport to transport.
For HTTP bindings, we do have some of the information you might want in the HttpRequestMessageProperty that you can retrieve from the message Properties collection either directly or with OperationContext.Current.IncomingMessageProperties[HttpRequestMessageProperty.Name]
Hope that helps