扫一扫
分享文章到微信
扫一扫
关注官方公众号
至顶头条
引用两个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
by stswordman
如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。
现场直击|2021世界人工智能大会
直击5G创新地带,就在2021MWC上海
5G已至 转型当时——服务提供商如何把握转型的绝佳时机
寻找自己的Flag
华为开发者大会2020(Cloud)- 科技行者