使用 XMPP 进行数据传输 - 有什么理由不这样做？
我需要一个简单、轻量级的身份验证和数据传输机制（在.NET 平台上）。我看过 WCF 和 SOAP 等，它们对于我的需求来说似乎都太头重脚轻和复杂。我需要一些简单直接的东西引导我使用像 Jabber 这样的聊天协议。我的数据传输大多很小 - 例如：用户搜索某些内容并返回一些结果等。
鉴于 Jabber 进行身份验证、加密和您拥有的功能，我有什么理由不应该使用它？关于替代品的建议？
谢谢
I need a simple, lightweight authentication and data transfer mechanism (on .NET platform). I have looked a WCF and SOAP etc. they all seem too top-heavy and complicated for my needs. I need something simple and straight-forward leading me to a chat protocol like Jabber. My data-transfer is mostly small - example: user searches for something and gets some results back etc.
Given Jabber does authentication, encryption and what-have-you, any reasons why I should not be using it? suggestions on alternates?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
搜索结果听起来不像是点对点的（我猜测搜索往往与数据存储位于同一位置），在这种情况下，HTTP 可能适合您的需求。以任何方式编写服务器并使用 WebClient，为每个请求提供身份验证。如果您担心安全性，可以使用摘要式身份验证。 XMPP 的缺点是您必须担心保持连接，并且网络上存在大量无关信息。例如，存在、智商、协议协商。另外，ejabberd（不确定其他的 - 是否有大型 .Net XMPP 服务器？）倾向于尝试协商 SSL。
如果您不担心带宽，您可能不会担心上述任何问题，但当然最简单的编程模型只是 WebClient 触发无状态请求。您永远不会断开连接，并且错误处理也很简单。
OTOH 您对上述评论的回应似乎暗示您可能有一些 P2P 元素，在这种情况下，HTTP 可能无法提供服务，除非您结合一点网络遍历和代理以将对等点作为公共地址相互公开。 XMPP 比这简单得多。
我们有一个网络演讲厅应用程序，通过 XMPP 无缝传输 750Mb/s。您可能会发现它可以正常处理负载。
我推荐在服务器上使用 ejabberd（它是跨平台的并且令人难以置信），在客户端上推荐 agsXMPP。
Search results don't sound peer to peer (searching tends to be colocated with the datastore is why I'm guessing that), in which case HTTP probably fits your needs. Write your server in anything whatsoever and use a WebClient, supplying authentication to each request. You can use Digest authentication if you're concerned about security. The downside of XMPP is that you have to worry about staying connected, and that there's a lot of extraneous information on the network. For instance, presence, iq, protocol negotiation. Also ejabberd (not sure about the others - is there a big .Net XMPP server?) tends to try to negotiate SSL.
If you're not worried about the bandwidth you're probably not worried about any of the above, but certainly the simplest programming model is just a WebClient firing stateless requests. You're never disconnected and the error handling is simple.
OTOH your response to the above comment seems to imply that you might have some P2P elements, in which case HTTP will probably not serve, unless you incorporate a little bit of network traversal and proxying to expose the peers as public addresses to each other. XMPP is WAY simpler than that.
We have a networked lecture theatre application transferring 750Mb/s seamlessly over XMPP. You'll probably find it handles the load ok.
I recommend ejabberd on the server (it's cross platform and incredible) and agsXMPP for the client.
听起来 XMPP 可能很合适，但您也应该考虑 HTTP。 XMPP 可能仅在您确实需要有状态消息传递/传输时才有意义。如果您使用例如 Transfer-Encoding: chunked，HTTP 可以很好地处理长时间运行的连接。
Sounds like XMPP might be a good fit, but you should consider HTTP as well. XMPP probably only makes sense if you really need stateful messaging/transfer. HTTP could work quite well for long-running connections if you use e.g. Transfer-Encoding: chunked.
对于数据传输，为什么不使用简单的普通 HTTP？
For datatransfer, why not use simple plain HTTP?