以前我也问过类似的问题,都没有得到答案.
很高兴今天终于知道结果了:不能!!!!!!!!!!!!!!!!!!!!!
很遗憾啊,微软的解释是wcf封装了底层传输信息,无法得到ip,hostname这些信息...一个不是方法的方法就是客户端在OutgoingMessageHeaders告诉服务器自己的相关信息....无语了.
相关的信息:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=717652&SiteID=1
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1174862&SiteID=1
引用两个post中的重点吧:(
David Wortendyke - MSFT:
Hello Jdang,
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.
Regards,
David
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
Clemens