如何在同一个套接字上托管WCF服务和TCP服务器？
今天我使用 ServiceHost 来自托管 WCF 服务。
我想在我的 WCF 服务附近托管我自己的 TCP 程序，用于直接套接字操作（例如留置某种广播 TCP 流）
我需要控制 URL 命名空间（这样我就可以让我的客户端将 TCP 流直接发送到我的服务使用一些不错的 URL，例如 example.com:port/myserver/stream?id=1 或 example.com:port/myserver/stream?id=anything，这样我就不会被 1 个客户端用于 1 个套接字的想法所困扰在某一时刻，我真的希望将我的 WCF 服务保留在与我自己的服务器相同的端口上，或者能够调用 www.example.com:port/myWCF/stream?id=222... 并且我希望它可以在任何端口上工作 - 不仅仅是 80）
任何人都可以帮助我吗？
我现在只使用WCF。我不喜欢它的运作方式。这是我想开始迁移以清除 TCP= 的众多原因之一
我不能使用 net-tcp 绑定或任何其他很酷的 WS-* 绑定（今天我使用最简单的一个，以便我的客户喜欢 Flash、AJAX等轻松与我联系）。
我需要快速、简单地实现连接协议，就像我在使用套接字实时传输大量数据时创建的连接协议一样。
那么..有什么想法吗？拜托 - 我需要帮助。
Tooday I use ServiceHost for self hosting WCF cervices.
I want to host near to my WCF services my own TCP programm for direct sockets operations (like lien to some sort of broadcasting TCP stream)
I need control over URL namespaces (so I would be able to let my clients to send TCP streams directly into my service using some nice URLs like example.com:port/myserver/stream?id=1 or example.com:port/myserver/stream?id=anything and so that I will not be bothered with Idea of 1 client for 1 socket at one time moment, I realy want to keep my WCF services on the same port as my own server or what it is so to be able to call www.example.com:port/myWCF/stream?id=222... and I want it to work on Any port - not only 80)
Can any body please help me with this?
I am using just WCF now. And I do not enjoy how it works. That is one of many resons why I want to start migration to clear TCP=)
I can not use net-tcp binding or any sort of other cool WS-* binding (tooday I use the simpliest one so that my clients like Flash, AJAX, etc connect to me with ease).
I needed Fast and easy in implemrnting connection protocol like one I created fore use with Sockets for real time hi ammount of data transfering.
So.. Any Ideas? Please - I need help.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
好吧，如果您要使用纯套接字，您也可以让您的服务充当代理。让 WCF 服务在其他端口上侦听，并让您的应用程序在所需端口上侦听。当您在应用程序中收到请求时，手动解析标头并检查它是否适用于您的服务或 WCF 服务。如果它用于 WCF 服务，请打开到 WCF 服务的 TCP 连接并将接收到的数据传递给它，然后只需将 WCF 的答案传回客户端。
另一方面，您可以通过编写自己的 WCF 来大大加快 WCF 的速度自定义绑定。 WCF 在使用反射完成的序列化上浪费了大量时间（速度很慢），解决这个问题将大大提高速度。
Well if you're going to drop down to pure sockets, you could as well make your service act as proxy. Make WCF Services listen on some other port, and your app on the desired port. When you receive request in your app, manually parse header and check weather it is intended for your service or WCF Service. If it's intended for WCF service, open a TCP connection to WCF service and pass the received data to it, and then simply pass back WCF's answer to the client..
On the other hand you could speed up WCF quite a lot by writing your own custom binding. Lots of time WCF looses on serialization that is done using reflection (which is slow), going around this would improve your speed considerably.
如果 WCF 的问题是性能，那么您应该尝试二进制网络 TCP 绑定来消除 XML 序列化以提高性能。
一些高流量应用程序（例如实时游戏）使用 UDP 进行大部分通信，因为它突破了协议。使用 TCP，您可以获得内置的排序和可靠性，但这是以性能为代价的，因为它会隐式延迟数据包以等待无序数据包，以便它可以按正确的顺序将它们传递给应用程序，或等待丢失的数据包被怨恨。相反，您可以使用 UDP 并实现自己的方案来验证不如 TCP 严格的数据。
WCF 有可用的 UDP 选项，或者您也可以实现自己的选项。 WCF只不过是一个消息泵，您可以用您想要的任何内容替换不同的步骤。
If your problem with WCF is performance then you should try the binary net TCP binding to eliminate XML serialization to improve performance.
Some high traffic applications, like realtime games, use UDP for the majority of communication since it cuts through the protocol. With TCP you get ordering and reliability built in, but this comes at the cost of performance because it will implicitly delay packets to wait for out of order packets so that it can hand them to the application in the correct order, or wait for lost packets to be resent. Instead you can use UDP and implement your own scheme for verification of data that is less stringent than TCP.
There are UDP options available for WCF, or you could implement your own. WCF is nothing more than a message pump, and you can replace different steps with whatever you want.
不确定这是否对您有帮助，但请尝试打开您的 Net TCP 共享服务。
Not sure if this will help you or not, but try turning on your Net TCP Sharing Service.