套接字编程与Web服务？

Question

我想创建一个移动消息服务,但我不知道使用套接字编程或Web服务哪个更好？

在创建此类服务时我需要考虑哪些问题？如连接成本..等

如果您需要更多详细信息,请在投票或关闭之前告诉我!

Answer 1

Web服务通常说"更容易",这要归功于它们对它们的巨大兴趣以及对开发人员工具以及库和框架的支持.

但是,特别是如果您的有效负载很小(认为消息的大小与典型的SMS或推文相同),您使用Web服务创建的开销是令人望而却步的:通过无线网络(如GPRS或UMTS)发送的字节仍然非常昂贵,与传输的字节数相比电缆或ADSL.并且Web服务带有几层隐形信息,最终客户也必须支付这些信息.

因此,如果您的用例基于短消息,我至少建议您进行一些带宽模拟计算,并根据带宽节省与应用程序复杂性的增加做出决策.

在查看套接字时,还要看一下UDP:如果你可以接受这样一个事实:基本上你扔了一个数据包,并且没有在你的协议中设计一些ack机制,你永远不会确定消息到达,它是非常有效的,因为没有流量来创建和维护连接,甚至很长的消息也可以在1个UDP数据包内传输.

根据评论编辑:

• stream socket:不确定如何定义流,但是流和消息对我来说是两个非常不同的概念,流是通常较长的数据序列,而消息是一个发送的实体,并且可选地由接收器.
• 带宽模拟:理解我所说的最简单的方法是获取Wireshark并将通过网络传输的所有内容添加到一个非常短的字符串的简单请求中 - 您将看到几层管理信息(即不可见,只是为了使不同的协议层工作),这是最终用户支付的所有流量.然后,使用UDP编写一个小的模拟服务来传输相同的消息,或者使用像netcat这样的工具,这里的好教程,并添加传输的字节.你会发现交换的字节数差异很大.

EDIT2,我忘了提到:移动网络过去是开放的透明网络,设备由公共IP地址识别.NAT移动网络正在快速发展,这对这个"围墙花园"内外的设备如何进行通信(NAT遍历)产生了影响.在设计通信渠道时,您需要考虑到这一点.

至于为聊天应用程序使用流:它提供了一些概念上的优势,但你可以很好地在UDP之上分层聊天应用程序,看这里或这里