当前位置:  开发笔记 > 编程语言 > 正文

为给定方案投票选择最佳协议

如何解决《为给定方案投票选择最佳协议》经验,为你挑选了2个好方法。

我有一个设计决定.我需要你的建议.

要求:

服务器和客户端.客户端通常是手机.

通过互联网连接.

服务器和客户端希望相互通信.

在客户端和服务器之间交换文本,多媒体.

文本将是一些标准格式.这是预先确定的.

实时要求

会话通常会持续5-15分钟.在某些情况下,不到一分钟.假设会话持续时间为5分钟.

该协议应遵守标准.

它必须是有效的.

选项1 我为我的应用程序设计的二进制协议.

选项2将 我的服务器实现为HTTPServlet.客户端发送post请求,post消息中的查询和servlet在消息中发送响应.但是,我认为对于实时交互,这不是一个好的选择,因为即使对于同一个客户端和会话,也会为每个帖子请求创建一个新线程.请评论一下这个效率.

选项3 使用普通的servlet.将面临与上述相同的问题.

选项4 使用SOAP

选项5 使用REST

选项6 使用Google Wave(我尚未阅读规范)

选项7 建议其他一些协议

现在,我没有与网络服务的经验,但如果是选项,那么我不介意投资于它的时间.

基本上,我希望选项1的速度和效率具有标准的处理方式.

谢谢



1> monksy..:

听起来我觉得HTTP协议最适合你.它的开销很低,已被广泛接受.使用TCP [这是移动通信的要求],它具有会话协商[连接良好而不是会话的实际状态]

使用不同的协议来共享视频和音频,但使用http设置连接.

由于需要处理,使用SOAP/Web服务不是最佳的.从个人经验来看,移动机器上的Web服务客户端更容易,但所需的处理过程非常流行,可能会在您的应用程序中造成瓶颈.[移动机器不能很好地处理线程]

另外:由于您通过无线方式发送数据,因此您还必须考虑与非制导媒体相关的其他问题.

您的要求:

服务器和客户端.客户端通常是手机.:是的

通过互联网连接.:是的,取决于您的设备网络的设置方式

服务器和客户端希望相互通信.:是的

在客户端和服务器之间交换文本,多媒体.:HTTP适用于文本和图像,但您需要切换到像UDP一样不可靠的视频.

文本将是一些标准格式.这是预先确定的.:是的

实时要求:这是不可能的,但可以尝试.

会话通常会持续5-15分钟.在某些情况下,不到一分钟.假设会话持续时间为5分钟:有一些标题可以保持会话打开

该协议应遵守标准.:RFC Something

它必须是有效的.:您需要做的唯一处理是逐行解析Key:data.

另外,我忘了提到SOAP/Webservices是XML over HTTP.


取决于移动设备的要求...使用PPC +高规格否则使用GPB b/c更容易大多数移动设备通常是低性能设备,b/c主要关注的是尽可能延长电池寿命.经验法则:如果设备具有GSM/CDMA调制解调器,它将具有低端CPU以节省功率.http://code.google.com/p/protobuf/问题:1.它扩展了HTTP协议[不是坏事但不是准系统] 2.添加额外的字符[这会延迟传输] 3.第三方组件是使用(这将使您的可执行文件更大)

2> sfussenegger..:

选项7为什么不选择XMPP

这是一个标准

它允许两个方向的消息.

您可以使用现有的XMPP基础架构(客户端可能使用他们的Google Talk帐户进行连接),也可以使用开源XMPP服务器轻松构建自己的XMPP基础架构

我也喜欢这样的事实,你基本上只编写客户端代码(因为服务器也是一个XMPP客户端) - 假设服务器和客户端都用相同的语言编写,你甚至可以使用完全相同的代码.

支持文件传输.

可以轻松扩展到您的需求

嗡嗡声(Google Wave);)

人们可能争论的唯一问题是它的效率 - 或者一般的XML效率.我不认为这是一个问题.


+1我准备添加XMPP作为答案,但你打败了我.这是显而易见的方式.PubSubHubbub是另一种可能有很大意义的可能性.
推荐阅读
Gbom2402851125
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有