****如何突破上传速度*****
目前大部分客户均是通过adsl上网的，下载速度120K左右，而上传速度只有50k左右（猜测）
我现在要做一个视频软件，要求客户的视频数据尽可能多的发到网络上其它的客户端，如何才能突破50k的瓶颈呢？
一种是先上传到服务器，通过服务器转发。这种方法会不会太占服务器的资源了呢，如果同时在线200的话大概要怎样的服务器呢？
现在我想到了另一种方法勒，就是类似QQ采取udp直连的方法。这样的话服务器只要负责打洞和登录就可以了。
可是这样如何把一个视频发给多个客户端呢，客户的上载速度又不能超过50k呀？
一种解决方法就是采取类似bt的做法，其它的客户端帮忙中转视频数据
这样会不会人越多视频超流畅呢，呵呵^_^
可是，要求视频是实时又向的，这样处理延时和同步就成了问题了。
那就采用时间戳的方法，其它客户只能转发容许时间内的数据
这样谁的网速快，谁就能转发的多勒：）
好了，问题也就是这样了，原理也差不多了，时间是：年低完成！
*********希望高手指点一下************
问题点数：0、回复次数：140Top
1 楼vc_asm（哥俩好）回复于 2005-11-30 15:33:15 得分 0
目前大部分客户均是通过adsl上网的，下载速度120K左右，而上传速度只有50k左右（猜测）
我现在要做一个视频软件，要求客户的视频数据尽可能多的发到网络上其它的客户端，如何才能突破50k的瓶颈呢？
一种是先上传到服务器，通过服务器转发。这种方法会不会太占服务器的资源了呢，如果同时在线200的话大概要怎样的服务器呢？
现在我想到了另一种方法勒，就是类似QQ采取udp直连的方法。这样的话服务器只要负责打洞和登录就可以了。
可是这样如何把一个视频发给多个客户端呢，客户的上载速度又不能超过50k呀？
一种解决方法就是采取类似bt的做法，其它的客户端帮忙中转视频数据
这样会不会人越多视频超流畅呢，呵呵^_^
可是，要求视频是实时的，这样处理延时和同步就成了问题了。
那就采用时间戳的方法，其它客户只能转发容许时间内的数据
这样谁的网速快，谁就能转发的多勒：）
好了，问题也就是这样了，原理也差不多了，时间是：年低完成！
*********希望高手指点一下************
****回复****
Top
2 楼vc_asm（哥俩好）回复于 2005-11-30 15:41:22 得分 0
也许你会问：什么是时间戳？
时间戳就是以数据源的时间为戳，随着时间的推移和包的转发，超出容许延时的包将不再被转发
Top
3 楼fisheryj（重新开始）回复于 2005-11-30 19:09:26 得分 0
udp 数据正确与否无法保证Top
4 楼vc_asm（哥俩好）回复于 2005-12-01 08:28:24 得分 0
楼上的这位仁兄说到点子上了，如何保证数据的正确性呢？
既然是udp，那么就不需要分包打包了，那定义的包应该是多大？既然在公网上，又要通过电话线传送，暂且 512字节/包 吧（大约）。
512字节好小哦，怎么才能在这么小的包里面传送有用信息呢，即如何提高视频数据占带宽的比例呢？只能是尽可能降低协议的体积了，现在我曾用过一种协议，只要3个8字节=24字节，以后我会想法子把负荷降到12字节，这样可用数据就会达到500字节勒，12/512=2.3% 比5%小勒，在统计学上是可以忽略了。如何利用12个字节灵活的把任意数据送过去 收回来 又传发出去 又通分辨数据源 又带时间戳，真是有难度啊
听我解释一下，一般情况下，固定头部大小12个字节，体部500字节。不必要传那么多数据的时候，体部可以少于500字节，有时候要传送控制和同步等负荷信息的时候，体部也可以小于500字节，甚至没有
既然包只有512字节 那么一个大数据（8K，大约）要分好几次才通传出去了，而一秒钟又要传送好几个（8X，大约）这么多的数据，而且又要尽可能的把数据以同样的方式转发出去，数据的传送模块就要飞一样快了。
好了，现在的问题是用什么方法调用socket发送时又快又简单，切换目的地时又快又简单。
send sendto wsasend wsasendto writefile
recv wsarecv recvfrom wsarecvfrom readfile
怎么取舍，怎么框架呢，头大勒
*********希望高手指点一下************
Top
5 楼shootingstars（有容乃大，无欲则刚）回复于 2005-12-01 09:08:19 得分 0
呵呵,没有明白搂主的意思...
物理带宽只有50k，再用什么软件的方法也不可能突破50k。
当然，如果是一对多的方式的话，采用BT方式会获得更好的效果。
如果是视频或者音频业务的话，使用udp应该是更好的选择。udp确实会有一些可靠性方面的问题（当然你可以自己解决这些问题），但是视频或者音频业务更主要的是实时性，三十桢画面丢掉几桢是没有关系的。Top
6 楼vc_asm（哥俩好）回复于 2005-12-01 09:32:03 得分 0
感谢楼上的参与，非常同意楼上的看法，丢掉几桢一点关系也没有，我暂且把桢数降到8桢也没问题
关键问题是如何在50k的上传带宽和120k的下载带宽内把一个人的视频传给多个人，这个算法好难勒Top
7 楼vc_asm（哥俩好）回复于 2005-12-01 09:35:53 得分 0
因为带宽的限制，理论上只能和有限的人同时视频，哈哈，我另外想到了一个方法，就是出笼一个焦点的概念，即只有获得焦点的那个视频才流畅。Top
8 楼vc_asm（哥俩好）回复于 2005-12-01 11:34:45 得分 0
*********希望高手指点一下************ *********希望高手指点一下************Top
9 楼duyhui（一天到晚游泳的鱼）回复于 2005-12-01 11:49:51 得分 0
把一个人的视频传给多个人,这个人数有限制不?
视频数据本身就比较大,在ADSL的传输速度下，实时视频有些困难。楼主还是采用P2P的原理吧，把数据发送分配到各个客户端，减轻服务器的压力。对于速率高的客户端，可以让他多传，速率低的，可以少传或不传。客户端报告自己状态，服务器维持这个客户端列表。
数据同步就采用时间戳的方式
不过，这种状态下，能支持多少，也是个问题，毕竟网速有限啊Top
10 楼Mackz（在相互）回复于 2005-12-01 12:03:13 得分 0
考虑采用P2P的方式，现在好像有一个看电影的软件就是这样。Top
11 楼Snow_Ice11111（雪上加冰）回复于 2005-12-01 12:16:58 得分 0
呵呵，你太抬举我了^_^我是只不折不扣的菜鸟，接触VC不过半年多，这个问题刚才思考了良久，初步的想法和楼上duyhui(一天到晚游泳的鱼)大致相同，p2p的技术用在这里再合适不过了(不用太在意传输数据的可靠性；多人同时视频等等)。
-------------------------------------
关键问题是如何在50k的上传带宽和120k的下载带宽内把一个人的视频传给多个人
------------------------------------------
这个问题才是关键处，我想到的解决方法是：在视频发送时就进行抽帧处理(30多帧每秒压缩成15帧每秒左右，就算丢几帧还有10来帧)，再用p2p把数据发给各个用户。
不过上面的方法似乎你已经想到了(我暂且把桢数降到8桢也没问题)。
先吃饭去，有什么更好的想法我再发上来。
关注本贴中......Top
12 楼rabo（不哭死人）回复于 2005-12-01 13:22:35 得分 0
通过转发服务器和二级联网可以实现为服务器分流。
思想有点点类似BT，但不是BT。
模型如下：
Server
|
C1 C2
| |
C3 C4 C5 C6
| | | |
... ... ... ... ... ...
解释一下：如果Server收到了Client3的收看请求，发现请求的内容与Client1相同，于是把通道交给C1,C1把收到的数据自己先使用后，不忙丢弃，再转发给C3。这个时候，C1就想当于Server了，也就为Server分流，减轻了Server的负担。Top
13 楼vc_asm（哥俩好）回复于 2005-12-01 13:22:39 得分 0
网上那个P2Plive我用过的，好像用的是p2p的方式，效果不错，可是他们要延时几分钟才行，得，我的意思是延时不能超过1秒钟，而且是双向的勒，给人的感觉，就像打视频电话一样
桢率是可能随意控制的勒，压缩算法正在收集当中。
声音压缩打算采用 Windows Media Voice 9,只要20kbit，视频压缩打算采用Windows Media Video 9，大概要400kbit，（这是24桢的数据，估计降到8桢后会小一些）
现在最关键的问题又集中到socket的使用方法问题了，必要的时候我会用asm的，只是用哪个函数会使io操作又快又简单呢？
*********希望高手指点一下************ *********希望高手指点一下************Top
14 楼shootingstars（有容乃大，无欲则刚）回复于 2005-12-01 13:44:35 得分 0
不用在socket上打算什么....别说50kbps，就是5000kbps，瓶颈也不会在socket上啊。
再说你用asm有什么用呢？自己写网络驱动？
两个建议：
一，采用类似BT的协议方式，但是不可能到达实时效果。（最开始的第一份数据总是要通过你的50K线路传输出去的，如果一对一的方式都达不到好的效果，采用什么别的什么软件协议都不可能做到一对多）
二：如果有可能，采用多播（当然，必须所有客户的路由器支持并且可以打开才行。如果实在internet上用，就不用试验了）Top
15 楼vc_asm（哥俩好）回复于 2005-12-01 13:44:52 得分 0
感谢楼上的良苦用意，居然能够画出来。楼上的意思我理解的很哦，分流的意思我是这样想的，客户维护一个可用数据源列表A 和可用的连接列表B，当需要请求某一个数据的时候，先向A发出请求，如果A超时了（即A没有所要的数据，可能是网络变化），就向B发出请求，在B中把最先收到回应的若干成员放到A的头部，把A中的尾部成员放回到B中。
总的意思是把对象简单的分成提供者和消费者，这样可以根据需要很方便的在网络上增加/减少中转服务器。Top
16 楼vc_asm（哥俩好）回复于 2005-12-01 13:56:48 得分 0
这位仁的意思我不太明白，由于客户可能运行在不同的平台上，所以客户端要用哪一个socket是一个问题，但是服务器目前只打算用windows 2003的，所以可能会采用iocp方式的，也许客户端会用OverlappedIO了，这是对windows98用户的照顾，不知道值不值的
*********希望高手指点一下************Top
17 楼shootingstars（有容乃大，无欲则刚）回复于 2005-12-01 14:23:29 得分 0
呵呵，iocp和OverlappedIO不是什么socket，这只是一种i/o方式而已。iocp和OverlappedIO同样可以用于文件的读写。
iocp只在大量的i/o切换时才会有一定的优势。
既然是想做视频电话，就不建议采用c/s模式，本来一次能够完成的操作，非得用两次完成。Top
18 楼xiaofengxu（锋）回复于 2005-12-01 14:31:41 得分 0
Mark！
Top
19 楼hjunxu（hjun）回复于 2005-12-01 14:46:24 得分 0
楼上的这位仁兄说到点子上了，如何保证数据的正确性呢？
既然是udp，那么就不需要分包打包了，那定义的包应该是多大？既然在公网上，又要通过电话线传送，暂且 512字节/包 吧（大约）。
512 字节好小哦，怎么才能在这么小的包里面传送有用信息呢，即如何提高视频数据占带宽的比例呢？只能是尽可能降低协议的体积了，现在我曾用过一种协议，只要3 个8字节=24字节，以后我会想法子把负荷降到12字节，这样可用数据就会达到500字节勒，12/512=2.3% 比5%小勒，在统计学上是可以忽略了。如何利用12个字节灵活的把任意数据送过去 收回来 又传发出去 又通分辨数据源 又带时间戳，真是有难度啊
听我解释一下，一般情况下，固定头部大小12个字节，体部500字节。不必要传那么多数据的时候，体部可以少于500字节，有时候要传送控制和同步等负荷信息的时候，体部也可以小于500字节，甚至没有
既然包只有512字节 那么一个大数据（8K，大约）要分好几次才通传出去了，而一秒钟又要传送好几个（8X，大约）这么多的数据，而且又要尽可能的把数据以同样的方式转发出去，数据的传送模块就要飞一样快了。
好了，现在的问题是用什么方法调用socket发送时又快又简单，切换目的地时又快又简单。
send sendto wsasend wsasendto writefile
recv wsarecv recvfrom wsarecvfrom readfile
怎么取舍，怎么框架呢，头大勒
--------------------------
看不懂老兄的这个包理论啊.
这些东西和SOCKET有什么关系.
建议楼主去看一些视频的压缩协议和传输协议.Top
20 楼vc_asm（哥俩好）回复于 2005-12-01 14:59:53 得分 0
不好意思勒，可能是我没说明白勒，上面的原意就是说
通过UDP传送数据，在UDP的基础上做一个上层的视频传磅协议，这个协议负责分包解包。
而定义UDP包大小是说，不让操作系统再把要发送的包分包发送
关于压缩协议楼主已经在下文说到了，请楼上大哥仔细瞅瞅:)Top
21 楼greenabc（green）回复于 2005-12-01 15:08:46 得分 0
这么紧呀!
UDP p2p方法:
1.bt 的做法仅仅是可以借鉴一些,因为视频是流式的,是一边产生一边往外传,所以传输效率要比 bt 要低的多, bt算法在这里不能充分发挥.
2.要有成熟的 bt 代码,否则...
3.一定不能 UDP p2p 方式对多方发送,要考虑用户(发送视频的用户)带宽只有512K.
服务器转发:
这个方法比较保守,但是保险一些.
另:"目前大部分客户均是通过adsl上网的，下载速度120K左右，而上传速度只有50k左右（猜测）" 这个不是客户带宽造成的,一般是下载服务器(负担太重等原因)方的原因.你不是用过 bt吗,有的时候下载速度是不是达到 400k 以上了呢.
Top
22 楼vc_asm（哥俩好）回复于 2005-12-01 15:10:01 得分 0
这里所谓的协议体积是什么？这里所谓的协议体积是指我的UDP上层协议在网络传送中需要的带宽开销Top
23 楼vc_asm（哥俩好）回复于 2005-12-01 15:10:17 得分 0
这里所谓的协议体积是什么？这里所谓的协议体积是指我的UDP上层协议在网络传送中需要的带宽开销
*********希望高手指点一下************ *********希望高手指点一下************Top
24 楼vc_asm（哥俩好）回复于 2005-12-01 15:29:38 得分 0
楼上的是有道理的，我也希望客户下载的速度越快越好嘛，这样就有条件接收更多的视频数据勒。
只是视频源客户上传只能50k左右，肯定是不能满足每个接收方的请求了，这里我也想用一种类似上面提到过的想法，就是发送方维护一张可用接收方的列表，把最先请求数据的成员移到列表的头部，发送数据时优先满足队首成员，依次满足第二个，第三个，直到包超出了充许的时间戳。
--------------------
我一直试图在想一种方法，把公网上的服务器和客户机看成同一个角色，使用同一种协议。把整个系统看成发送方和接收方两个角色。数据就像水波一样从一个点发出，不断的扩散，直到超时为止，即超出了时间截可容忍的时间为止。(登录服务器除外)
*********希望高手指点一下************ *********希望高手指点一下************
Top
25 楼luolovegui（骆归）回复于 2005-12-01 22:59:07 得分 0
我也没有什么时间看,其实如果你要将一个数据流发到多份出去的话,用组播通信是最好的.Top
26 楼luolovegui（骆归）回复于 2005-12-01 23:04:04 得分 0
我想你的东东就是和视频会议差不多,组播是最好的,我这近本来是这是做方面的,但是时间不错,就没做什么了.
你最好用一个中间服务器.Top
27 楼luolovegui（骆归）回复于 2005-12-01 23:04:48 得分 0
才发现你这个贴子是零分的,楼主这般小气!!! :(Top
28 楼vc_asm（哥俩好）回复于 2005-12-02 07:57:06 得分 0
感谢楼上的意思，呵呵，侬可可，俺们哩哥到今天才就只油10哪。技术这个东东就是相互的嘛，只有把自己的想法说出来，才会知道这个想法的错误的地方啊。请问大哥在公网上能用组播吗。Top
29 楼vc_asm（哥俩好）回复于 2005-12-02 08:06:08 得分 0
说真的，这个贴子不要说开100分，就是100元也可以的：）只是我滴分先前散光勒，如果我是一个小气的人的话现在就不会只有10勒，只要楼上大哥有好的想法，我把分数全给你也没问题，何必在呼这个开多少分呢？你说是吧Top
30 楼vc_asm（哥俩好）回复于 2005-12-02 08:13:37 得分 0
现在公开我的计划：做这个软件，是为了方便二次开发的，是做一个控件，这个控件具备网络会议视频的所有功能，可以钳在应用程序里组成一个网络教室，也可以镶嵌在网页上，组成网上聊天室，也可以用于远程监控等等。。。
关于具体的想法是：把控件模块化，其中网络传输模块是最关心的问题，也是难题，>>>>>>希望能得到高手的指点<<<<<<Top
31 楼shootingstars（有容乃大，无欲则刚）回复于 2005-12-02 13:02:43 得分 0
搂主:
我现在还不是太清楚你的需求。
一：视频电话类
这种软件最重要的是实时性，不能我说了一句话以后，你10秒钟以后才收到，那就没有什么意义了。对于这种软件，最好采用直接通信的方式。
二：视频广播类
这种软件你可以采用类似BT协议的方式来发送视频流。但是肯定会有比较大的延时。
如果你是在专有网络中运行的话，可以采用组播方式（如果是Internet就不需要试验了，一般路由器都不会打开组播的）
如果即想做到实时性，还需要一对多的广播发送，我想目前我没有更好的建议了。（呵呵，这个好像比较困难哦，我还没有看到过在Internet上使用的网络视频会议系统）Top
32 楼luolovegui（骆归）回复于 2005-12-02 13:09:19 得分 0
shootingstars(有容乃大，无欲则刚) :: 一句话,强!!Top
33 楼vc_asm（哥俩好）回复于 2005-12-02 15:28:01 得分 0
感谢楼上猩猩大哥的指点，目前的算法和设计正在形成过成中。。。
其实我要的需求正是楼上大哥的第二条。
说的再明白些，就是做一个伸缩性极大的视频聊天室。
公网上放一台打洞服务器，即可满足最少运行需求，如果想提高性能，可能再摆放任意数目的中转服务器，这些服务器承担类似客户端的角色，加快实时数据的流通。
因为要求数据实时的，所以延时不能超过1秒钟。
跟你说，这个项目是我一个人独挑的，呵呵，希望年底搞好，明年去上海找工作勒
*****大家祝福我吧********Top
34 楼shootingstars（有容乃大，无欲则刚）回复于 2005-12-02 16:38:54 得分 0
呵呵，有难度哦。
还有你说的“公网上放一台打洞服务器”是什么意思？Top
35 楼vc_asm（哥俩好）回复于 2005-12-02 16:45:22 得分 0
哦，公网上放一台打洞服务器 是什么意思？公网上放一台打洞服务器 是说在公网上放一台服务器，这台服务器给通过Adsl拔号上网的客户提p2p打洞服务Top
36 楼vc_asm（哥俩好）回复于 2005-12-02 16:49:14 得分 0
不说了，再说谁都可以搞勒，现在有点后怕，怕我还没搞出来的时候，你们都先比我搞出来了，呵呵，希望上海公司能招聘我，我的E-mail:nrt3303@sohu.comTop
37 楼XXandOO（麦猪）回复于 2005-12-03 11:00:54 得分 0
bt的数据下载是不连续的，所以才能实现类似多用户并行下载和共享，视频是实时连续的，这就意味着自己不能为自己的服务段提供服务，因为显然你的服务端接收的数据比你多，所以，转发层次只能是树状的。楼上的srever分流的算法就是这样，但是视频如果是p2p的就要有一个针对每一个节点作为根节点的实时的树状路由算法，但是所谓的打洞服务器只能提用连接元（即通知你你有哪些点对点用户），这显然是网状的，但srever分流是树桩的，网状到树状转化？只能每个节点根据点对点客户的网速实时构建，而且网速还有时效性，要保证最佳效果的话构建好的树状拓扑不能缓存要实时更新，哼哼。。。转发分流的方式是不可取的。我看压缩算法才是关键。Top
38 楼vc_asm（哥俩好）回复于 2005-12-03 13:45:09 得分 0
感谢楼上大哥的意见，你大部分的意思我明白。我看了pplive的一些资料感觉自已的想法还是比较简单，不过如果这次成功了的话，是可以再弄的高效一些的。
可能楼上大哥还没有完全明白我的意思，现在再浅显的说一下
整个系系是这个这样的系统
.
......
..........
S...............................D
............
.........
........
..
====================================================================
. .
...... ......
.......... ............
S...............................D1..........................D2
............ ...........
......... ......
.......................D3...............
.. .
.
就是说数据源经过一段未知的网路后到达目的地，而保证实时性只是在数据上加了一个时间戳。延时的数据不再被转发。
S---->1
2
3
4
5
...
D<----1
2
3
4
5
...
S先给1发数据，发完后若还有时间就再给2发数据，直到超过延时
D先向A发请求，若超过延时没有接到回应，就向2和3发送请求，还超时就向4、5、6、7发请求。
S把最先收到请求的客户排到头部，D把最先收到回应的客户排到头部
Top
39 楼vc_asm（哥俩好）回复于 2005-12-03 13:47:49 得分 0
每个客户均当担任S和D两种角色
Top
40 楼vc_asm（哥俩好）回复于 2005-12-03 13:51:18 得分 0
D先向1发请求，若超过延时没有接到回应，就向2和3发送请求，还超时就向4、5、6、7发请求。Top
41 楼nlstone（天外流星）回复于 2005-12-03 18:18:53 得分 0
mark一下Top
42 楼wwwllg（野蛮人）回复于 2005-12-04 10:36:16 得分 0
有很多难点，非一般人等为之。Top
43 楼vc_asm（哥俩好）回复于 2005-12-05 08:03:33 得分 0
感谢楼上大哥的意见，现在算法可能就是这样勒，现在我正在弄DS，非常感谢网友的意见，我看了一下pplive的表现，决定网络方面使用tcp（控制）+udp（数据）的方式，而数据的传送方式采用select(客户端)+iocp(服务器)的方式.
**********有于经验有限，希望高人多多指点************Top
44 楼vc_asm（哥俩好）回复于 2005-12-05 08:10:27 得分 0
这位大哥，你好嘛，你说有很多难点，我也想知道将会有什么难点出来，你能指点一下吗，都说说会有什么难点嘛，我也发提前做好准备嘛
Top
45 楼vc_asm（哥俩好）回复于 2005-12-05 08:25:03 得分 0
这位大哥，你好嘛，你说有很多难点，我也想知道将会有什么难点出来，你能指点一下吗，都说说会有什么难点嘛，我也好提前做好准备嘛
Top
46 楼daixinhou（lazy man）回复于 2005-12-05 08:52:10 得分 0
Up一下Top
47 楼laiyiling（陌生人[MVP]）回复于 2005-12-05 09:08:14 得分 0
置顶Top
48 楼vc_asm（哥俩好）回复于 2005-12-05 09:12:08 得分 0
太感谢你了，我会继续弄下去的!Top
49 楼laogong165（歪锅配翘盖，好锅头有好锅盖！）回复于 2005-12-05 09:40:58 得分 0
昨天晚上的新闻联播，就有讲这样的事情。
上海的一个什么公司，已经突破了这种带宽限制，形成一个自己的视频压缩协议。
好像已经申请国际专利，部分专家认为这个协议对我们在国际视频领域占有一席之地具有重要意义。Top
50 楼laogong165（歪锅配翘盖，好锅头有好锅盖！）回复于 2005-12-05 09:45:26 得分 0
http://www.cctv.com/news/xwlb/20051204/100661.shtml
看看这个，不知道跟楼主的是不是有点相像。Top
51 楼Stefine（CSDN最菜滴猩猩）回复于 2005-12-05 09:59:04 得分 0
不是吧，那楼主可落后啦
技术上提不出什么成熟点的建议，祝福楼主吧Top
52 楼vc_asm（哥俩好）回复于 2005-12-05 10:13:27 得分 0
不要怕，先把它搞好再说。谢谢楼上的祝福Top
53 楼lmf_1（lmf）回复于 2005-12-05 11:11:32 得分 0
upTop
54 楼anjing1225（juliet）回复于 2005-12-05 11:34:11 得分 0
同样的问题关注中——Top
55 楼vc_asm（哥俩好）回复于 2005-12-05 12:09:47 得分 0
天气转冷，哥们多穿件衣服保暖啊Top
56 楼vc_asm（哥俩好）回复于 2005-12-05 12:10:08 得分 0
天气转冷，哥们多穿件衣服,保暖啊Top
57 楼vc_asm（哥俩好）回复于 2005-12-05 12:10:29 得分 0
天气转冷，哥们多穿件衣服,保暖啊Top
58 楼arvid_gs（west）回复于 2005-12-05 13:02:05 得分 0
楼主,不如我们合作开发一个项目,顺便学习一下!我做过累思的项目,!Top
59 楼vc_asm（哥俩好）回复于 2005-12-05 13:06:21 得分 0
我的QQ：4654451，具体的你加我吧。不过我是由公司支持的哦Top
60 楼mynamelj（风动,帆动,仁者心动）回复于 2005-12-05 13:09:37 得分 0
不给分的题我不回答?Top
61 楼zhenzhihy（新手）回复于 2005-12-05 19:16:27 得分 0
加我一个吧，我公司正在商量一个监控的项目，对多客户和实时要求也非常高！
估计成了，网络的就得归我！Top
62 楼lianglp（寻找黄金分割点）回复于 2005-12-06 20:30:20 得分 0
呵呵，做这个东西，难度可不小哦。。。。。。。本人的一些想法与建议：
1、应该使用p2p技术建立连接。
2、使用RTP与RTCP协议作为传输与控制协议的基础。
3、建立发送数据包长度1024byte吧。
4、如可能，仿类似BT技术吧，上边的兄弟也提到过了，在建立时，涉及到一些算法，类似运用网络递归搜索等算法。
5、发送方的视频数据发送机制。应该使用单线程数据采集与多线程发送，但这里应该使用类似建立数据发送缓冲、调度、保存等机制。在发送线程中，应使其发送线程之间最大化并行运行，这可能需要你去了解并发控制有那几类。Top
63 楼oknight（oknight）回复于 2005-12-06 21:57:46 得分 0
markTop
64 楼AntonlioX（做人要厚道）回复于 2005-12-07 22:50:40 得分 0
物理带宽只有50k，再用什么软件的方法也不可能突破50k。
这是在adsl的猫中设置的功能Top
65 楼nij_nick（阿拉）回复于 2005-12-08 13:40:36 得分 0
这个东西不管有没有人作出来了，楼主把他实现了就不用来上海找工作了，可以单干了。我给你打工。。。
本人的建议是从server上得到一张会议成员列表，并分别打洞成功，然后从a（会议发起方）对会议成员进行网速检测，得到一份从上到下的成员表，然后从a开始建立一个类似于2叉树的网络架构，网速快的始终在前面。（至于是2叉树还是3叉树，根据数据量和网络权衡而定）。
这样，每个节点就都只要负责给2个或者3个对自己来说网速最快的人的数据分发，负担应该不是很大。当然这是一种权衡的办法，是牺牲最后的人的时延为代价的。
强烈支持楼主快点实现，造福于网络数据越来越大的今天。Top
66 楼nuaawenlin（飘人）回复于 2005-12-08 14:06:15 得分 0
要想达到实时性，压缩技术是关键
对于楼主的想法，个人非常支持，但是楼主提出的启动时延为1秒钟
这个比较困难，其他软件之所以有时延，主要是采用缓冲技术
先把前几帧的数据缓冲起来，这样可以使画面比较流畅，不过实时性估计差一些
楼主可以考虑这种方法来保证图像的流畅性。Top
67 楼lzzqqq（Jonersen）回复于 2005-12-08 14:28:38 得分 0
硬件控制电路你也能突破???
那你倒不如编个程序把五角大楼的CPU烧掉算了....Top
68 楼netgm（问题多多）回复于 2005-12-09 06:14:25 得分 0
看了
CCTV的文章。。并不是对网速有突破。。是对视频压缩有突破Top
69 楼microyzy（人不在牛，分高就行；分不在高，人牛也行）回复于 2005-12-18 11:31:30 得分 0
pplive的延迟不是网络延迟产生的，应该是视频源的压缩有滞后Top
70 楼9731boy（叉叉TV - 班头爷）回复于 2005-12-20 14:43:58 得分 0
打洞的方法还是可行的。具体的可以看看ICE方面的资料.
你可以用 结队的方法，把三台左右的client组成一个队，其中有一台是master,另外的是slave，
因为有50K的带宽，每个队的数据都由master来负责发送和接收。当master出现异常时，由任意的一台的slave来顶替。
比如 A队有A1,A2,A3
B队有B1,B2,B3.
A1和B1分别是master,其他的是slave.
当A1的数据需要发给a2.a3.b1.b2.b3时，
只需要将数据发给a2,a3,以及b1就行了，由b1将数据发给b2,b3
这样的情况下可以最大化的降低一台主广播的节点的带宽，但在数据的传输上会很依赖于边缘节点的稳定性。开发上也会很复杂。 :D
另外，压缩是必需的。为了防止出现ip裂片，你需要把数据控制在1500以下，这里包括了ip头和udp还有你的数据描述的头部（比如rtp），所以数据的分包尽量控制在1024以下。
至于线程模型，我想简单的两个线程就够了，因为你的程序再快，最终的瓶颈还是在带宽上。
其实我还不是很明白你的需求。
Top
71 楼dahai_2002（ 编程浪子）回复于 2005-12-21 08:48:55 得分 0
这个话题有意思, 我曾经也有过做基于Internat视频监控的想法, 但后来失败了. 实时性不够(RTP/RTCP未使用成功). 还有就是在Internat上组播的功能得不到发挥.所有服务器的负载也比较重.Top
72 楼tccsdn（紫乐）回复于 2005-12-28 09:38:21 得分 0
学习Top
73 楼qiujun1（阿俊）回复于 2005-12-28 14:52:00 得分 0
MARK！进来学习学习Top
74 楼softrain（曾经的月光,现在的日光）回复于 2005-12-29 12:19:08 得分 0
peer与peer之间要交换数据,必须有一个相当的数据空间,数据空间越大,可以交换到数据的可能就越大.
BT下载只所以快,是因为数据空间是整个磁盘文件大小,有几百兆.peer与peer之间基本上都可以交换分片,没有实时性要求.
ppstream等p2p网络电视只所以可以在线观看,是因为数据空间有十几兆的内存,peer与peer之间基本上也都可以交换分片,但它的直播方式会造成很大延迟.
按照楼主50k的视频压缩算法,1秒的延迟,那么数据空间只有50K.如果一个包1k,也就是50片.
从一个片诞生开始,到到达每个peer,需要走过1~n次.最快是所有用户都从视频源下载,最慢是串行流过所有peer.
在tcp下,实时视频传输虽然容易控制,但速度太慢,1秒中的延迟也不可能达到,因为请求->回应->确认,需要往返3次.所以tcp不可取.
在udp下,实时传输速度快了,不过会丢包,实时性还造成有些迟到的包立即失效.
BT分片选择机制在如此小的数据空间下,从交换索引表,到请求分片,回复,到索引更新通知,这个过程需要很多时间,1秒钟的延迟根本缓存不了几片有效数据.可相互交换的有效数据就非常有限,甚至于没有.
所以,我的结论是采用bt方式不可能实现实时性,bt原理天生就跟实时性无缘.除非允许较大延迟.
大家可以想想,400比特率的电影,网络电视软件为什么搞那么大缓存?
Top
75 楼Vc_Atl（哥俩好）回复于 2005-12-29 15:29:00 得分 0
一个贴子只能回复30次，还真是不习惯，只好另申请了一个新帐号，呵呵
首先，非常感谢楼上各位的指点，你们的意见都很宝贵，再次感谢你们。
>softrain(敢笑杨过不痴情)
=================
你的理论不错，至于你认为bt不能实现实时功能，我也比较赞同。不过我现在打算采用的不是完全的BT原理，而是一种类似BT的原理，也许有可能会达到效果的，我是这样想的。
假设服务器上原来有一个群在视频，并且已经稳定，现在有一个节点要加入进来，那么，服务器在群成员列表里添加了一个成员，并把例表发送给这个节点，这个节点就得到了一个最新的关于群成员的信息，再根据我上面提到的方法来动态形成请求数据的优先队列，而其它原有节点仍然使用原有成员列表信息，只有当这个原有成员访遍了原有列表中的所有成员而仍然不能满足数据要求时，才向服务器提交请求，并报告原有列表的ID，服务器就根据提交的ID来决定是否向这个结点发送新成员列表。这样服务器也就得到了关于这个视频群的视频质量信息，并依此作为是否在公网上添加中转服务器的服务的依据。
========================
到现在为止，已经完成了对p2p的研究，才发现，要弄的，要考虑的东西是越来越多了，不过我还是不想轻易放弃这个项目。在温州就是离家近一些，搞VC却没有几个，更不用说谁会帮我一起搞了，所以我也想去上海了，但是又不忍心放弃好这个项目，虽然对公司来说并不会一搞好马上就给我带来多大的物质利益，也许是因为兴趣在作怪吧
Top
76 楼Vc_Atl（哥俩好）回复于 2005-12-29 16:36:23 得分 0
关于包头，即协议头部的体积，我已经设计好了，是一种基于概率的，长度可变的协议。大小是没有固定的，不过对于送送流数据来说，每份数据拆成若干个包后，第一个包的协议头为8字节（还是有空余的，更具体的安排还在设计中），接下来的包是4字节（已经设计好）。最大支持256条流并发传送，呵呵，之所以采用这种设计是因为，一方面迎合包头越大越小的思想，另一方面，4字节成为绝大部分包的传输协议体积，更主要的是为了加快数据向一个目的地发完后，转向另一个目的地发送的效率，并减少在此过程中修改头部信息的资源开销。因为我只要一个for(i...){...chunck[i]=(long)header...}，就可以达到切换目的地的功能。然后一个wsasendto(....)，就把数据一次性发送出去了。这会不会很爽呢：）
另外，之所以头部信息能够减少到4个字节，是因为我使用了比较多的索引，呵呵，比如，UserInTraffic[256],MemoryInTraffic[256]，呵呵，这两个就是256个成员的数组，这也是为什么一个节点同时只能支持256条流并发的原因了，不过，我相信，这个数据因该是够的，因为像QQ的话只用到了两条流（视频，音频）。而一般的视频会议同时也顶多播放10来个视频（也许用到20个流）。好了，也许看到这里你会头大，不要头大，我给你看我的4字节协议的分配:struct HEADER{BYTE bytOperation;BYTE bytUserID;BYTE bytMemoryID;BYTE bytMemoryOffset}
这里,bytOperation决定这个包的角色，功能，作用，相当于majorType，在这里取一个固定的值，表示这个包是一个数据段的一部分；bytUserID决定谁向你发了这个包，用于快速定位发给你包的节点的信息，bytMemory也是用于快速定会你要存放数据的内存的相关信息，而bytMemoryOffset就是决定，这个包在一段数据中所处的位置，这样就可以把数据安放在数据段中它因该安放的位置了。
8字节头部是这样的struct HEADERINFO{HEADER{BYTE bytOperation;BYTE bytUserID;BYTE bytMemoryID;BYTE bytReserved;LONG lnGrosslLengh}，这里前面几个不用讲了，bytReserved只是用于对齐，现在暂时不使用，lnGrossLenth用于表示数据段的总长度。
在这里你也许会问，什么是数据段？数据据段是指“比如一副图，一个0.5s的音频数据，或者一个文件”
Top
77 楼nicolas（nicolas）回复于 2005-12-30 11:00:34 得分 0
好文章,好论题!Top
78 楼bdove（鸽子情缘）回复于 2005-12-30 11:58:09 得分 0
一句话，组播比较好，目前很多软件采用这个技术！未来3g技术也将会用到这个！Top
79 楼cqgaoke（技高软件公司）回复于 2005-12-31 10:43:35 得分 0
upTop
80 楼Vc_Atl（哥俩好）回复于 2006-01-03 14:34:10 得分 0
感谢大家的支持，现在已经进入初步的协议设计阶段，有很多难点，但我仍会继续的，初步的想法如上面所说，基本不会改变，现在我打算先实现功能，再做优化，其中，实现功能时，先针对一对一，兼顾多对多情况，优先保证一对一实现代码的方法，从简单处入手设计。
在细节处可能会有些变动，但 延时少于1秒，多对多，支持256条流同时传输 的总体规划将不会改变
Top
81 楼kevinmartin（海魂）回复于 2006-01-05 10:34:31 得分 0
我尝试过了，如果通过MPEG标准库压缩过的每帧的大小在176*144下是2k多，如果采用关键帧的技术，每10帧一个关键帧，那么另外9帧的平均大小在150字节左右，这样计算下来，以15fps，不超过5k。理论上没有延时，所有的延时在于网络，晚到的时间戳就直接丢掉。Top
82 楼lisypro（）回复于 2006-01-06 15:43:23 得分 0
不可能Top
83 楼redwoodnymph（new）回复于 2006-01-07 17:00:30 得分 0
正在学习网络，学习一下Top
84 楼gogowhy（123）回复于 2006-01-09 09:46:06 得分 0
mTop
85 楼Vc_Atl（哥俩好）回复于 2006-01-09 09:56:28 得分 0
再次感谢大家的关照，现在初步框架既将形成，遗憾的是年底完的软件的目标没在实现，这其中不光有技术上的原因，还有其它一些杂七杂八的事情，如果明年我还在这家小公司的话，我一定会继续这个项目的，现在多说也不说了，下个星期开始放假，只希望在年底前把框架完成了，现在正在自定义Allocator和NetSenderFilter(Push)，NetReceiverFilter(Pull mode)（作为框架的结束）。
Top
86 楼fei1219hot（々枫/db★）回复于 2006-01-09 18:25:12 得分 0
heheTop
87 楼broccoli（-_-||）回复于 2006-01-10 10:05:49 得分 0
upTop
88 楼Vc_Atl（哥俩好）回复于 2006-01-11 11:30:11 得分 0
http://community.csdn.net/Expert/topic/4509/4509991.xml?temp=.7954065
网友一席话让我蠢蠢欲动！才1.5k工资，不干了！
年后继续找工作
Top
89 楼trueyu（两点半的苦工）回复于 2006-01-12 03:53:46 得分 0
markTop
90 楼hy1080（老神经病）回复于 2006-01-12 09:52:54 得分 0
+---------------------------------------+
+ +
+ +------------------------+ +
+ | _______________+ | +
+ | / | | +
+ | / | | +
+ | / | | +
+ | / | | +
+ |-------\ + | +
+ | \------------ | +
+ +------------------------+ +
+ +
+---------------------------------------+
计算出桌面上更改了的区域然后打成包发过去(总不至于对方在看电影吧,那样设计成两种模式好了,不过我想这种软件不会是这么用想一想这主意好象很馊,不多说了.....Top
91 楼Vc_Atl（哥俩好）回复于 2006-01-12 12:18:58 得分 0
这是最基本的压缩方法啊，相信很多压缩算法都已经考虑进去的。
======================
告诉大家一个好消息，老总和我谈话了，只要我在3个月内把服务器端和多人视频插件做出来，平均每月5K，这样的话我会继续做好的
Top
92 楼CSDNWW（中国软件WW）回复于 2006-01-15 20:52:46 得分 0
得叫他做的这三个月就每月5k!Top
93 楼sdsuper（泊舟）回复于 2006-01-16 17:36:58 得分 0
mark!@Top
94 楼XXandOO（麦猪）回复于 2006-01-17 00:00:21 得分 0
在上海北京做这个如果一个月没有10K还作个毛啊，自己辞职回家做吧，做出来如果像样的话买个100K都算是大吐血呢，呵呵。Top
95 楼XXandOO（麦猪）回复于 2006-01-17 00:03:08 得分 0
不过，能不能做出来，有没有实用性，说实话，不太乐观。。。Top
96 楼yangyangk（工兵）回复于 2006-01-17 15:34:28 得分 0
长见识Top
97 楼captainwh（wh）回复于 2006-01-19 15:04:01 得分 0
无论如何能够同时视频的数量是有限的， 首先受网络速度限制， 其次受内存限制
bt那样的办法， 对于下载这样的应用来说没问题， 但对音视频应用来讲恐怕不合适了，有一个数据实时性问题， 用其它的客户端帮忙中转视频数据， 恐怕做出来也不会有好的效果
用大带宽的服务器转发还是比较好的办法
比如可以用windows media server, 它对实时视频流数据的支持还是很不错的, 看看windows media sdk会有帮助， 省掉很多事情， 自己只要做好客户端就行了Top
98 楼Vc_Atl（哥俩好）回复于 2006-02-07 12:12:09 得分 0
大家新年快乐
难点在DirectShow模块了，弄好Filter就可以调试了，今天刚到岗，正在回顾以前的代码和思路，感觉老公司还是有点熟悉Top
99 楼candy0789（）回复于 2006-02-16 01:15:09 得分 0
哇,抛砖引玉啊~学习学习,能说说p2p跟socket的联系吗?Top
100 楼Vc_Atl（哥俩好）回复于 2006-02-16 08:15:49 得分 0
系统划分为 p2p模块,Filter模块，NetEngine模块，服务器模块，包传送增加了类似滑动窗口模型，经数据分析，可以支持15p/s的贞率。技术上已经没有问题了，现在是在开始写Filter了，公布一下我的模型，希望高人指点，谢谢
+-----+ +---------+
|filter_________ | |
| | | |
+_____+ | |
| |
+-----+ | NetEngine
|filter_________ | |.....................>NetWork
| | | |
+_____+ | |
| |
+-----+ | |
|filter_________ | |
| | | |
+_____+ +---------+
所有模块都做成COM形式，和语言形成二进制兼容，一个客户端一个NetEngine，用于和网络通信，一个媒体流一个filter并有自已的FilterGraph，每个Filter都连到NeEngine，经过NetEngine和网络通信，NetEngine支持256个Filter的连接。Top
101 楼Vc_Atl（哥俩好）回复于 2006-02-16 08:32:36 得分 0
服务器模块又细分为p2p模块，数据库模块，流控制模块，用户控制模块。。。（具体还没有设计），打算采用iocp模型，客户端采用select模型，两个filter都使用push mode，另外还要增加中转服务器，三个月的时间感觉紧紧的Top
102 楼wangk（倒之）回复于 2006-02-17 12:59:20 得分 0
晕，为什么不整理一下，放到博客上，那样也好看拉。
还有画了UML图没？Top
103 楼Vc_Atl（哥俩好）回复于 2006-02-17 13:09:37 得分 0
楼上言之有理，呵呵，就是咱的不uml不会用，用rose吗？Top
104 楼newcore（to be or not to be, it's a question.）回复于 2006-02-17 13:19:13 得分 0
一个人无论从工作量还是技术上都有难度....
LZ,搞定了还真是强
Top
105 楼Vc_Atl（哥俩好）回复于 2006-02-17 13:41:48 得分 0
其实我们公司还是蛮不错的，有宿舍住的，可惜有一个宿舍不租了Top
106 楼Hylas（羽心）回复于 2006-02-17 13:44:17 得分 0
楼主的任务现在还有人顶啊，我再顶一下。
如何才能突破50k的瓶颈呢？
回复：这个恐怕是硬件上限了，没办法了。
如果同时在线200的话大概要怎样的服务器呢？
回复：先上传再转发，这个就是一个标准的通信服务器了，看你的硬件性能，网络带宽；
还有服务器程序设计，这是最关键的。
现在我想到了另一种方法勒，就是类似QQ采取udp直连的方法。这样的话服务器只要负责打洞和登录就可以了。
回复：你让client--client ,那如果如果一边要连接20多个，那普通的pc电脑不就崩溃了吗？
当然你也可以用UDP多播。 可能通信上稍微麻烦一些。
可是这样如何把一个视频发给多个客户端呢，客户的上载速度又不能超过50k呀？
一种解决方法就是采取类似bt的做法，其它的客户端帮忙中转视频数据
这样会不会人越多视频超流畅呢，呵呵^_^
回复：不可能出现实时视频，你这个是乌托邦。
用最简单的理论，假设播放需要50k/s的流入，那整个带宽都利用起来，而且都是完美的配合起来，这才可能。Top
107 楼Vc_Atl（哥俩好）回复于 2006-02-17 13:48:15 得分 0
乌托邦? 有趣
不过我发现，现在客户已经开始用宽带了，呵呵
Top
108 楼wangk（倒之）回复于 2006-02-17 15:22:45 得分 0
回复人： Vc_Atl(哥俩好) ( ) 信誉：100 2006-02-17 13:09:00 得分: 0
楼上言之有理，呵呵，就是咱的不uml不会用，用rose吗？
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
常用的有rose、Poseidon或者UML Diagrammer都可以。
其中UML Diagrammer功能最少，不过应该是最容易用的Top
109 楼Hylas（羽心）回复于 2006-02-17 15:32:43 得分 0
客户用宽带 能有多少宽带？？？ 你试一下QQ给三个人视频看你的电脑还能处理其它的吗？
bt算法传的又不是按0---》100， 可能是100 数据先到，你能视频吗？
Top
110 楼Vc_Atl（哥俩好）回复于 2006-02-17 15:48:34 得分 0
TO：wangk(倒之)
谢谢，我有个rose破解那个相当的麻烦那,MS的Visual Modular也不好用，难学，就不学了，呵呵
TO Hylas(羽心):
客户用宽带 能有多少宽带？？？ 你试一下QQ给三个人视频看你的电脑还能处理其它的吗？
------------------------------
客户上传带宽可能有几百k吧
QQ视频其实还不是很完善，它对数据处理特占资源，这不是网络的错，而是算法不完善
bt算法传的又不是按0---》100， 可能是100 数据先到，你能视频吗？
------------------------------
最近我也刚刚对此问题想出了一个解决办法，就是类似窗口的原理，不过我只是简单的应用了一下，并经过测试，可以支持15p/s的桢率。
Top
111 楼Hylas（羽心）回复于 2006-02-17 18:17:27 得分 0
客户上传带宽可能有几百k吧----》局域网？城域网？
承认QQ不是做的很完善；用网络直播技术 采用的spring UDP多播 也许是比较现实的做法。
但主机必须要求是服务器级别的，而且带宽也不是普通用户所能达到的。
经过测试，可以支持15p/s的桢率。
局域网 吧，一个Client 吧
革命没成功，继续努力吧
Top
112 楼Vc_Atl（哥俩好）回复于 2006-02-18 08:38:03 得分 0
客户上传带宽可能有几百k吧----》局域网？城域网？
-------------
那你认为现在的宽带用户和adsl用户的上传带宽是多少呢？
用网络直播技术 采用的spring UDP多播 也许是比较现实的做法。
-------------
不知指的是什木？
经过测试，可以支持15p/s的桢率。
局域网 吧，一个Client 吧
-------------
不是的，是这样算的：设置窗口大小为一桢的容量，这样接收一桢滑动一次窗口。
在收到新桢中的任意的第一份包时开始计时，并打开窗口，在收到下一桢的任意包时重新计时，打开新的窗口。这个计时器的超时值大为桢间隔时间，如果减小超时值，一桢中的最快的一份包和最慢的一份包的到达时间差可能会超出这个值；如果增大超时值，那么次桢的包可能会在落在前一窗口内。这个窗口的最小超时值决定了视频的最大桢率，需由网络状况统计得出。
经测试在Ping 网络上的一些主机时，返回包的time间的最大时差匀没有超过66ms
1000/66>15，也就是说在现在的网络上，一份桢的所有包的最早到达包和最迟到达包的时差在66ms范围内，只要收到一桢中的第一份包，那么就可以认为在66ms后桢中的所有包都已经到达了，这样就可以以66ms的周期无缓冲的播放视频了，这个周期就是15p/s的桢率得来的缘由。
另外也可以得出，在1s的延时内，一份视频可以最多经过15个客户端，也就是说只要带宽充许，一个客户最多可以带15台另外的客户^_^Top
113 楼Vc_Atl（哥俩好）回复于 2006-02-18 08:42:09 得分 0
现在初步设计已经全部完成了，框架也已经形成了，祝贺一下^_^
我一定会继续努力的，谢谢大家，大家的关心是我的动力Top
114 楼Vc_Atl（哥俩好）回复于 2006-02-18 08:53:26 得分 0
另外也可以得出，在1s的延时内，一份视频可以最多经过15个客户端，也就是说只要带宽充许，一个客户最多可以带15台另外的客户^_^
-------------
算错了，呵呵，应该不能这样算的。在1s的延时内，一份视频可以最多经过15个客户端是对的。
一个客户可以带多少其它客户，在我的算法中纯粹由网络状况决定的:)Top
115 楼Hylas（羽心）回复于 2006-02-18 12:20:25 得分 0
做为 宽带用户和adsl用户的上传带宽 有100~120K已经是相当理想了，
如果是 用户 <----> 用户 能达到50K（普遍，或平均）我想已经差不多了
这样根据具体情况定，
比如杭州网通--杭州网通，杭州网通--杭州电信，杭州网通--新疆电信
最后一个可能是第一个的 1/20
ping 是怎么实现的？ ICMP包有多大？64字节
你的一桢有多大？不要告诉是64字节.如果超过网络MTU，你的数据会分成几次TCP发送，即使不考虑重传也是远大于ping时间。
另外根据15User一说，我打个比方，
user1--user2--user3--user4--user5
1M-100K-10K-100K-1M 上传带宽
如果中间有个环节带宽很小，比如10K, 那后面就是死蟹；
正如你说的：在我的算法中纯粹由网络状况决定的:)
我认为：你的算法在现实上是不可能的，所以别浪费太多精力了。
关于在线直播。
就是一个服务器，后面连接过来的client，就发UDP多播数据，而且数据发送都是一致的。
Client重收到完整的前几桢开始播放。
Top
116 楼Vc_Atl（哥俩好）回复于 2006-02-18 13:19:37 得分 0
ping 是怎么实现的？ ICMP包有多大？64字节
你的一桢有多大？不要告诉是64字节.如果超过网络MTU，你的数据会分成几次TCP发送，即使不考虑重传也是远大于ping时间。
-------------------------
你理解错了，给你解释一下：
我的一桢一般几K，要分几个包发送的，一般不重传的（不过，通过对ping的情况看，没响应的机率很大，很多超过10%，不知是丢包还是什么原因，如果是丢包的原因的话，那还要重传机制的，这个问题有待于进一步验证）
我知道一定有很多难点，一个是网络丢包的机率是多大，这个问题只有电信里的人最清楚了，他们才知道用的是什么设备，设备的性能参数如何，以及一些adsl厂商才知道猫的丢包机率是多大。如果问题真的很严重的话，我会考虑更复杂的处理的。
这个项目是一定要做的，人那，就要勇于挑战，那怕粉身碎骨。
现在看看我的理想的情况：
客户收到完整桢后会把数据再次“广播“给其它客户的（关于这个解释，你仔细看一下前面的老贴），这个能广播给多少客户就看这个机子的网络情况了，另外其它客户收到桢后也会广播给更多客户。
我说的一个桢能经过15个客户，是指一个桢在1S内最多可以经过15个端点，在100k网络带宽/25k数据带宽下，理论上可以把一个人的视频，在不经服务器中转的情况下和(100/25)^15=1073741824（1G！！）个人共享，呵呵！！！！
当然这个前提是：网络不丢包，每个客户上传带宽是100k,视频占的带宽是25k，贞率是15p/s，延时是1sTop
117 楼Vc_Atl（哥俩好）回复于 2006-02-18 13:23:35 得分 0
传也是远大于ping时间。
------------------------
你看不是那个时间是 Minimum - Maximum，这个时间决定桢率的，你明白了吗Top
118 楼Hylas（羽心）回复于 2006-02-18 17:58:11 得分 0
讨论了那么久 发现你很小气； 一分不给；没动力和你说了。
什么时候实现了，你传给我一份，我占点光Top
119 楼Vc_Atl（哥俩好）回复于 2006-02-21 07:59:29 得分 0
等一下开新贴送分，你一定要来哦Top
120 楼vicky_jam（★天使亲蛙☆）回复于 2006-02-22 08:47:47 得分 0
目前大部分客户均是通过adsl上网的，下载速度120K左右，而上传速度只有50k左右（猜测）
我现在要做一个视频软件，要求客户的视频数据尽可能多的发到网络上其它的客户端，如何才能突破50k的瓶颈呢？
首先硬件限制就是上传 "50k左右（猜测）" ,你要让外网的人看到你的视频,那你必须要传出一份完整的.
问题是你的上传速度只有" 50k左右（猜测）" 你应该想怎么能把一份数据快的传出去.我觉得你的瓶颈是在这里.
硬件限制着呢.
BT下载又有什么不同呢? 我觉得BT下载的话 有多个源.但是你的只有一个,而且视频数据发送一次,就废弃了.
应该考虑数据压缩,更快的传出一个数据包到外面,然后再想p2p,BT的方式.Top
121 楼shootingstars（有容乃大，无欲则刚）回复于 2006-02-22 13:12:17 得分 0
另外也可以得出，在1s的延时内，一份视频可以最多经过15个客户端，也就是说只要带宽充许，一个客户最多可以带15台另外的客户^_^
---------------------------------------------------
看似不是太可能 *_* （如果你可以做到这一点的话，做Voip设备的人就没必要混了 ^_^）
建议搂主先进性测试。。。。
ADSL的速率是你到最近的电信接入点的速率，而不是任意两个ADSL用户的速率（这两个速率有时候会相差很多）
而且下面这个理论似乎也有错误：
“经测试在Ping 网络上的一些主机时，返回包的time间的最大时差匀没有超过66ms
1000/66>15，也就是说在现在的网络上，一份桢的所有包的最早到达包和最迟到达包的时差在66ms范围内，只要收到一桢中的第一份包，那么就可以认为在66ms后桢中的所有包都已经到达了，这样就可以以66ms的周期无缓冲的播放视频了，这个周期就是15p/s的桢率得来的缘由。”
看了你的解释，仍然没有领会你的意思。
我们假设，我在局域网作测试：ping网关的返回时间是1ms（其实可能是小于1ms），那么1000/1可以得出结果是：如果使用你的程序，可以在我的计算机和网关之间每秒传输1000桢图像。。。。呵呵。。。。似乎不太可能吧。。。。
还有，按照你的算法，每秒传输的桢数似乎与视频图像的大小都没有关系了。。。这更加不符合逻辑吧。
呵呵，还是希望搂主先进性测试（比如你可以测试任意两个ADSL用户之间的传输速率。你可以写一个很简单的socket传输程序，不需要考虑iocp，其实在这种点对点的连接中，iocp不会对你的传输速率有什么影响）
然后将这个速率除以每桢大小，就可以大概估计出点对点连接的过程中能够传输的最大桢数！（注意：是最大，这已经忽略了其他因素对传输数据的影响）Top
122 楼wwwllg（野蛮人）回复于 2006-02-22 13:17:59 得分 0
vc_atl,差的是经验，并不差热情，随着时间的推移，我觉得他能把这个软件做好。
做软件，缺乏的不是经验，是热情。Top
123 楼Vc_Atl（哥俩好）回复于 2006-02-22 14:11:33 得分 0
shootingstars(有容乃大，无欲则刚) :
首先，感谢你的关注。其次，呵呵，我的确采用了点夸张的手法，之所以这样做只是想增加点人气而已，希望以此来完全否定我的项目。
这个世界是没有绝对的东西，也不可能达到完美的境介，就像我们知道物体有惯性，却从来没有物体能够无摩擦的在水平面上匀速运动过一样，显然，我也承认，达到让15p/s的一桢在1s内数据经过15个端点是非常困难的。因为：1，网络的拓朴算法如果不完美，就很难形成深度是15的树来，即使形成了，也很难稳定下来，这是其一；2，包在网络上传送需要时间，这个我上一贴把它忽略了，如果某一桢数据从一个端点传向另一个端点，最快的包也要10ms的话，那么启动定时后，要再过60ms才能停止对这个桢的包的接收，这时已经过了70ms了，1000ms/70ms<15了，这是其二。虽然事实上存在这些客观的不利因素，但却不能就因为这个而否定整个项目，因为，完美的事情不可能达到，而我们却可以让事情尽可能的接近完美，比如，通过不断的改进，一定有办法让数据通过2个端点，然后下一个目标就是让数据通过3个端点，另外，我也早已为方案增加了中转服务器，这个100来M的服务器可不是吃闲饭的:)
-------
返回包的time间的最大时差匀没有超过66ms
注意，是time间--的最大时差，比如，一个桢共三个包，从A地发到B地，第一个包用了10ms，第二个包用了12ms，第三个包用了9ms。Look，b先收到第三个包，此时已经过了9ms，然后是第一个包，此时已经过了10ms，最后第三个包，此时是12ms。B收到一个包后过了3s收到了所有的包，包间时差是3ms。
在这里我有意把包起始发送时间等同起来了，这只是为了简化考虑，因为一般一次向网络发几个包，而数目比较小时，在这里就可以把这个误差忽略掉，而在局域网内，像你说的那么快就不可能了。
-----------
每秒传输的桢数似乎与视频图像的大小都没有关系了
当然有关系，这也是像上面说的，视频的图像经压缩后，在现实里是比较小的，可以认为在60ms发送10来个包是绰绰有余的。到底能发多少是网卡的硬件电路关系。
-----------
你可以写一个很简单的socket传输程序
其实，我认为QQ已经帮我们测试过了，只要打开QQ传一下就知道了：）
---------
概估计出点对点连接的过程中能够传输的最大桢数
已经估计过了，15p/s，我打开FilterGraph，调到这个值，Preview的效果不错
如果在网络上也能达到这样的效果已经是VVVVVVVVVVVVVVeryGooDDDDDDDDD了
其实我并没有一定要实现15p/s啊什么的，我现在的目标是实现流程，只要我的数据能在我的方案中的各个模块走一遍就感到很有成就了，我开始的要求不高的
另外了很感谢wwwllg的鼓励，我们在QQ上也聊过几回的，你的的UDP可靠传输很棒。Top
124 楼Juchiyufei（三更半夜我送你回家.总统也许我做不到.今生难得的遇见你,我们就应该在一起.....）回复于 2006-02-22 15:17:41 得分 0
先记下，忙完了再看。Top
125 楼wegotnothingtolosebu（t this is a dirty joke...）回复于 2006-02-22 23:33:28 得分 0
markTop
126 楼Hylas（羽心）回复于 2006-02-23 09:58:39 得分 0
在哪开贴？？ 我来接分Top
127 楼Hylas（羽心）回复于 2006-02-23 10:07:28 得分 0
杭州网通以前有个p2p软件，很像BT，可以让杭州网通的在线用户做种子，当然是对某一个碟的下载。 它一般有个前提，是让用户先下载前10%;然后 边下载边看； 这样的用户，也为其它的用户提供数据。缓解服务器带宽。
---
其实我并没有一定要实现15p/s啊什么的，我现在的目标是实现流程，只要我的数据能在我的方案中的各个模块走一遍就感到很有成就了，我开始的要求不高的
----
我个人认为做软件，做项目；要做可行性分析。 然后是设计，最后是实现，再最后是测试。
你先把它实现了，流程是通的，但性能根本是不可能的。 你又会对项目重新（分析，你又不做这一步）设计，实现。。。。
如果一个正式的项目是经不起你这样折腾的。Top
128 楼Vc_Atl（哥俩好）回复于 2006-02-23 11:01:45 得分 0
Hylas(羽心):
新贴在这儿，快来接分吧
http://community.csdn.net/Expert/topic/4567/4567179.xml?temp=3.867739E-02
我个人认为做软件，做项目；要做可行性分析。 然后是设计，最后是实现，再最后是测试。
--------------------
是的，我之前的设计已经对其做了充分的可行性分析了，只是感觉如wwwllg(wwwllg) 所说的，经验不是很多，所以在实际的实现过程中遇到了一些困难，所以只能一方面逐步改进设计，能使其能解决新发现的问题，另一方面简化设计，以最快的速度实现一个小原型，以方便以后更改或增加。我觉的在没有做出一个看的见的东东以前，一切设想皆假想，所以打算先实现一个实物，然后再解剖这个实物，你说呢？Top
129 楼Hylas（羽心）回复于 2006-02-24 09:43:41 得分 0
说的有道理，先原形后改进；
以后碰到同类问题就会熟门熟路了。
在原形设计上，给两个建议：
1。重理论；理论上不可行的，是绝对不行的；理论上行的，实际上不一定行
2。可对某一特征进行试验。 比如1---2---3----4----5 这样测试一下1数据到5，
5收到数据是否完整，效率有多少
-----------------------------
我去接分了。
Top
130 楼Vc_Atl（哥俩好）回复于 2006-02-25 11:23:27 得分 0
是这样的，就等你了Top
131 楼tccsdn（紫乐）回复于 2006-03-03 19:58:19 得分 0
学习
Top
132 楼unionize（同盟会）回复于 2006-03-04 19:28:19 得分 0
这能行吗？Top
133 楼Vc_Atl（哥俩好）回复于 2006-03-21 16:26:25 得分 0
大家好，一段时间没发贴了，现在我报告一下进展，首先感谢wangk(倒之)的建议，现在我已经把现在的代码用uml表示了，现在打算进一步把项目用uml描述下去，感觉时间太紧了，不行了，晚上要加班了，呵，祝大家过的开心Top
134 楼gohappy_1999（碧水蓝天）回复于 2006-04-06 11:53:46 得分 0
gzTop
135 楼dirdirdir3（风）回复于 2006-04-06 13:09:40 得分 0
计算延时没有什么用的，主要是速度上面的限制，也就是说每秒能够上传的数量决定于50k/每个客户端每秒需要发送的大小。
Top
136 楼Vc_Atl（哥俩好）回复于 2006-04-10 21:38:05 得分 0
to dirdirdir3(风):
感谢你的意见，关于计算延时的问题，我的方案中是非常重要的，它不但挟带了网速的因素，还有带宽的因素。因为当某个客端的带宽大时，他可以直接把数据发向更多的下行客户端，这样就可以减少数据被中转的次数，也就减少了延时，因而数据可以被传播的更远，更广，而当客户端的带宽小时，他只能把数据直接发给比较少的下行客户端，这样就会增加数据的中转次数，因而减少传播的"面积"。控制延时直接的控制了数据通过客户端树的层数，间接的反应了客户端间的带宽状况。
现在我的项目现在暂时搁置了，经过空闲时的思考，可以认为在1to1的时候媒体数据不需要通过服务器中转，在1 to n的时候，中转服务器可以保证更好的用户体验，在中转服务器的参与下，客户树的层次在2层左右就可以大大的减轻了中转服务器的负担，而理论上却可以达到15层(在15fps的情况下)(只要算法绝对好），说明方案的伸缩性还是极强的。在客户端的组织中(插入，查找），增想过是用红黑树还是平衡二叉树的问题，发现两个各有利弊(红黑树操作次数少，但实际上和后者一样系统对删除时间要求不紧迫)，不过估计性能均会远远超过其他的数据结构。另外在有限的带宽下对如何保质音频，牺牲图像桢数是个非常头疼的问题。我想了很多方案，有些方法非常复杂，而效果却又难以验证，这也许是水平有限吧，现在我想到了一个相对简单的一点的方法了，但细节上处理起来也是比较难的（感觉太抽像），总的来说，就是建立流的优先级，让高优先级的数据先放到网络上，另外，对流的属性加上一个保质的可选项，即根据音频数据量相对视频小的特点，增加重传的机制(或者说增加重传的次数--空间)。
------------
希望高手能够多多提错误，惭愧 = =!Top
137 楼Vc_Atl（哥俩好）回复于 2006-04-12 14:08:38 得分 0
现在我打算使用stl来了，不知道自已写好还是stl好，特别是服务器端内存管理那一块，本来是一次申请多次使用的，现在如果使用了stl就把内存管理交给stl了，也好，自已省了很多心，也少去了不必要的调试，呵~~~打算客户端也用stl了，到时候再看看，遂步改成自的手工的数据结构，呵~~~~如果一切顺利的话项目要快很多了！：DTop
138 楼zhangqu_980371（能坚持一辈子的东西太少）回复于 2006-04-12 18:38:34 得分 0
的确欠缺的是经验，热情劲打，一直能坚持就好，系统想得太复杂，可以活动脑筋，热情高，可以补充知识。复杂的系统要形成产品化和后期维护改进都是几何级数的。典型的程序完美主义。
Top
139 楼lfchen（一条晚起的虫--床上用品[家纺]专卖）回复于 2006-04-12 18:41:17 得分 0
markTop
140 楼CUG122032（烫烫烫烫烫烫?烫烫烫烫烫烫烫烫烫烫烫烫烫烫烫烫烫烫烫烫烫烫烫烫烫烫烫?烫烫烫烫烫烫烫烫烫烫烫烫烫烫烫）回复于 2006-04-12 19:04:09 得分 0
其它大家不要说什么P2P了,P2P是最费带宽的.
如果单纯的追求对用户带宽的节约,那最好的办法就是服务器<-->用户{1,2,....}这种办法了.
因为它把带宽的压力全放在服务器上面了.Top
