1:delphi7.0怎末没有fastreport报表控件了??? 那如何做报表(不用第三方控件的 话)
2:另外我也想问一下oicq的通信机制是怎末样的(tcp连接udp发送消息???)
2.1:两个人相互聊天时(同时在线) 是点对点通信吗?怎末通信???
2:另外我也想问一下oicq的通信机制是怎末样的(tcp连接udp发送消息???)
2.1:两个人相互聊天时(同时在线) 是点对点通信吗?怎末通信???
解决方案 »
- delphi2007下安装ehlib4.2
- 请教 Delphi 开发 asp.net 的问题~~
- DELPHI透明控件代码,求VB的实现方法
- 小问题
- 关于TStream的问题:如何得到一个指定的文件大小的stream?
- 请问,用鼠标点击,画箭头怎么画??在线等
- deiphi2010 我怎么安装起来就直接弹到商店的网页???
- 如何给已经存在的exe文件加上自己的一段代码?类似的问题我已经发了3个帖子,就是中高级会员也只能说关注一下而不会解答,难道这里真的无
- d6 personal Edition的序列号
- 工程的名字在编好后怎么改变?
- 菜问题,轻松拿分.
- 关于导出到.txt时的自动分出固定长度的列的问题!!!请帮忙!!
2.1:两个人相互聊天时(同时在线) 是点对点通信吗?怎末通信???
2.1:两个人相互聊天时(同时在线) 是点对点通信吗?怎末通信???
////////////////////////////////////////////////////////////////
主题:Free (小光) 对于OICQ的回复
发信人: ciert()
整理人: williamlong(2001-11-21 20:50:30), 站内信件
【 在 ciert (安安) 的大作中提到: 】
: 我对Oicq目前协议的初步看法
:
: 在粗略看了oicq采用的实现方式以后,我感觉非常失望。
: 理由如下,
: OICQ协议完全采用UDP封装,众所周知,UDP是不可靠
: 传输协议,但是效率比较高,同时协议封装和实现都很
: 简单。TCP协议比UDP协议消耗更多的CPU时间,相比而言
: 产生一个TCP连接和发送一个UDP包而言,TCP的开销很大,
: 这在服务器端更加明显。
: 但是,采用UDP包带来的首先是安全性问题。 呵呵,首先感谢这位网友的热心,不过还是想告诉你几点
1)下个版本的OICQ协议将全部采用128位不对称算法加密
2) 如果用TCP连接的话,请你给出一个能同时容纳10000个连接以上的方案
3) 建议你好好看看TCP连接的原理,它为什么能实现可靠连接,TCP并不是
比UDP的线路要高档一些,它也会丢包,但是它是把包重发机制封装了起
来,因此采用TCP连接和采用UDP连接所传输的数据量是差不多的,而且
在线路好的情况下,UDP的数据量要更小一些。
4) 你对重复发UDP包的机制判断有些错误,OICQ并不是拼命向服务器发包
直到有返回,而是间隔5秒,一般来说5秒都没有返回的时候这个包在
去的路上就丢了的可能性为50%,因此这样做带来的额外的开销对于服
务器而言并没有你所描述的那么重,相反,采用udp机制的节约下来的
开销已经远远抵了TCP永久连接的可怕开销
: 目前我对OICQ协议的实现方式的评价是:很差。
所以,在没有经过通盘考虑的情况下,不要妄下结论:)
不过还是非常感谢你对我们的关心和建议。
【 在 ciert (安安) 的大作中提到: 】
:
: 请看任何一个成功的C2C的电子商务站点。:) 或者例如hotmail之类的
: 免费mail站点。并发连接数都不小于5000,同时承担和OICQ相比不可比拟的
: 数据传输量。
喝喝,要知道http连接属于短连接模式,并且非常容易
平行扩展到很多台机器上,可是你见过同时容纳10000个
连接的聊天室吗,用tcp和服务器做通讯的类似的icq产品
也不是没有,可是你可以自己去问问他们服务器的负荷是
怎么样的
:
: 服务器与客户机之间的通讯确实可以部分/全部采用UDP,但是不应该用在
: 客户的互相通讯之中。
:
: 也可以包括著名的download站点,例如ftp.download.com
喝喝,似乎绝大多数ftp站点都不是无限制让用户连入的吧
:
: : 3) 建议你好好看看TCP连接的原理,它为什么能实现可靠连接,TCP并不是
: : 比UDP的线路要高档一些,它也会丢包,但是它是把包重发机制封装了起 : : 来,因此采用TCP连接和采用UDP连接所传输的数据量是差不多的,而且
: : 在线路好的情况下,UDP的数据量要更小一些。
: TCP协议我也学过:), TCP连接重发原理绝对不是靠每若干秒种重发。:),按照
: 目前的网络状况,TCP包的正常重发率根据 SNIFFER平均小于5% ( LAN里小于
: 1% ),危言耸听的不是我。我只是靠一些事实数据根据。 退一万步而言,即使
: TCP重发率达到100%,发送一个"hi"信息也用不了 2K吧? 利用TCP原理此信息
: 用OICQ封装后,网络开销不会超过128Byte ,无他,只是16倍的相差而已。如
: 果仅仅从这点上有任何争议,我可以把所有的包的每个byte都写出来。 呵呵,就算你这个2k是你测出来的,那不过是一种最最极端的情况,在网络情况
好的时候一般最多三个包重发即可以到达目的地,这样的通信量也不过60个字节
而已,况且绝大多数情况下每次的通信量不会超过500个字节,而我想目前中国的
网民里似乎绝大多数都不是按流量计费的吧,即使按流量计费,这点通信量也要
远远小于看网页的通信量,因此似乎这个问题并不是OICQ目前的协议模式好坏
的关键。
好,我们再来探讨一下客户机之间采用TCP的问题,没错ICQ的客户机之间采用
的是TCP连接,可是要知道国内的网络情况非常复杂,抛开169不说,还有有非
常多的用户使用的是proxy共享上网,而这些proxy绝大多数是三元素proxy,这样
有一个好处就是在server上记录到的client的udp端口其他客户机也同样能够向
这个端口发包,proxyserver会把这个包转发给client,这样一个客户机就可以
直接向proxy内部的机器主动发送信息而无须通过服务器中转,而且两个同在 proxy后面的客户机也可以相互直接通信而无须通过服务器中转,而如果采用TCP
方式的话这些是不可能做到的,这也是为什么广大用户纷纷觉得OICQ要比ICQ发
信息快得多的原因之一。此外采用TCP连接可能更不安全,一点不懂网络知识的
人用netstat就可以看到对方的IP,这样带来的危险要远远超过upd可以伪装源地
址进行攻击带来的危险(因为即使你知道了源地址,大多数情况下你也无能为力
)
当然,采用tcp不是没有好处,但是作为一个系统来考虑,需要权衡各方面的利弊
来作出一个选择,不可能让你占尽所有的优点,可以这么说,OICQ之所以如此深
受广大用户的喜爱,采用UDP协议功不可没。此外可以告诉你的是OICQ是目前 唯一教育网上能够使用的ICQ,如果采用TCP的话,oh,MY god~~~~ :
: : 4) 你对重复发UDP包的机制判断有些错误,OICQ并不是拼命向服务器发包
: : 直到有返回,而是间隔5秒,一般来说5秒都没有返回的时候这个包在
: : 去的路上就丢了的可能性为50%,因此这样做带来的额外的开销对于服
: : 务器而言并没有你所描述的那么重,相反,采用udp机制的节约下来的
: : 开销已经远远抵了TCP永久连接的可怕开销
: 我举的"hi"的例子是 Sniffer下的原始记录,并非我的判断失误:)
:
: 我的意思是,现在采用的连接方式对服务器负担确实很轻,但是对于网络
: 和用户未免不够负责。
: 分析OICQ协议也并非因为协议本身的好坏,是出于探索的目的:)。
:
: 谢谢您很诚意地纠正我的意见,我相信OICQ的开发者作了相当的权衡,
: 但是只考虑开销(当然,目前开销仍然不是最合理),完全忽略安全性是我
: 作为一个对安全比较关心的“网友”所不愿意看到的。 好了,最后再来探讨你所说的安全性的问题,其实仔细想想,如果不对信息流
加密的话无论是UDP还是TCP都一是一样的,安不安全和协议本身没有多大关系
因此说采用UDP就是对用户不负责任的说法未免有些牵强,难道采用TCP协议就
算是对用户负责了么?
由于开发初期人手的问题造成了明文协议的历史遗留问题,我们也感觉颇为遗憾
但是作为一个聊天系统,我们要做的好,侧重点同电子商务是不同的,否则也许
我们的系统非常安全,可是并不好用,只能说是本末倒置了,相信随着OICQ的不
断完善,在这方面我们会投入更大的精力。 :
: 和我上封帖子里写的那样,OICQ是个好的开端,而且对将来的电子商务等
: 网络市场开发和营销都是个良好基础,如果放眼将来,安全性绝对是很重要
: 的部分。 从这个意义上而言,128bit的加密是个必备的选择。 最后想说的一点就是,不同的系统有不同的侧重点,要想做好一个系统,必须
要权衡到各种利弊进行通盘的考虑,也许我们看问题的出发点不同,我们做的
是一个系统,而你看到的只是这个系统的某一个方面,因此我觉得在没有进行
全面细致地考虑的情况下就作出“很差”评价是不太负责任的。