DELPHI盒子
!实时搜索: 盒子论坛 | 注册用户 | 修改信息 | 退出
检举帖 | 全文检索 | 关闭广告 | 捐赠
技术论坛
 用户名
 密  码
自动登陆(30天有效)
忘了密码
≡技术区≡
DELPHI技术
移动应用开发
Web应用开发
数据库专区
报表专区
网络通讯
开源项目
论坛精华贴
≡发布区≡
发布代码
发布控件
文档资料
经典工具
≡事务区≡
网站意见
盒子之家
招聘应聘
信息交换
论坛信息
最新加入: 123glimmer
今日帖子: 20
在线用户: 14
导航: 论坛 -> 网络通讯 斑竹:liumazi,sephil  
作者:
男 ww1000 (Delphis) ▲▲▲▲△ -
注册会员
2021/3/20 23:39:35
标题:
请问:2个不同城市的内网PC与服务器通讯后,可以脱离服务器后2地PC互相通讯吗? 浏览:1025
加入我的收藏
楼主: 请问:2个不同城市的内网PC与服务器通讯后,可以脱离服务器后2地PC互相通讯吗?

现在不同城市的内网PC只能通过独立IP的服务器转发通讯吗?
如2台PC进行复制文件,是否所有流量必须经过服务器转发?

不是很懂网络通信,希望各位有经验的指引一下如何用Delphi实现。。。感谢。。。
----------------------------------------------
阳光总在
作者:
男 emailx45 (emailx45) ▲▲▲△△ -
注册会员
2021/3/20 23:53:23
1楼: hi ww1000

为了使设备彼此通信,需要有一种“装置”来使之发生。
因此,有必要具有“手段”,通常是通信网络,无论是物理的还是逻辑的。
当两个设备在通信网络中进行“登录”时,很可能会存储它们的联系数据,即每个设备的其他信息(例如网卡,操作系统等外围设备的特性)。如果未执行用于远程访问的策略安装,则通过其他方式(例如,如果设备连接到任何其他通信网络并尝试查找旧服务器)(例如,当设备被病毒感染时的操作) ,那么,如果存在某种“手段”,则这两个设备只能相互接触。
如果没有“单向”(物理或逻辑上连接两个设备的另一种方式),则无法在两者之间建立连接。
除非“天上的手段被用来创造奇迹”。

总结:两个或多个设备必须存在一种连接和交换信息的方法。否则,就没有办法。

想象一下:您是如何与这个论坛取得联系的?是从头开始的,还是您必须访问电子设备,并且该设备必须先连接到通讯网络,然后找到论坛,然后登录,然后写您的帖子?

你明白这条路吗?
----------------------------------------------
The higher the degree, the greater the respect given to the humblest!
作者:
男 scarlette (Scarlette) ★☆☆☆☆ -
普通会员
2021/3/21 1:59:24
2楼: 如果是IPv6,可以。如果是IPv4,常规来说需要至少有一端是公网IP地址,并且通常要在网关处配置端口转发或者支持uPNP。
----------------------------------------------
-
作者:
男 3dhot (3dhot) ★☆☆☆☆ -
普通会员
2021/3/22 10:07:57
3楼: 楼主可以参考一下开源的N2N,https://github.com/ntop/n2n   理论上来说,n2n通过UDP方式打通隧道后两台电脑之间的流量是不走服务器的。
----------------------------------------------
-
作者:
男 wang_80919 (Flying Wang) ▲▲▲▲▲ -
普通会员
2021/3/22 10:09:25
4楼: 楼上的就是 NAT 的意思吧。
NAT 是有类型的。听说的有的类型 是无法 连接的。
----------------------------------------------
(C)(P)Flying Wang
作者:
男 3dhot (3dhot) ★☆☆☆☆ -
普通会员
2021/3/22 10:13:32
5楼: 对,有部份NAT无法成功打洞,但常规的很多实际还是可以打通的。看雪出的KSA打通成功率就很高,一但打通后流量就不需要走服务器转发了。
----------------------------------------------
-
作者:
男 wang_80919 (Flying Wang) ▲▲▲▲▲ -
普通会员
2021/3/22 10:23:30
6楼: 求一套 PASCAL 的 NAT SDK开发组件。
----------------------------------------------
(C)(P)Flying Wang
作者:
男 pcplayer (pcplayer) ★☆☆☆☆ -
普通会员
2021/3/22 21:52:24
7楼: 楼主,你的问题,解决方案是 P2P;

所谓 P2P,就是两台电脑【点对点】直接连。

但目前我们的问题是,两边都是在内网,也就是电脑只有私网 IP,出口公网可能是一个路由器。理论上的解决方案包括:

1. 设置路由器,打开路由器端口映射,将路由器的某个端口,映射到内网的某个 IP 、 PORT  上。这样做外网就能直接访问你的路由器的公网IP+你打开的映射端口来访问你的内网电脑。但这样做,用户必须会设置路由器。不同的路由器设置界面也不同,因此无法大规模推广。

2. 用程序设置路由器。网络协议里面有一个协议叫做:UPnP 协议。这个协议用于内网的设备发现和控制。比如用这个协议发现打印机。也可以发现路由器,并向路由器发命令让它打开某个端口映射。网上也有 Delphi 代码的 UPnP 控件。这样做的好处是程序完全自动控制,无需用户干预,也无需用户懂得路由器设置。问题是各种路由器对 UPnP 的支持可能不一样,不能百分百成功。

3. 自己用代码尝试打通 NAT,也就是 NAT 打洞。UDP 打洞只能是 UDP 通讯。原理是利用一个有公网 IP 的服务器,两边在没有建立直接连接前,通过这个中间服务器转发通讯。比如通过这个中间服务器查询对方的 IP 地址以及当前的端口号,然后直接向这个 IP 和端口号发 UDP 包。至于对方为啥是这个端口号?原理是某些 NAT 路由器当内网的某台电脑向外发送 UDP 包的时候,NAT 路由器会为它保持一个开放的端口,让外面回送的 UDP 包能够返回到该电脑。
3.1. 这个方法,打洞不能百分百打通。原因之一是某些路由器的 NAT 的工作模式不支持这种打法。另外一个原因是,可能有一些内网电脑是在两层或多层路由器底下。比如现在安装的电信的 ADSL,电信给你的 IP 地址可能本身就不是公网 IP,也就是电信那里有一个路由器,然后你再加一个路由器,那这个打洞就很难了。
3.2. 实在打不通的,就必须通过有公网 IP 的中间服务器转发。
3.3. 上述自己打洞的办法,没有网络通讯协议标准,各家有各家的代码和算法,都是私有的。
3.4. 还有个问题,因为 NAT 打洞是走的 UDP,而 UDP 通讯是不可靠的,可能丢包,也可能收到的顺序和发送的不一致。在不允许丢包的场合,比如拿来传文件,或者做视频直播,就要自己想办法写一些代码来保证。针对这个问题,目前网上也有一些开源代码,不过就我自己能找到的,测试下来,没有靠谱的。可能靠谱的人家没有释放出来?

4. 当当当,现在有了一个开源的新的标准:WebRTC 这个玩意原本是 Google 开发的,现在开源了,而且进了 W3C 标准,这个玩意主要用来做视频会议什么的,它的通讯层就支持 P2P,如果用它,大概自己就不用去了解打洞如何做之类的事情了。但我搜了一下, Delphi 的代码支持 WebRTC 的开源代码或者控件,似乎还没有。这个玩意厉害在 Chrome 浏览器内置支持了,你做的东西,浏览器可以直接访问。


所以各位玩 Delphi 的童鞋,尽量想办法在 Delphi 上把 WebRTC 用起来吧。开源的代码是有 C 代码的。这个 WebRTC 从网络通讯的角度来看,会带来很多新的应用和新的机会。
----------------------------------------------
-
作者:
男 txdy2010 (潜龙出海) ▲▲▲▲△ -
注册会员
2021/3/22 21:53:57
8楼: QQ是怎么作到的呢
----------------------------------------------
-
作者:
男 pcplayer (pcplayer) ★☆☆☆☆ -
普通会员
2021/3/22 22:00:13
9楼: 上面我写了那么多原理性的东西。这里说一下实践:

我在04年左右,用 Delphi 写了一套 P2P 的东西,实现了:
1. NAT 打洞;打不通就转发;
2. UDP 的可靠性传输,我当时命名它为 UDP over TCP,因为我采用了 TCP 的算法原理。

工作起来也还算可靠。当然也有很多问题,但至少是能用的。去年我在这里发贴说准备把那套当年卖钱的玩意,改改好,开源出来。然后开始动手做,然后发现当年的架构不对,基本上要彻底重构。开了个头,然后有别的要吃饭的事情一忙,这个事就放下了,推进的进展不太好。

现在有了 WebRTC 我就要考虑当年我做的那个玩意还有没有必要拿出来费时间优化?毕竟 WebRTC 是网络标准协议而且有 Google 这样的大佬在搞并且开源,肯定比我的破代码强一万倍。
----------------------------------------------
-
作者:
男 wr960204 (武稀松) ★☆☆☆☆ -
盒子活跃会员
2021/3/23 0:26:01
10楼: NAT实际上UDP,TCP都行。
另外据腾讯的员工说,QQ实际上传输文件的时候,大多数都不是点对点的,因为打洞失败,大都是走服务器的
----------------------------------------------
武稀松http://www.raysoftware.cn
作者:
男 nevergrief (孤独骑士) ★☆☆☆☆ -
盒子活跃会员
2021/3/23 6:36:37
11楼: to pcplayer
等你的项目开源等了1年多,都没有结果呀!能不能发上来啊?你没时间优化,我们有时间。项目最难的就是原创性,诺贝尔奖就是授予原创的那个人,而不是那些发扬光大的人。具体参考一下屠呦呦的例子,她打开了治疗抗疟药这扇大门,搞笑的的是她自己却没有能够挤进去,但是不好意思,诺贝尔奖还是她的,而不是别人的。你的功劳和水平是任何人都不能否认的,捂嘴笑。。
----------------------------------------------
只有偏执狂才能生存!
作者:
男 nevergrief (孤独骑士) ★☆☆☆☆ -
盒子活跃会员
2021/3/23 6:41:04
12楼: 当然,改成卖钱的控件也不错,这样您也更有动力去改进和维护,能取得双赢的结果。再加上一点情怀,这件事情就算不亏了。
----------------------------------------------
只有偏执狂才能生存!
作者:
男 dbyoung (dbyoung) ★☆☆☆☆ -
普通会员
2021/3/23 9:17:26
13楼: 我的机器是双网卡。
用 QQ 传文件(在线模式):
当我的IP和同事的电脑(A网卡),是在同一网段的时候,100M文件,5秒钟就能传完 (点对点传输)。
当我的IP和同事的电脑(B网卡),不在同一网段的时候,100M文件,5分钟才能传完 (服务器转发)。

由于国内网络的复杂性,打洞大概率会失败。不具有通用性。学习技术是可以的。
qTox 在国内也被封了,科学上网后才可以用。也不具有通用性。
要想具有通用性,好像只能是服务器转发。

一直想做个远程工具,放到软件中。当客户现场出问题时,可以直接远程,而不用使用第三方远程工具。
一直没时间弄。也没有想到好的解决方案(非服务器转发模式)。
----------------------------------------------
武汉天气不好
作者:
男 jackalan (nVicen) ★☆☆☆☆ -
盒子活跃会员
2021/3/23 9:24:05
14楼: 其实不管你打洞技术有多高,必须有中间的公网IP的服务器做最基础的信息交换,否则谈何打洞,现在QQ那些除非一端是有公网IP的,否则大多情况还是经过服务器中转。

WebRTC的解决方式是通过ICE (Interactive Connectivity Establishment) ,交互式连接建立,是一种NAT穿透的框架,它集成了多种NAT穿越技术,比如STUN、TURN。也同样是让双方直接建立连接。然而,在某些情况下,两台主机无法直接通信,此时,WebRTC也是借助中间代理进行间接通信。

STUN(Session Traversal Utilities for NAT)
STUN(Session Traversal Utilities for NAT),NAT会话遍历实用工具。名字有点拗口,主要用途如下:

检测分配给主机的外网IP和端口;
检测NAT类型;
检测两台主机之间的网络连通性;


确认外网IP和端口
STUN是C/S架构,实现这点相对简单,跳过协议细节,流程大致如下:

主机向STUN Sever发起地址查询请求;
请求数据包穿过NAT到达STUN Server。
STUN Server收到请求,获得请求的来源IP、端口;
STUN Server发送响应,响应数据包里包含了上面的来源IP、端口;
响应穿过NAT到达终端,终端获得自己的外网IP、端口;


检测NAT类型
NAT主要分4种类型:Full Cone、Restricted Cone、Port Restricted Cone、Symmetric。

这4种NAT类型的主要差异,体现在对UDP数据包的处理上,以Full Cone、Restricted Cone为例:

Full Cone:全锥型,任意来自相同内网IP、端口(IP_A、PORT_A)的请求,都会被映射到相同的外网IP、端口(IP_B、PORT_B)。此外,任意外网主机可以通过向IP_B、PORT_B发送数据包,来向内部主机发送数据包;
Restricted Cone:受限锥形,跟全锥形类似,任意来自相同内网IP、端口(IP_A、PORT_A)的请求,都会被映射到相同的外网IP、端口(IP_B、PORT_B)。不同之处在于,假设外网主机的IP地址是X,只有当内网主机曾经给IP地址X发送过数据包,该外网主机才能给内网主机发送数据包;


如何检测NAT类型呢?

假设STUN Server有两对公网IP、端口(IP_1 + PORT_1、IP_2 + PORT_2),假设内网主机(IP_A、PORT_A)向STUN Server的IP_1、PORT_1发送数据,STUN Server通过IP_2、PORT_2向该内网主机发送数据,那么:

Full Cone:内网主机可以收到数据;
Restricted Cone:内网主机收不到数据;


最后!!!连通性检测
连接双方获知自己的IP地址、端口(可能有多对,比如内网地址+内网端口、外网地址+外网端口)后,通过信令服务器告知对方。剩下的工作,就是连通性检测:

双方是否有可连接上的IP地址、端口对;
哪个IP地址、端口对的通信质量最好;


TURN(Traversal Using Relays around NAT)
TURN对STUN进行了扩展,主要增加了中继服务器,说白了就是中间的代理。
----------------------------------------------
简单做人,认真做事。
作者:
男 littlestone08 (littlestone08) ★☆☆☆☆ -
普通会员
2021/3/23 13:14:00
15楼: 好多总结性的发言
----------------------------------------------
我和我追逐的梦,擦肩而过
作者:
男 pcplayer (pcplayer) ★☆☆☆☆ -
普通会员
2021/3/23 18:17:33
16楼: @nevergrief  我原来的那些代码太烂了,拿出来展示很丢人啊。

@jackalan  你写的这些,把 NAT 如何打洞的原理写得很清楚了。但如果用 Delphi 来实现,似乎目前为止也没什么很好的开源代码。当然,当年我也实现过,不过代码比较烂,打通率在复杂的网络条件下也不行。反正打不通就中转啦。

我相信,WebRTC 怎么都比我写的强一万倍。所以,我还是想在 Delphi上有机会把 WebRTC 用起来。
----------------------------------------------
-
作者:
男 pcplayer (pcplayer) ★☆☆☆☆ -
普通会员
2021/3/23 18:22:18
17楼: @wr960204  TCP 确实理论上也能够打洞。也有相关的一些文档。但目前为止我能找到的 TCP 打洞的开源代码,都不靠谱。不知道有厉害的实现没有。

至少,目前市面上,商用的一些 P2P 库,都是在用 UDP 在跑。

至于 QQ,当年我做 P2P 通讯的时候,也抓过 QQ 的包来分析:
1. QQ 发文件是用 UDP;
2. QQ 的 UDP 尽量不做流控,狂抢流量。类似的狂抢流量,当时国内的好多网络软件比如 pplive 等等都是这样。

TCP 协议就是类似大家开车的有个共识,堵车时,大家都慢点走不要抢道,这样大家虽然走得慢,但每个人都能很顺畅的走;

而国内的这帮软件包括 QQ(现在如何我不知道,我说的时当年抓包分析它时),类似开车的时候每个人都往前抢道,不管别人死活,结果就是导致整个局域网的出口路由器被堵塞,丢包严重。
----------------------------------------------
-
作者:
男 ww1000 (Delphis) ▲▲▲▲△ -
注册会员
2021/3/24 20:44:51
18楼: 谢谢各位的总结,

如果不同城市pc复制文件都经过服务器,那服务器的带宽负担非常大吧
----------------------------------------------
阳光总在
作者:
男 bigboy2050 (bigboy2050) ★☆☆☆☆ -
注册会员
2021/3/25 11:31:00
19楼: 进来看大佬。。。
----------------------------------------------
http://www.kittyapp.net
作者:
男 yesin119 (yesin119) ★☆☆☆☆ -
盒子活跃会员
2021/3/25 15:07:12
20楼: 期待 pcplayer (pcplayer) 的观点,希望能有更多人研究  WebRTC !做个Delphi能用的库或者组件
----------------------------------------------
-
作者:
男 142857 (142857) ★☆☆☆☆ -
盒子活跃会员
2021/3/25 15:38:32
21楼: WEbrtc 
商业上:
https://www.esegece.com/websockets
http://www.flashavconverter.com/content/webrtc-delphi-component
客户端
https://www.tmssoftware.com/site/blog.asp?post=661

开源客户端:
https://github.com/Zeus64/alcinoe
WebRTC Delphi wrapper
WebRTC (Web Real-Time Communications) is a technology which enables Web applications and sites to capture and optionally stream audio and/or video media, as well as to exchange arbitrary data between browsers and mobile applications without requiring an intermediary. The set of standards that comprises WebRTC makes it possible to share data and perform teleconferencing peer-to-peer, without requiring that the user installs plug-ins or any other third-party software.

TALWebRTC component makes it easy to add video and audio chat into your applications, which opens up a whole new world of interactivity
----------------------------------------------
dddddd
作者:
男 ww1000 (Delphis) ▲▲▲▲△ -
注册会员
2021/3/25 21:37:21
22楼: WebRTC 看上去好像还是服务器中转,这样服务器的带宽要求很高吧
----------------------------------------------
阳光总在
作者:
男 pcplayer (pcplayer) ★☆☆☆☆ -
普通会员
2021/3/25 23:38:52
23楼: WebRTC 据我所知,是尽量打洞,能打通的,就直接 P2P 了;打不通的,那只能服务器中转。

当然,打通率如何,是否还有比 WebRTC 打洞的打通率更高的代码?反正开源的代码我没见到。如果有估计也是商业代码,不公开。
----------------------------------------------
-
作者:
男 hawke2e (hawke2e) ▲▲▲▲▲ -
注册会员
2021/3/26 10:26:23
24楼: 比特币是怎么实现的??

你们的讨论都忽略了一个关键因素:墙的存在。
假设境内主机发送出去的每个IP包(IP层)都必须先转发到某个机构审查,经过这机构允许后才能继续后续的网络传输
假设这传言是真的,互联网IP层当初设计有个前提:互联网里不存在封锁,所以两个节点在IP层的传输路很多,这条路不通只要有其它路通就能送达。
然而,墙的存在令这前提不成立,影响波及建立在IP层上的网络层。导致:
1. 你们上面说的打洞打不通,你无法分析出是NAT的不支持还是墙的原因
2. 两个节点之间的通讯,或许昨天一切正常,今天就无法访问,明天又通了但断断续续。这种现象完全可能。

原因很简单,必定存在大量IP包,墙既不能判定允许通过,也不能判定不允许通过。怎么办? 这里就有很大的人为控制了,乱七八糟。

社会付出大量成本这是一方面,更重要是墙会扼杀通信方面的创新,从而遏制了中国互联网的发展。
若干年后,网外区块链已经非常成熟,但我们仍旧使用着陈旧的商业模式。
打个比喻,人们的书信往来都必须经过审查,有时候,我们沟通的东西不希望给第三方知道,那就加密,但有关机构审查不了阿,怎么办?
加密后的书信就不准往来或往来困难,时间一长,结果就是只有他们希望的通信方式才能存在。

水至清则无鱼,当规则含混不清时,就很难判断是非了,你能判定打洞不通是不是因为墙? 墙存不存在你都判定不了。
----------------------------------------------
软件是什么,相信很多人都说不清。
作者:
男 hawke2e (hawke2e) ▲▲▲▲▲ -
注册会员
2021/3/26 10:38:29
25楼: 连通过HTTP HTTPS访问失败的失败原因都分析不出来。
还想在技术上解决打洞问题,如同浮沙建城,你骗我我骗你。
----------------------------------------------
软件是什么,相信很多人都说不清。
作者:
男 yesin119 (yesin119) ★☆☆☆☆ -
盒子活跃会员
2021/3/26 11:54:13
26楼: 我觉得技术未必百分百完美才值得研究,研究的意义就是让技术解决某种难题,并且趋向于更可靠。
我目前使用frp外挂来解决外网链接内网。有很多问题,但大部分客户也能接受那些问题。我不知道 pcplayer (pcplayer) 大侠说的WebRTC 是否完美,但是越研究,研究的人越多,才会有更多解决方案。
----------------------------------------------
-
作者:
男 last_exile (last_exile) ★☆☆☆☆ -
盒子活跃会员
2021/3/27 9:37:42
27楼: 看看zerotier
----------------------------------------------
我的论坛
http://zsnet.kmip.net/phpbbs
作者:
男 dbyoung (dbyoung) ★☆☆☆☆ -
普通会员
2021/3/27 11:29:01
28楼: 都一样的。没有什么新鲜玩意。
能打洞就打洞,不能打洞的,就走服务器转发。当走服务器转发时,速度就慢了。

今天查看了一下我自己家的宽带公网IP,居然是固定IP。还是电信网好呀。
----------------------------------------------
武汉天气不好
作者:
男 terony (圣光) ★☆☆☆☆ -
盒子活跃会员
2021/3/27 19:08:23
29楼: PC与PC之间“通话”,目前都是需要服务器的。
P2P软件也都是有服务器的,并不会真的脱离服务器。
大家提到腾讯,腾讯当然是用服务器的。
做成熟的商业产品,无论技术实力再好,也需要服务器。
两个单纯PC之间,可以打通,但是很有可能不稳定。
只是单纯研究如何脱离服务器去进行PC到PC的互联,意义不大,即使作为个人兴趣。
----------------------------------------------
-
作者:
男 dbyoung (dbyoung) ★☆☆☆☆ -
普通会员
2021/3/27 21:51:55
30楼: 楼上错了,意义不是不大。是很大很大。
只是ZF不允许你们这么干。

但正如 hawke2e 大侠所言,因为有墙的存在,基本上不可能出现完美的P2P。
ZF岂不是监控不到了一切了吗?你们这些刁民此不是无法无天了吗?
现在满大街的摄像头,人脸识别,还不知道这是为什么吗?
你以为南上必胜客是那么容易赢得所有官司的吗?

都知道现在中小学课本中鲁迅的文章删除了,添加了一些三字经百家姓此类的文章吧。
思考一下为什么删除了?鲁迅的文章说了什么?
官方的理由是不符合现在和平社会了。反过来看,是不是说,它更符合现代社会呢?
现在推行的是什么教育?
你知道他们在担心什么,怕什么了吧。
教育一旦落后,那可是一代人,几代人。
教育落后,科技必落后,迟早是要被打的。
----------------------------------------------
武汉天气不好
作者:
男 a5824 (Return) ▲▲▲▲▲ -
注册会员
2021/3/27 22:07:34
31楼: 你们这么说话,没把你们抓起来??好好的技术贴,动不动就来带节奏,看着真让人恶心。居心叵测。
----------------------------------------------
-
作者:
男 iamdream (银河恒久远,梦想无止境!) ★☆☆☆☆ -
大贡献会员
2021/3/27 22:17:55
32楼: 没事扯那么多干吗?想让论坛关闭?晕……你以为霉国没墙?嗯,人家需要的时候直接封掉你。
----------------------------------------------
-广袤璀璨的银河,永无止境的梦想(梦无止境游银河) 博客挂了……
作者:
男 dbyoung (dbyoung) ★☆☆☆☆ -
普通会员
2021/3/27 22:29:34
33楼: 我没有带节奏。也没有居心叵测。只不过说了事实。
如果让你感到恶心了,非常对不起。
----------------------------------------------
武汉天气不好
作者:
男 jackalan (nVicen) ★☆☆☆☆ -
盒子活跃会员
2021/3/29 9:40:48
34楼: @dbyoung 你把你家猫或者路由重启,你就不是固定IP了。
----------------------------------------------
简单做人,认真做事。
作者:
男 wang_80919 (Flying Wang) ▲▲▲▲▲ -
普通会员
2021/3/29 12:52:16
35楼: 部分支持 32楼。
但是 有些技术网站,我还是希望不要墙。
有些技术网站,是直接打不开。
有些是偶尔打不开。
比如 github ,就是 偶尔打不开。
----------------------------------------------
(C)(P)Flying Wang
作者:
男 wang_80919 (Flying Wang) ▲▲▲▲▲ -
普通会员
2021/3/29 12:54:53
36楼: kad dht
是目前最好的 P2P 技术。而且还是开源的。你们谁打算去学?
区块链,只是 加密的 p2p 技术。
----------------------------------------------
(C)(P)Flying Wang
作者:
男 sczhyq (旺财) ▲▲▲▲▲ -
注册会员
2021/3/29 16:19:30
37楼: 听人说采用TCP打洞技术可以
----------------------------------------------
我84砖家
作者:
男 pcplayer (pcplayer) ★☆☆☆☆ -
普通会员
2021/3/29 23:27:45
38楼: P2P 采用 UDP 打洞使得两个节点直接直接通讯,实在打不通,才通过服务器转发。当然,打工过程中需要服务器协助,但一旦打通了,流量就是两个节点之间直接走了,不通过服务器了。

29楼说没有意义,只能说对这个世界不了解。

P2P 的意义非常大。简单说,跑视频,如果全部从服务器转发,流量成本非常高。因此,为了节约流量成本,在很多应用场合,是尽量建立 P2P 通讯的。当然为了保证通讯建立,打不通的,必须转发。

在真实世界,提供 P2P 解决方案(节点算法,转发服务器等等)的软件公司甚至做到了上市。你说有没有意义?
----------------------------------------------
-
作者:
男 hawke2e (hawke2e) ▲▲▲▲▲ -
注册会员
2021/4/5 14:06:23
39楼: 同意楼上。
不过,对于非阿里腾讯这些的公司来说,P2P应用的障碍就是《wangluo安全法》。
打个比喻,好比,你出租房子,如果租客zhi毒或者卖Y,你也得担责任;这很不合理,有句话叫不知者不罪,你得有证据证明房东知情才能向房东追责吧;
现在是如果你搭建P2P,因为没有服务器,别人在上面做违法的事情,你无论知不知情都得担责任。
请问你们有没有想到能规避这法的好题材??你用WEBRTC搞了个文件分享系统,哪天搞得成规模了,别人就在上面贩huang,结果你也得进去,怎么搞?

墙的本质就是遮羞布遮不住露出来的丑陋,什么丑陋就不细说了。
一项政策往往有好的一面同时又有不好一面,所以仅仅从政策本身来讨论好坏是没有结果的,
就像封国民的口,肯定有好处也有坏处,仅仅从这件事本身来讨论只会落得个公说公有理婆说婆有理的结果;
关键在于政策是否体现大多数国民的意志,如果是,则小数服从多数;
如果不是,请参照隔壁的缅甸和俄罗斯,最典型就是朝鲜,一片和谐景象。
----------------------------------------------
软件是什么,相信很多人都说不清。
作者:
男 zwjchinazwj (蒲石) ★☆☆☆☆ -
普通会员
2021/4/6 13:04:54
40楼: "关键在于政策是否体现大多数国民的意志,如果是,则小数服从多数;"

每人发印发100万人民币, 你估计大多数国民是赞成呢,还是反对呢?
----------------------------------------------
-
作者:
男 zyp1984 (小李他妈的飞刀) ★☆☆☆☆ -
普通会员
2021/4/6 17:08:05
41楼: 赞成楼上:大多数人往往不见得是正确的。
----------------------------------------------
山外青山楼外楼,能人背后有能人弄..
作者:
男 wang_80919 (Flying Wang) ▲▲▲▲▲ -
普通会员
2021/4/6 18:17:57
42楼: 把老外的丑陋都遮起来,大家还以为老外都是好人呢。
----------------------------------------------
(C)(P)Flying Wang
信息
登陆以后才能回复
Copyright © 2CCC.Com 盒子论坛 v2.1 版权所有 页面执行31.25毫秒 RSS