evilpan/p2p-over-middleboxes-demo

A simple demo of P2P communication over middle boxes such as NAT

P2P-Over-MiddleBoxes-Demo

一个简单的P2P通信示例

English README

p2pchat

一个P2P聊天程序，使用UDP打洞创建链接。

编译

make p2pchat

运行

./p2pchat/server <服务器端口号>

./p2pchat/client <服务器IP>:<服务器端口号>
>>> help

测试：

编译

make test

运行

./run_test.sh

常见问题

通信不正常/打洞不成功？

该UDP打洞示例仅支持锥形地址转换器（Cone NAT），如果两个客户端都在同一个公网结点下，需要确保出口路由器支持回环传输（LOOPBACK TRANSMISSION）。

我咋知道我的NAT是什么类型？

在stun目录下有个简单的Python脚本，用RFC3489（经典STUN协议）的示例来检测NAT类型。 运行：

cd stun
python3 classic_stun_client.py [本地IP]

运行结果示例如下：

INFO:root:running test I with stun.ideasip.com:3478
INFO:root:MAPPED_ADDRESS: 220.181.57.217:46208
INFO:root:running test II with stun.ideasip.com:3478
INFO:root:running test I with 217.116.122.138:3479
INFO:root:MAPPED_ADDRESS: 220.181.57.217:2732
NAT_TYPE: Symmetric NAT

相关介绍文章

• https://evilpan.com/2015/10/31/p2p-over-middle-box/

注: 本项目只是一个简单的UDP打洞示例，如果想构建成熟的P2P应用，可以接着参考STUN/TURN以及ICE等协议。

p2p-over-middleboxes-demo's Issues

你好！

请教一下，怎样正确使用tools里面的udp_server和udp_client检测Nat是否支持回环传输（FULL CONE NAT）?

A机器的内网地址（192.168.1.14）
B机器的内网地址（192.168.1.43）

我在A（192.168.1.14）机器上运行：udp_server 8888，
在B（192.168.1.43）机器上运行udp_client；然后运行sendto 192.168.1.14:8888 hello
此时A是可以收到hello的。但是我感觉我测试的方式有问题，请问是这样测试的吗，如果不是，您能不能把正确的方式跟我说一下？

开源协议

请问一下它的开源协议是什么，或者使用这些源码需要遵守什么要求

服务端C外网运行，客户端A内网虚机机运行，客户端B远程控制家里机器运行。A向B发送消息成功，B向A发送消息不成功。

打洞成功后，客户端A向B发消息成功，客户端B向A发消息不成功。
测试环境，服务端C在公网上，客户端A在机器1虚拟机下运行，客户端B远程控制机器2运行。

服务端外网运行后，客户端之间不能通信。

程序运行后，客户端A，B通信不成功。
测试环境，服务端C在公网上，客户端A在机器1虚拟机下运行，客户端B在机器2虚拟机下运行，连的手机wifi热点。
求教，这程序有验证成功过吗？

How do you running the priject?

Hi,I need you help,because i don't how to running the project,how to test result Thanks

客户端Port Rristrict Cone NAT服务端 Full Cone NAT，打洞不成功

测试过两个不同局域网，打洞不成功。两个相同局域网（同一个nat之后）也是不成功。
没成功问题表现在，当clientA主动向clientB发送一个punch命令时候。然后再发给服务端，服务端转发给clientB，clientB这时候发送一个消息给clientA。但是clientA没有收到消息（问题在这里，这个是同一个nat之后）。（客户端Port Rristrict Cone NAT服务端 Full Cone NAT），请问大概是哪里问的问题呢。
对于这个，不是很理解。
If two of your peers are both behind the same NAT, this NAT must support LOOPBACK TRANSMISSION to forward messages. You can test it by using the utils(udp_server/udp_client) in tools

#define MSG_MAGIC 0x8964

RFC5389中Magic Cookie定义的是0x2112A442，这里为什么定义的不一样呢？

不同NAT端口存活时间不同，为了保活则需要频繁打洞

场景1:
例如客户端A处于内网，地址192.168.2.10:8001，第一次发送消息至公网服务S时，客户端A外网端口为10.0.0.1: 52000，有的NAT端口存活时间就30s，30s不持续向发送UDP数据包保活，则端口会被回收，则公网服务S再向62000发送数据时，端口已经被回收，导致客户端A无法正常收到数据，下次客户端A再次发送至S可能端口变为52001 ,服务S只能再向52001才能正常通信。
此处暂时是通过客户端频繁向公网服务S，定时30s发送数据包，保持端口存活，但同时服务S也会收到该数据包，但不进行回复。
请问有别的方式保活吗？能让NAT识别进行保活，但服务器端可不用收到保活消息。

P2P场景2：
服务S公网IP端口(18.181.0.31:1235)，客户端A的内网地址(10.0.0.1:1234)，外网地址(155.99.25.11:62000)，客户端B内网地址(10.1.1.3:12345)，外网地址(138.76.29.7:31000)。
当客户端A与服务S建立链接时，映射为18.181.0.31:1235 - 155.99.25.11:62000，客户端B与服务S建立链接映射为18.181.0.31:1235 - 138.76.29.7:31000。
服务S和客户端A和客户端B都可以正常通信，但客户端A和客户端B不能正常通信，当服务S告知客户端A，需要进行打通，打洞的目标地址为客户端B的地址(138.76.29.7:31000)，此时客户端B这个外网分配的端口仅仅是NAT分配给客户端B与服务S进行通信的端口，而并不是客户端B应用程序所运行的真实端口，导致双方频繁进行打洞和发送消息，双方也无法进行交互。
请问如何解决？