基于 HTTP Web 的"拉"方式的 P2P 服务器端
ideawu
发这封邮件和大家讨论下这种架构.
因为 HTTP 的工作原理, 所以使用本方式, 通信延迟大. 当两个节点要进行通信时, 某一个节点先将数据存放在服务中心, 然后另一个节点再到
服务中心取这些数据. 因为节点取数据的周期不可能太小, 太小会对 Web 服务器造成太大的压力, 所以延迟以秒来计算.
比较来说(相对TCP), 我认为基于 HTTP Web 的方式更有优势. 因为 Web 集群技术已经相当成熟. 当 P2P 网络变得庞大时,
可以应用现有的成熟技术来解决服务中心的问题.
另一方面, Web 开发技术多样化和流行. 可以使用 Java/J2EE, .Net, PHP, C/C++ CGI 等技术. 这也表示一旦应
用确定或者进行更改, 将非常容易找到开发人员. 所以开发成本可以降低.
单就 IM 应用来说, 账号管理, 好友功能, 群(圈子), 留言, 黑名单, 客户端广告等用 Web 方式来实现都是非常简单的技术.
大家不妨发表下自己的看法. 原文写在我的博客: http://www.ideawu.net/ideablog/category8/article276.html
Feng Yu
--
专注 高性能 容错 分布服务器的实现（erlang）
http://mryufeng.javaeye.com
Jerry Wang
Web 开发相关的技术确实很成熟，但是选用 webserver 运行游戏逻辑就看游戏需求了，做棋牌这些算小意思了。所以说关键就是个运行效率问
题，开发效率（全脚本）应该会比较高。
还有个问题： 是否能找到懂得如何做游戏的 web 程序员？
个人认为：整合web服务进入游戏 Server Cluster 是个趋势，web服务到未必需要去处理一般游戏逻辑，实际上已经有人这么做了......
tao yuan
sunway
目前WEB的IM类受到的限制非常多，不是用一些技术名词可以解决的，复杂性永远存在。
On 10月19日, 下午3时31分, ideawu <ide...@163.com> wrote:
qingdong he
Feng Yu
ideawu
ideawu
-------------------------------------------------------------
On 2007-10-19 16:03:53, tao yuan<yty...@gmail.com> wrote
Subject：Re: 基于 HTTP Web 的"拉"方式的 P2P 服务器端
Feng Yu
ideawu
1. Web 集群技术很成熟.
2. Web 开发门槛低.
ideawu
-------------------------------------------------------------
On 2007-10-19 18:16:40, Feng Yu<mryu...@gmail.com> wrote
Subject：Re: Re: 基于 HTTP Web 的"拉"方式的 P2P 服务器端
>
用Web做服务器端？ 明白， 就是不明白为什么。
sunway
On 10月19日, 下午4时15分, "ideawu" <ide...@163.com> wrote:
> 我只是用Web做服务器端, 用户建立直连后使用P2P通信, 大家不要理解错了.
>
> ideawu
>
> -------------------------------------------------------------
> On 2007-10-19 16:03:53, tao yuan<yty...@gmail.com> wrote
> Subject：Re: 基于 HTTP Web 的"拉"方式的 P2P 服务器端
>
>
>
> 这个还叫做p2p吗，P2P就是为了节约Server成本， 你这种方式看不出什么优势。
>
> 在07-10-19，Feng Yu <mryuf...@gmail.com> 写道：
>
>
>
>
>
> > 你赶紧靠谱吗？
>
> > On 10/19/07, ideawu <ide...@163.com> wrote:
> > > 最近我在开发一个P2P库, 服务器端选用 Web Server 的架构. 服务器端除了帐号管理外和其它业务逻辑外, 最重要的功能是数据中转.
> > > 发这封邮件和大家讨论下这种架构.
>
> > > 因为 HTTP 的工作原理, 所以使用本方式, 通信延迟大. 当两个节点要进行通信时, 某一个节点先将数据存放在服务中心, 然后另一个节点再到
> > > 服务中心取这些数据. 因为节点取数据的周期不可能太小, 太小会对 Web 服务器造成太大的压力, 所以延迟以秒来计算.
>
> > > 比较来说(相对TCP), 我认为基于 HTTP Web 的方式更有优势. 因为 Web 集群技术已经相当成熟. 当 P2P 网络变得庞大时,
> > > 可以应用现有的成熟技术来解决服务中心的问题.
>
> > > 另一方面, Web 开发技术多样化和流行. 可以使用 Java/J2EE, .Net, PHP, C/C++ CGI 等技术. 这也表示一旦应
> > > 用确定或者进行更改, 将非常容易找到开发人员. 所以开发成本可以降低.
>
> > > 单就 IM 应用来说, 账号管理, 好友功能, 群(圈子), 留言, 黑名单, 客户端广告等用 Web 方式来实现都是非常简单的技术.
>
> > > 大家不妨发表下自己的看法. 原文写在我的博客:
> >http://www.ideawu.net/ideablog/category8/article276.html
>
> > --
> > 专注 高性能 容错 分布服务器的实现（erlang）
> >http://mryufeng.javaeye.com- 隐藏被引用文字 -
>
> - 显示引用的文字 -
ideawu
-------------------------------------------------------------
On 2007-10-19 19:41:14, sunway<sunh...@gmail.com> wrote
ideawu
-------------------------------------------------------------
On 2007-10-19 21:56:43, sunway<sunh...@gmail.com> wrote
>
ideawu
On 2007-10-19 21:56:43, sunway<sunh...@gmail.com> wrote
Subject：Re: 基于 HTTP Web 的"拉"方式的 P2P 服务器端
>
Feng Yu
ideawu
-------------------------------------------------------------
On 2007-10-20 12:01:50, Feng Yu<mryu...@gmail.com> wrote
Subject：Re: Re: 基于 HTTP Web 的"拉"方式的 P2P 服务器端
>
> 想借鉴bitorrent的思路不错 但是老兄你作的是p2p库哦，不能搞个web构架和你的库一起发布吧？
sunway
当然这个也是他成功多种因素的一部分，不过现在电驴类的应用发展更快一些，因为电驴下载文件
对服务器的依赖很低。
你的P2P是否是利用WEB SERVER来帮你中转？
On 10月20日, 下午12时40分, "ideawu" <ide...@163.com> wrote:
> 你说得正是, 我这个P2P是中心化的拓扑结构. 我的计划是同时提供客户端SDK和服务器端解决方案. 我想和大家讨论的正是服务器端的解决方案. 可能你主要考虑的是客户端SDK, 所以误解了我的意思.
>
> -------------------------------------------------------------
> On 2007-10-20 12:01:50, Feng Yu<mryuf...@gmail.com> wrote
> Subject：Re: Re: 基于 HTTP Web 的"拉"方式的 P2P 服务器端
>
>
>
>
>
> > 想借鉴bitorrent的思路不错 但是老兄你作的是p2p库哦，不能搞个web构架和你的库一起发布吧？- 隐藏被引用文字 -
>
> - 显示引用的文字 -
ideawu
两个节点无法直接进行网络连接传输文件, 可以经过Web服务器中转. 虽然经受了很长的时延, 很多时候还是在用户的可接受范围.
对于需要频繁经过服务器中转, 以及需要频繁与服务器进行交互的P2P应用, 使用Web作为服务器端确实不适合. 但是, P2P应用有很多种, 如
果某种P2P应用在与服务器交互时可以容忍长时延, 为什么不可以使用Web服务器. 如 IM, 类似PPLive 等应用就适合完全使用Web服务
器作为服务器端, 防火墙穿透等功能可以应用超级节点.
动物园墙垮
egg
Peer1 想要与Peer2 共享数据当然是他们之间直接通讯啦！
就算2 Peer之间由于网络链路不能直接连接也应该找公网的peer 3作为中转，最后才是考虑服务器中转吧？
tao yuan
P2P 直播，也只是在公网上搭建一些服务器，作为SuperNode, 来做P2P网络的带宽补偿，提高流畅度.
如果服务器做中转的话，那就失去P2P的意义了。
ideawu
比如A想与B直连, 就必须经过服务器中转, 这样, 服务器才能进行权限管理(比如, 不交钱就不允许中转). 面对这种类型的业务需求, 如果经过 Super Node 中转, P2P网络的提供者很难控制.
数据经过服务器中转, 这个说法可能令人混淆, 因为这是在数据通信的角度来说, 不过, 这些中转的数据是控制指令.
这样说吧, 我提供了一个P2P网络服务(包括P2P客户端软件, 服务器端, 周边软件等), 有一个需求, 用户必须交费才能使用我的服务. 那么, 要达到这个目的, 必须存在中心服务器, 对客户加入该网络, 使用该网络的资源等进行管理和控制.
总结来说, 和P2P网络管理相关的控制数据必须通过服务器中转, 以便服务器能对这些数据进行过滤和处理. 非控制数据由节点直连进行传输(这是P2P部分). 我的计划是使用 Web Server 架构来开发这个服务器端.
ideawu http://www.ideawu.net/
-------------------------------------------------------------
On 2007-10-22 16:23:46, tao yuan<yty...@gmail.com> wrote
Subject：Re: 基于 HTTP Web 的"拉"方式的 P2P 服务器端
Young Lee
Feng Yu
Young Lee
tao yuan
sunway
难道玩家不知道电驴，BT？
收了钱怎么应付电影厂家，歌曲作者等等。
On 10月22日, 下午4时45分, "ideawu" <ide...@163.com> wrote:
> 是的. 应该尽可能减小经过服务器中转的数据的量. 但是, 因为特定业务的要求, 有些数据必须经过服务器中转, 而不能经过 Super Node 中转.
>
> 比如A想与B直连, 就必须经过服务器中转, 这样, 服务器才能进行权限管理(比如, 不交钱就不允许中转). 面对这种类型的业务需求, 如果经过 Super Node 中转, P2P网络的提供者很难控制.
>
> 数据经过服务器中转, 这个说法可能令人混淆, 因为这是在数据通信的角度来说, 不过, 这些中转的数据是控制指令.
>
> 这样说吧, 我提供了一个P2P网络服务(包括P2P客户端软件, 服务器端, 周边软件等), 有一个需求, 用户必须交费才能使用我的服务. 那么, 要达到这个目的, 必须存在中心服务器, 对客户加入该网络, 使用该网络的资源等进行管理和控制.
>
> 总结来说, 和P2P网络管理相关的控制数据必须通过服务器中转, 以便服务器能对这些数据进行过滤和处理. 非控制数据由节点直连进行传输(这是P2P部分). 我的计划是使用 Web Server 架构来开发这个服务器端.
>
> ideawuhttp://www.ideawu.net/
>
> -------------------------------------------------------------
> On 2007-10-22 16:23:46, tao yuan<yty...@gmail.com> wrote
> Subject：Re: 基于 HTTP Web 的"拉"方式的 P2P 服务器端
>
>
>
> 现有的主流p2p协议， 譬如BT, EMULE, 还没有采用服务器做中转的吧.
> P2P 直播，也只是在公网上搭建一些服务器，作为SuperNode, 来做P2P网络的带宽补偿，提高流畅度.
> 如果服务器做中转的话，那就失去P2P的意义了。
>
> 在07-10-22，egg <egg.t...@gmail.com> 写道：
>
>
>
>
>
> > 为什么要用服务器中转呢？
> > Peer1 想要与Peer2 共享数据当然是他们之间直接通讯啦！
> > 就算2 Peer之间由于网络链路不能直接连接也应该找公网的peer 3作为中转，最后才是考虑服务器中转吧？- 隐藏被引用文字 -
>
> - 显示引用的文字 -
ideawu
关于收费的P2P服务的存在的合理性可以开另外一个主题.
ideawu http://www.ideawu.net/
-------------------------------------------------------------
On 2007-10-24 14:24:49, sunway<sunh...@gmail.com> wrote
biggio
息,如port和ip等
.这和fiirfox和ie没关系.web server 可以自己实现,也可以利用现有的appach或者iis
重要的是这一种思想,很不错.
补充一点,web server上,最好还收集一下所有客户端的网络类型,这样,web server可以行使中心服务器的功能,让网络类型相同的节点
之间进行p2p,这样穿透的几率更好,效果更好.
严格的说,楼主的思想可以概括成
基于http协议进行信息交换,然后进行UDP的网络穿透,实现p2p的数据传输机制
On 10月23日, 下午10时25分, "Young Lee" <softfis...@gmail.com> wrote:
> 这种干什么都需要服务器认证授权的中心拓扑的P2P想象eDONKEY server一样单服务器带几十万clients不大可能吧,
> 需求决定设计.
>
> Young Lee
> 2007-10-23
>
> 发件人： Feng Yu
> 发送时间： 2007-10-22 23:42:27
> 收件人： dev4s...@googlegroups.com
> 抄送：
> 主题： Re: Re: Re: 基于 HTTPWeb 的"拉"方式的 P2P 服务器端
>
> 单服务器几百几千对大型的p2p网络 根本不够用。
>
> > ideawuhttp://www.ideawu.net/
>
> > -------------------------------------------------------------
> > On 2007-10-22 16:23:46, tao yuan <yty...@gmail.com > wrote
> > Subject：Re: 基于 HTTP Web 的"拉"方式的 P2P 服务器端
>
> > 现有的主流p2p协议， 譬如BT, EMULE, 还没有采用服务器做中转的吧.
> > P2P 直播，也只是在公网上搭建一些服务器，作为SuperNode, 来做P2P网络的带宽补偿，提高流畅度.
> > 如果服务器做中转的话，那就失去P2P的意义了。
>
> > 在07-10-22，egg <egg.t...@gmail.com > 写道：
>
> > > 为什么要用服务器中转呢？
> > > Peer1 想要与Peer2 共享数据当然是他们之间直接通讯啦！
> > > 就算2 Peer之间由于网络链路不能直接连接也应该找公网的peer 3作为中转，最后才是考虑服务器中转吧？
>
> --
> 专注 高性能 容错 分布服务器的实现（erlang）http://mryufeng.javaeye.com- 隐藏被引用文字 -
>
> - 显示引用的文字 -
tao yuan
不过感觉用WebServer，开发虽然方便，但是效率上有没有保障。
lwk...@gmail.com
从设计到实现服务端和客户端组件花了我将近1个月的时间.内核全部使用IOCP多线程完成.
不扯技术名词,实实在在.
通过前一段时间仔细阅读了libTorrent和BT相关的SOURCE,了解他们这些大多扔一个IP和PORT就不管,让你自己去连啥的.
针对国内的环境大多都是内网的问题,提出了这个结构,估计能解决99%的P2P直连通道.还有剩下1%靠服务端虚拟的P2P进行转发
让整个的结构,和你其他程序的主逻辑分离.
呵,整个底层通了,刚兴奋还睡不着觉,我也不知道自己在说什么了.
我现在是写成COM IDispatch估计会直接根据实际要求做上层应用,
如果合适的话,有一天,人人都愿意安装这个控件,都可以让基于HTTP的P2P见鬼去了.
On 10月23日, 下午10时25分, "Young Lee" <softfis...@gmail.com> wrote:
> 这种干什么都需要服务器认证授权的中心拓扑的P2P想象eDONKEY server一样单服务器带几十万clients不大可能吧,
> 需求决定设计.
>
> Young Lee
> 2007-10-23
>
> 发件人： Feng Yu
> 发送时间： 2007-10-22 23:42:27
> 收件人： dev4s...@googlegroups.com
> 抄送：
> 主题： Re: Re: Re: 基于 HTTPWeb 的"拉"方式的 P2P 服务器端
>
> 单服务器几百几千对大型的p2p网络 根本不够用。
>
> > ideawuhttp://www.ideawu.net/
>
> > -------------------------------------------------------------
> > On 2007-10-22 16:23:46, tao yuan <yty...@gmail.com > wrote
> > Subject：Re: 基于 HTTP Web 的"拉"方式的 P2P 服务器端
>
> > 现有的主流p2p协议， 譬如BT, EMULE, 还没有采用服务器做中转的吧.
> > P2P 直播，也只是在公网上搭建一些服务器，作为SuperNode, 来做P2P网络的带宽补偿，提高流畅度.
> > 如果服务器做中转的话，那就失去P2P的意义了。
>
> > 在07-10-22，egg <egg.t...@gmail.com > 写道：
>
> > > 为什么要用服务器中转呢？
> > > Peer1 想要与Peer2 共享数据当然是他们之间直接通讯啦！
> > > 就算2 Peer之间由于网络链路不能直接连接也应该找公网的peer 3作为中转，最后才是考虑服务器中转吧？
>
> --
tao yuan
如果靠服务器端转发的话，还做成P2P干嘛， P2P的一个目地就是降低服务器端投入的成本，除非象P2P流媒体这种应用，需要服务器的带宽补偿，一般的应用，只需要一个Tracker服务器即可.
刚刚才底层才测试通过,一套全部用TCP实现P2P连接的可集群性,服务端辅助连接的分离式P2P架构.
从设计到实现服务端和客户端组件花了我将近1个月的时间.内核全部使用IOCP多线程完成.
不扯技术名词,实实在在.
通过前一段时间仔细阅读了libTorrent和BT相关的SOURCE,了解他们这些大多扔一个IP和PORT就不管,让你自己去连啥的.
针对国内的环境大多都是内网的问题,提出了这个结构,估计能解决99%的P2P直连通道.还有剩下1% 靠服务端虚拟的P2P进行转发
lwk...@gmail.com
情况的不通,没有办法的时候,这时候服务器会自主承担起转发的责任,建立条虚通道.
如果AB间的连接的成功是建立在99%的直连的基础上,那么他对P2P服务器的连接为短连接,即提供好正常的通道后,直接断开,用原有连接相连.
On 10月27日, 下午2时33分, "tao yuan" <yty...@gmail.com> wrote:
> 目前国内P2P 都以UDP 为主了， 你这种基于TCP的， 在传输性能方面要比UDP 差不少， 而且看你的描述，没有做任何的UPNP
> 和穿透的工作，这个P2P网络的性能不是很乐观。
> 如果靠服务器端转发的话，还做成P2P干嘛，
> P2P的一个目地就是降低服务器端投入的成本，除非象P2P流媒体这种应用，需要服务器的带宽补偿，一般的应用，只需要一个Tracker服务器即可.
>
> 在07-10-27，lwkl...@gmail.com <lwkl...@gmail.com> 写道：
> > > - 显示引用的文字 -- 隐藏被引用文字 -
>
> - 显示引用的文字 -
lwk...@gmail.com
我现在这种模式是AB2个人都是以一全局名来标志身份,这部分并不承担找人等工作,而是由其他你的程序的主逻辑来通知双方去向同一个
P2PServer,如果足够配合的话那么AB一定能建立直联通道,模式变了.
而且是把可能需要分离编程的东西,全都整合到一个模块上来.
简单的应用如AB间单对单传输文件视屏语音, 还有比如一种网站上有好多资源组成,同时下载某一资源的用户比较少的情况.
当然,我这部分是负责我自己的事,至于主逻辑你需要单独开发和集合.
我说的这个可集群的,你只要任意在机子配备比较多的P2PServer来进行辅助用户.
另外,我前期只开发TCP,UDP的话也可以用同样的理念做成这种模块.UDP会简单的太多.
On 10月27日, 下午2时33分, "tao yuan" <yty...@gmail.com> wrote:
> 目前国内P2P 都以UDP 为主了， 你这种基于TCP的， 在传输性能方面要比UDP 差不少， 而且看你的描述，没有做任何的UPNP
> 和穿透的工作，这个P2P网络的性能不是很乐观。
> 如果靠服务器端转发的话，还做成P2P干嘛，
> P2P的一个目地就是降低服务器端投入的成本，除非象P2P流媒体这种应用，需要服务器的带宽补偿，一般的应用，只需要一个Tracker服务器即可.
>
> 在07-10-27，lwkl...@gmail.com <lwkl...@gmail.com> 写道：
> > > 专注 高性能 容错 分布服务器的实现（erlang）http://mryufeng.javaeye.com-隐藏被引用文字 -
>
> > > - 显示引用的文字 -- 隐藏被引用文字 -
>
> - 显示引用的文字 -
ideawu
ideawu http://www.ideawu.net/
-------------------------------------------------------------
On 2007-10-27 15:26:53, lwklchj<lwk...@gmail.com> wrote
Subject：Re: 基于 HTTPWeb 的"拉"方式的 P2P 服务器端
lwk...@gmail.com
你不要告诉我,你用AJAX能在网页上监听,不监听还叫啥P2P,光有名词有啥用.
On 10月27日, 下午6时09分, "ideawu" <ide...@163.com> wrote:
> 你的思路是把 P2PServer 做成业务无关的模块吗?
>
> ideawuhttp://www.ideawu.net/
>
> -------------------------------------------------------------
> On 2007-10-27 15:26:53, lwklchj<lwkl...@gmail.com> wrote
ideawu
可能我们对P2P的理解和实现思路都不相同, 我想了解下你的想法. 你能否谈谈"COM网页通用", "AJAX网页监听"是什么意思.
ideawu http://www.ideawu.net/
-------------------------------------------------------------
On 2007-10-27 23:18:45, lwklchj<lwk...@gmail.com> wrote
lwk...@gmail.com
如果点对点能通的话,至少有一个要求,就是点需要有监听(socket的listen)接受别的点的连接.我以为你做WEB,很明显AJAX没有.
使用COM直接包装底层,是可以让基本在任何桌面环境下都可以通用,WEB是一个ATIVEX使用的特例..
我的底层全部用IOCP和多线程实现的.P2P服务器和P2P客户端是同一套内核.用服务器的技术来做客户端.
就是想以后每个用户都能建立一个庞大的网络.而不是仅仅是几个或者是几十个.以上的应用太多了.
P.S.不知道有哪家大的公司想合作呵呵.
On 10月28日, 上午9时32分, "ideawu" <ide...@163.com> wrote:
> 你理解错误了. 你不能总是把 HTTP 和浏览器技术联系在一起. 正如前面有一位朋友说的, 我使用 HTTP 协议来开发类似账号服务器的模块. 因为使用 HTTP, 所以客户端每隔一段时间查询一次服务器.
>
> 可能我们对P2P的理解和实现思路都不相同, 我想了解下你的想法. 你能否谈谈"COM网页通用", "AJAX网页监听"是什么意思.
>
> ideawuhttp://www.ideawu.net/
>
> -------------------------------------------------------------
> On 2007-10-27 23:18:45, lwklchj<lwkl...@gmail.com> wrote
> Subject：Re: 基于 HTTPWeb 的"拉"方式的 P2P 服务器端
>
>
>
> 你猜对了,写成COM就网页通用了,还拉个什么HTTPWeb P2P~
> 你不要告诉我,你用AJAX能在网页上监听,不监听还叫啥P2P,光有名词有啥用.
>
> On 10月27日, 下午6时09分, "ideawu" <ide...@163.com> wrote:
>
>
>
> > 你的思路是把 P2PServer 做成业务无关的模块吗?
>
> > ideawuhttp://www.ideawu.net/
>
> > -------------------------------------------------------------
> > On 2007-10-27 15:26:53, lwklchj<lwkl...@gmail.com> wrote
> > Subject：Re: 基于 HTTPWeb 的"拉"方式的 P2P 服务器端
>
> > Tracker只用来做P2P的速度补偿,他不需要知道对方是谁,只要他速度
> > 我现在这种模式是AB2个人都是以一全局名来标志身份,这部分并不承担找人等工作,而是由其他你的程序的主逻辑来通知双方去向同一个
> > P2PServer,如果足够配合的话那么AB一定能建立直联通道,模式变了.
> > 而且是把可能需要分离编程的东西,全都整合到一个模块上来.
> > 简单的应用如AB间单对单传输文件视屏语音, 还有比如一种网站上有好多资源组成,同时下载某一资源的用户比较少的情况.
> > 当然,我这部分是负责我自己的事,至于主逻辑你需要单独开发和集合.
> > 我说的这个可集群的,你只要任意在机子配备比较多的P2PServer来进行辅助用户.
> > 另外,我前期只开发TCP,UDP的话也可以用同样的理念做成这种模块.UDP会简单的太多.- 隐藏被引用文字 -
>
> - 显示引用的文字 -
ideawu
TCP/IP 网络并没有C/S之分, 只是 socket 对 TCP 的实现有这个要求. 而 socket 的 UDP 实现就没有, UDP 不需要 listen 和 accept. 所以你说的必须有监听只是对 TCP 而言, 并不是对 P2P 而言, P2P 没有这个要求.
===
在这里应该找不到投资和合作公司, 我觉得你如果能先做出一两个较有说服力的 Demo, 然后到专门的投资社区发个广告会更有效果.
ideawu http://www.ideawu.net/
-------------------------------------------------------------
On 2007-10-28 10:33:34, lwklchj<lwk...@gmail.com> wrote
>
ideawu
ideawu http://www.ideawu.net/
sunway
P2P不一定非要UDP，非要打洞的，BT，电驴主要是使用TCP协议的，个人用户用P2P类系统多一些，大部分个人用户都在家
上网，ADSL类都有自己的公网IP。
如果用WEB SERVER来充当P2P SERVER，确实减少了服务器端开发工作量，毕竟开发高性能服务器的人员并不多，直接用现成
的东西来做更稳定，周期更短，而且可扩展性更高。
希望看到LZ的产品推出。
> > - 显示引用的文字 -- 隐藏被引用文字 -
>
> - 显示引用的文字 -
lwk...@gmail.com
呵,我的P2P集群其实也考虑过服务端集群,反正目标是服务器的高性能库,那么服务端客户端也无所谓了.
另外上面sunway,server用来单纯的充当P2P SERVER,其实貌似邮件服务端的协议就是典型的.
如果光服务端P2P,我觉得意义不大,不能更好节省资源.
干脆开发个大家都愿意装的组件,上层开放文字流接口给大家传达用.这样文字里面你可以塞XML,那样不就是更好了.
另外打个广告,QQ群5352765,网络方面研究深入点的都进来吧,嘿嘿.
ideawu
ideawu http://www.ideawu.net/
-------------------------------------------------------------
On 2007-10-28 16:58:36, sunway<sunh...@gmail.com> wrote
>
lylone
很明显的是，这种事事都需经过web服务器做权限控制的活，web类服务器能支持个三五千就不错了，还是要用集群，算是牺牲性能换取更高的开发效率
吧。
On 10月19日, 下午3时31分, ideawu <ide...@163.com> wrote:
> 最近我在开发一个P2P库, 服务器端选用 Web Server 的架构. 服务器端除了帐号管理外和其它业务逻辑外, 最重要的功能是数据中转.
> 发这封邮件和大家讨论下这种架构.
>
> 因为 HTTP 的工作原理, 所以使用本方式, 通信延迟大. 当两个节点要进行通信时, 某一个节点先将数据存放在服务中心, 然后另一个节点再到
> 服务中心取这些数据. 因为节点取数据的周期不可能太小, 太小会对 Web 服务器造成太大的压力, 所以延迟以秒来计算.
>
> 比较来说(相对TCP), 我认为基于 HTTP Web 的方式更有优势. 因为 Web 集群技术已经相当成熟. 当 P2P 网络变得庞大时,
> 可以应用现有的成熟技术来解决服务中心的问题.
>
> 另一方面, Web 开发技术多样化和流行. 可以使用 Java/J2EE, .Net, PHP, C/C++ CGI 等技术. 这也表示一旦应
> 用确定或者进行更改, 将非常容易找到开发人员. 所以开发成本可以降低.
>
> 单就 IM 应用来说, 账号管理, 好友功能, 群(圈子), 留言, 黑名单, 客户端广告等用 Web 方式来实现都是非常简单的技术.
>
> 大家不妨发表下自己的看法. 原文写在我的博客:http://www.ideawu.net/ideablog/category8/article276.html
chai qiaozi
而web服务器端编程（asp jsp .net）丰富、容易上手是楼主决策的依据？
如果从效率上讲：
1）使用有冗余的http协议（针对楼主的应用），不是理想选择；
2）server端开发倒不是关键问题，可以采用apache modlue提高效率，而不用解释型语言，但这就没有了楼主期望的"容易上手"；
在 07-10-31，lylone<Lias...@gmail.com> 写道：
lwk...@gmail.com
On 10月31日, 下午12时39分, "chai qiaozi" <chaiqia...@gmail.com> wrote:
> 利用web服务器做中转，本质是利用http协议进行数据传输；
> 而web服务器端编程（asp jsp .net）丰富、容易上手是楼主决策的依据？
> 如果从效率上讲：
> 1）使用有冗余的http协议（针对楼主的应用），不是理想选择；
> 2）server端开发倒不是关键问题，可以采用apache modlue提高效率，而不用解释型语言，但这就没有了楼主期望的"容易上手"；
>
> 在 07-10-31，lylone<Lias....@gmail.com> 写道：
>
>
>
> > 简言之，就是使用web服务器技术来做peer list的分发控制端，没理解错吧
> > 很明显的是，这种事事都需经过web服务器做权限控制的活，web类服务器能支持个三五千就不错了，还是要用集群，算是牺牲性能换取更高的开发效率
> > 吧。
>
> > On 10月19日, 下午3时31分, ideawu <ide...@163.com> wrote:
> > > 最近我在开发一个P2P库, 服务器端选用 Web Server 的架构. 服务器端除了帐号管理外和其它业务逻辑外, 最重要的功能是数据中转.
> > > 发这封邮件和大家讨论下这种架构.
>
> > > 因为 HTTP 的工作原理, 所以使用本方式, 通信延迟大. 当两个节点要进行通信时, 某一个节点先将数据存放在服务中心, 然后另一个节点再到
> > > 服务中心取这些数据. 因为节点取数据的周期不可能太小, 太小会对 Web 服务器造成太大的压力, 所以延迟以秒来计算.
>
> > > 比较来说(相对TCP), 我认为基于 HTTP Web 的方式更有优势. 因为 Web 集群技术已经相当成熟. 当 P2P 网络变得庞大时,
> > > 可以应用现有的成熟技术来解决服务中心的问题.
>
> > > 另一方面, Web 开发技术多样化和流行. 可以使用 Java/J2EE, .Net, PHP, C/C++ CGI 等技术. 这也表示一旦应
> > > 用确定或者进行更改, 将非常容易找到开发人员. 所以开发成本可以降低.
>
> > > 单就 IM 应用来说, 账号管理, 好友功能, 群(圈子), 留言, 黑名单, 客户端广告等用 Web 方式来实现都是非常简单的技术.
>
> > > 大家不妨发表下自己的看法. 原文写在我的博客:http://www.ideawu.net/ideablog/category8/article276.html- 隐藏被引用文字 -
>
> - 显示引用的文字 -
qingdong he
ideawu
数据传输的"拉"方式, 并不要求保持连接. 我认为P2P库不应该陷入网络连接的泥潭, 应该尽可能接近应用, 除了提供客户端API, 还要提供服务器端API, 还有相对于具体应用的二次开发, 运营, 维护等方面解决方案.
ideawu http://www.ideawu.net/
-------------------------------------------------------------
On 2007-10-31 16:55:46, qingdong he<heqd...@gmail.com> wrote
Subject：Re: Re: 基于 HTTPWeb 的"拉"方式的 P2P 服务器端
qingdong he
你说的"现有的web服务器的机制不适合支持'拉'方式，原因在于一请求一线程的方式。", 这个说法很有问题, 首先你指出的原因并不是事实, 结论也不知道和原因有什么关系. 据我所知, Linux 下的 Apache 是一请求一进程, 而 lighttpd 采用单进程多路利用技术( http://blog.linuxsky.org/2/viewspace-2221 ).
ideawu
ideawu http://www.ideawu.net/
-------------------------------------------------------------
On 2007-11-01 10:21:24, qingdong he<heqd...@gmail.com> wrote
Subject：Re: Re: Re: 基于 HTTPWeb 的"拉"方式的 P2P 服务器端
Feng Yu
Kevin
服务器上得到的验证信息，进行验证，对非法peer拒绝中转。中心服务器集中管理peer的权限，并维护相关验证信息。这样不用中转数据，大可利用
P2P的优势。
On 10月22日, 下午4时45分, "ideawu" <ide...@163.com> wrote:
> 是的. 应该尽可能减小经过服务器中转的数据的量. 但是, 因为特定业务的要求, 有些数据必须经过服务器中转, 而不能经过 Super Node 中转.
>
> 比如A想与B直连, 就必须经过服务器中转, 这样, 服务器才能进行权限管理(比如, 不交钱就不允许中转). 面对这种类型的业务需求, 如果经过 Super Node 中转, P2P网络的提供者很难控制.
>
> 数据经过服务器中转, 这个说法可能令人混淆, 因为这是在数据通信的角度来说, 不过, 这些中转的数据是控制指令.
>
> 这样说吧, 我提供了一个P2P网络服务(包括P2P客户端软件, 服务器端, 周边软件等), 有一个需求, 用户必须交费才能使用我的服务. 那么, 要达到这个目的, 必须存在中心服务器, 对客户加入该网络, 使用该网络的资源等进行管理和控制.
>
> 总结来说, 和P2P网络管理相关的控制数据必须通过服务器中转, 以便服务器能对这些数据进行过滤和处理. 非控制数据由节点直连进行传输(这是P2P部分). 我的计划是使用 Web Server 架构来开发这个服务器端.
>
> ideawuhttp://www.ideawu.net/
>
> -------------------------------------------------------------
> On 2007-10-22 16:23:46, tao yuan<yty...@gmail.com> wrote
> Subject：Re: 基于 HTTP Web 的"拉"方式的 P2P 服务器端
>
>
>
> 现有的主流p2p协议， 譬如BT, EMULE, 还没有采用服务器做中转的吧.
> P2P 直播，也只是在公网上搭建一些服务器，作为SuperNode, 来做P2P网络的带宽补偿，提高流畅度.
> 如果服务器做中转的话，那就失去P2P的意义了。
>
> 在07-10-22，egg <egg.t...@gmail.com> 写道：
>
>
>
>
>
> > 为什么要用服务器中转呢？
> > Peer1 想要与Peer2 共享数据当然是他们之间直接通讯啦！
> > 就算2 Peer之间由于网络链路不能直接连接也应该找公网的peer 3作为中转，最后才是考虑服务器中转吧？- 隐藏被引用文字 -
>
> - 显示引用的文字 -
srdr...@gmail.com
我只想问另一个事就是，楼主是否考虑过详细的商业计划，盈利方式等没有？
污秽的摇篮
在有JAVA Socket做一些即时通讯的服务器!!!!