我最近通过DELPHI7写了一个基于UDP的点对点通讯程序,发给了一个朋友,我和他之间通过上宽带进行测试,设置好IP和端口号之后,我发现一个问题,对方是直接用ADSL一台机子上网的,而我是使用带路由的mondem(有设置路由),也是通过它底下有好几台机子共享上网的,结果我向对方发出一条信息,对方可以收到,对方给我发的信息我确收不到,后来我在一本书上看到:
    假如网吧的公共IP为:220.162.0.1,公网服务器的IP为220.162.0.2,网吧内的IP为:192.168.0.1-192.168.0.10,网吧服务器IP为192.168.0.1。
    如果网吧内的一台电脑192.168.0.5发数据给公网服务器的话,网吧服务器会将发送端的IP地址改为:220.162.0.1:5555,“:”后的为端口号,自动生成的,公 
网  服务器接收后,将发回的信息至IP:220.162.0.1:5555,网吧服务器接收后,会将此IP转换成192.168.0.5。我在服务端加上收到消息后再发送以下面语句~我在客户端怎么试就是收不到!
UDPServer.SendTo(ABinding.PeerIP, ABinding.PeerPort, s, Length(s));后来我放到局域网~试都是正常~是不是220.162.0.1:5555后端口号不正确?NAT解析端口号没有指定到我这个IP?还是放火墙拦截什么原因!实在想不出来了~忘高手能教教,感激不尽!

解决方案 »

  1.   

    顶啊,最近刚好在研究DELPHI的网络通信,学习中......
      

  2.   

    而且你peer to peer的时候监听的端口应该是peerport,不而是事先设定好的端口
      

  3.   

    初始化的时候不应该用bind(),  公网(外网)用户可以bind 绑定, 内网用户bind肯定就发不出去了
    建议 双方都不bind(); 通信之前先进行打洞,内网用户先发送请求给外网, 外网回复一个,确定连通以后加个心跳包,维持
    路由上分配的端口,双方根据之前接收的的IP和端口与对方通信 
      

  4.   

    谢谢大家了!
    我再把具体原因跟大家说说我现在所在子网(内网)的公网(外网)IP:219.128.50.105   
    我所在电脑IP:192.168.0.22  是通过放火墙+路由分配我所要访问的外网IP:221.5.125.129 暂时称为服务端 在服务端了一个Indy  IdUDPServer控件  固定监听Port:1001
    在收到消息以后然后在已对方带过来的IP地址回复一次!问题就在这里了!
    procedure MainForm.UDPServerUDPRead(Sender: TObject; AData: TStream;ABinding: TIdSocketHandle);
    var
      DataStringStream: TStringStream;
      s: String;
    begin
      DataStringStream := TStringStream.Create('');
      try
        DataStringStream.CopyFrom(AData, AData.Size);
        UDPMemo.Lines.Add('Received "' + DataStringStream.DataString + '" from ' + ABinding.PeerIP + ' on port ' + IntToStr(ABinding.PeerPort));
        s := 'Replied from ' + UDPServer.LocalName + ' to" ' + DataStringStream.DataString + '"';
        ABinding.SendTo(ABinding.PeerIP,ABinding.PeerPort, s, Length(s));  //回送消息
      finally
        DataStringStream.Free;
      end;
    end;
    我后来在我的电脑这边下了IdUDPServer IdUDPClient两个控件
    分别发送消息到服务端procedure TUDPMainForm.SendButtonClick(Sender: TObject);
    var
      ThisMessage: String;
      ReceivedString: String;
    begin
      ThisMessage := 'Message:' +edit1.Text; 
      UDPMemo.Lines.Add('Sending ' + ThisMessage);
      UDPClient.Send(ThisMessage); //发送包
      IdUDPServer1.Send('221.5.125.157',1001,ThisMessage);
      ReceivedString := UDPClient.ReceiveString();  //接受回来的包
      if ReceivedString = '' then
        UDPMemo.Lines.Add('No response received from the server after ' + IntToStr(UDPClient.ReceiveTimeout) + ' millseconds.')
      else
        UDPMemo.Lines.Add('Received: ' + ReceivedString)
    end;
    并把IdUDPServer.DefaultPort:=1002
    并且OnRead监听    现在在服务端那边可以收到如下信息这两个都应该是打洞对应我192.168.0.22的IP~~可是为什么回传后我收不到?????
      

  5.   

    TO:xiaokexinger 
         外网回复一个,确定连通以后加个心跳包,维持 
    路由上分配的端口,双方根据之前接收的的IP和端口与对方通信
      外网我能确定已经回复了~可是我这边收不到!
      我在网站上看了好多资料~都说这个样的方式几乎基于透明了
      可我还是收不到消息!服务端那边!只要我发送消息就能立即收到!
               
      

  6.   

    procedure   TUDPMainForm.SendButtonClick(Sender:   TObject); 
    begin 
        IDUDPServer1.DefaultPort :=1002;
        if not IDUDPServer1.Active then IDUDPServer1.Active:=true;
        IDUDPServer1.Binding.SendTo(IP,Port,pack,sizeof(pack));
    end; procedure TMainForm.IdUDPServer1UDPRead(Sender: TObject; AData: TStream;
      ABinding: TIdSocketHandle);
    begin
      showmessage('收到!');
    end;
      

  7.   


         并把IdUDPServer.DefaultPort:=1002 
        并且OnRead监听  楼上的兄弟帮我帮这两句话给换成程序了~
      杂就不给个能帮我给个解决的程序列!
      

  8.   

    UPD协议经过NAT后无法指向目标机子的,必须想办法试用穿透NAT的办法才能传递。
      

  9.   

    NAT处理不好,肯定接收不过来的。
      

  10.   

    你需要查看些书,你是用路由上网的,也就是内网用户, 
    而你朋友是ASDL拨号,是公网的 有固定的IP, 假如这个时候你的内网IP比如是192。168。1。11  端口是9000; 你的外网IP是60.0.10.123。
    你现在给你朋友的IP和端口发数据,他肯定是收的到的,他给你发就不可以了。 因为你必须要再自己的路由上建立一条属于你的通道《我也不知道怎么解释好》, 
    处理的方法 就是你给你朋友发一个打洞包, 他那里显示来自60.0.10.123:56000的包,这个60.0.10.123:56000 就是你路由上映射给192。168。1。11:9000的,路由上接收到任何给60.0.10.123:56000的包 自动分配到192。168。1。11:9000上。所以 你朋友要回复时就应该回复给60.0.10.123:56000而不是192。168。1。11:9000
      

  11.   

    最近刚写了一个类似的程序,看了一下楼主的代码逻辑。应该没有什么问题,请楼主用最新的Indy10试试。
    我用的就是Indy10的。
      

  12.   

    看看下面的打洞原理,方法,步骤:
        NAT(Network Address Translators),网络地址转换:网络地址转换是在IP地址日益缺乏的情况下产生的,它的主要目的就是为了能够地址重用。NAT分为两大类,基本的NAT和NAPT(Network Address/Port Translator)。
        最开始NAT是运行在路由器上的一个功能模块。
        
        最先提出的是基本的NAT,它的产生基于如下事实:一个私有网络(域)中的节点中只有很少的节点需要与外网连接(呵呵,这是在上世纪90年代中期提出的)。那么这个子网中其实只有少数的节点需要全球唯一的IP地址,其他的节点的IP地址应该是可以重用的。
        因此,基本的NAT实现的功能很简单,在子网内使用一个保留的IP子网段,这些IP对外是不可见的。子网内只有少数一些IP地址可以对应到真正全球唯一的IP地址。如果这些节点需要访问外部网络,那么基本NAT就负责将这个节点的子网内IP转化为一个全球唯一的IP然后发送出去。(基本的NAT会改变IP包中的原IP地址,但是不会改变IP包中的端口)
        关于基本的NAT可以参看RFC 1631
        
        另外一种NAT叫做NAPT,从名称上我们也可以看得出,NAPT不但会改变经过这个NAT设备的IP数据报的IP地址,还会改变IP数据报的TCP/UDP端口。基本NAT的设备可能我们见的不多(呵呵,我没有见到过),NAPT才是我们真正讨论的主角。看下图:
                                    Server S1                         
                             18.181.0.31:1235                          
                                          |
              ^  Session 1 (A-S1)  ^      |  
              |  18.181.0.31:1235  |      |   
              v 155.99.25.11:62000 v      |    
                                          |
                                         NAT
                                     155.99.25.11
                                          |
              ^  Session 1 (A-S1)  ^      |  
              |  18.181.0.31:1235  |      |  
              v   10.0.0.1:1234    v      |  
                                          |
                                       Client A
                                    10.0.0.1:1234
        有一个私有网络10.*.*.*,Client A是其中的一台计算机,这个网络的网关(一个NAT设备)的外网IP是155.99.25.11(应该还有一个内网的IP地址,比如10.0.0.10)。如果Client A中的某个进程(这个进程创建了一个UDP Socket,这个Socket绑定1234端口)想访问外网主机18.181.0.31的1235端口,那么当数据包通过NAT时会发生什么事情呢?
        首先NAT会改变这个数据包的原IP地址,改为155.99.25.11。接着NAT会为这个传输创建一个Session(Session是一个抽象的概念,如果是TCP,也许Session是由一个SYN包开始,以一个FIN包结束。而UDP呢,以这个IP的这个端口的第一个UDP开始,结束呢,呵呵,也许是几分钟,也许是几小时,这要看具体的实现了)并且给这个Session分配一个端口,比如62000,然后改变这个数据包的源端口为62000。所以本来是(10.0.0.1:1234->18.181.0.31:1235)的数据包到了互联网上变为了(155.99.25.11:62000->18.181.0.31:1235)。
        一旦NAT创建了一个Session后,NAT会记住62000端口对应的是10.0.0.1的1234端口,以后从18.181.0.31发送到62000端口的数据会被NAT自动的转发到10.0.0.1上。(注意:这里是说18.181.0.31发送到62000端口的数据会被转发,其他的IP发送到这个端口的数据将被NAT抛弃)这样Client A就与Server S1建立以了一个连接。    呵呵,上面的基础知识可能很多人都知道了,那么下面是关键的部分了。
        看看下面的情况:
        Server S1                                     Server S2
     18.181.0.31:1235                              138.76.29.7:1235
            |                                             |
            |                                             |
            +----------------------+----------------------+
                                   |
       ^  Session 1 (A-S1)  ^      |      ^  Session 2 (A-S2)  ^
       |  18.181.0.31:1235  |      |      |  138.76.29.7:1235  |
       v 155.99.25.11:62000 v      |      v 155.99.25.11:62000 v
                                   |
                                Cone NAT
                              155.99.25.11
                                   |
       ^  Session 1 (A-S1)  ^      |      ^  Session 2 (A-S2)  ^
       |  18.181.0.31:1235  |      |      |  138.76.29.7:1235  |
       v   10.0.0.1:1234    v      |      v   10.0.0.1:1234    v
                                   |
                                Client A
                             10.0.0.1:1234
        接上面的例子,如果Client A的原来那个Socket(绑定了1234端口的那个UDP Socket)又接着向另外一个Server S2发送了一个UDP包,那么这个UDP包在通过NAT时会怎么样呢?
        这时可能会有两种情况发生,一种是NAT再次创建一个Session,并且再次为这个Session分配一个端口号(比如:62001)。另外一种是NAT再次创建一个Session,但是不会新分配一个端口号,而是用原来分配的端口号62000。前一种NAT叫做Symmetric NAT,后一种叫做Cone NAT。我们期望我们的NAT是第二种,呵呵,如果你的NAT刚好是第一种,那么很可能会有很多P2P软件失灵。(可以庆幸的是,现在绝大多数的NAT属于后者,即Cone NAT)
       
        好了,我们看到,通过NAT,子网内的计算机向外连结是很容易的(NAT相当于透明的,子网内的和外网的计算机不用知道NAT的情况)。
        但是如果外部的计算机想访问子网内的计算机就比较困难了(而这正是P2P所需要的)。
        那么我们如果想从外部发送一个数据报给内网的计算机有什么办法呢?首先,我们必须在内网的NAT上打上一个“洞”(也就是前面我们说的在NAT上建立一个Session),这个洞不能由外部来打,只能由内网内的主机来打。而且这个洞是有方向的,比如从内部某台主机(比如:192.168.0.10)向外部的某个IP(比如:219.237.60.1)发送一个UDP包,那么就在这个内网的NAT设备上打了一个方向为219.237.60.1的“洞”,(这就是称为UDP Hole Punching的技术)以后219.237.60.1就可以通过这个洞与内网的192.168.0.10联系了。(但是其他的IP不能利用这个洞)。
        
        呵呵,现在该轮到我们的正题P2P了。有了上面的理论,实现两个内网的主机通讯就差最后一步了:那就是鸡生蛋还是蛋生鸡的问题了,两边都无法主动发出连接请求,谁也不知道谁的公网地址,那我们如何来打这个洞呢?我们需要一个中间人来联系这两个内网主机。
        现在我们来看看一个P2P软件的流程,以下图为例:                       Server S (219.237.60.1)
                              |
                              |
       +----------------------+----------------------+
       |                                             |
     NAT A (外网IP:202.187.45.3)                 NAT B (外网IP:187.34.1.56)
       |   (内网IP:192.168.0.1)                      | (内网IP:192.168.0.1)
       |                                             |
    Client A  (192.168.0.20:4000)             Client B (192.168.0.10:40000)    首先,Client A登录服务器,NAT A为这次的Session分配了一个端口60000,那么Server S收到的Client A的地址是202.187.45.3:60000,这就是Client A的外网地址了。同样,Client B登录Server S,NAT B给此次Session分配的端口是40000,那么Server S收到的B的地址是187.34.1.56:40000。
        此时,Client A与Client B都可以与Server S通信了。如果Client A此时想直接发送信息给Client B,那么他可以从Server S那儿获得B的公网地址187.34.1.56:40000,是不是Client A向这个地址发送信息Client B就能收到了呢?答案是不行,因为如果这样发送信息,NAT B会将这个信息丢弃(因为这样的信息是不请自来的,为了安全,大多数NAT都会执行丢弃动作)。现在我们需要的是在NAT B上打一个方向为202.187.45.3(即Client A的外网地址)的洞,那么Client A发送到187.34.1.56:40000的信息,Client B就能收到了。这个打洞命令由谁来发呢,呵呵,当然是Server S。
        总结一下这个过程:如果Client A想向Client B发送信息,那么Client A发送命令给Server S,请求Server S命令Client B向Client A方向打洞。呵呵,是不是很绕口,不过没关系,想一想就很清楚了,何况还有源代码呢(侯老师说过:在源代码面前没有秘密 8)),然后Client A就可以通过Client B的外网地址与Client B通信了。
        
        注意:以上过程只适合于Cone NAT的情况,如果是Symmetric NAT,那么当Client B向Client A打洞的端口已经重新分配了,Client B将无法知道这个端口(如果Symmetric NAT的端口是顺序分配的,那么我们或许可以猜测这个端口号,可是由于可能导致失败的因素太多,我们不推荐这种猜测端口的方法)。
        
      

  13.   

    其实udp穿孔打洞说白了就是一个欺骗过程,A要利用B与服务器连接时用的port,IP来,发数据来与B通信,同样,B要利用A与服务器连接时用的PORT,IP来与A通信,本来A,B与服务器连接的端口是只能与服务器通信的,现在通过一些处理,让A接收B发的数据,同样让B接收A发的数据,都接收数据完成这次打洞就算成功,打洞成功后还要对这个洞进行维持,因为彼此的port都是动态创建的,有一定的生命周期,过一段时间收不到数据就自动给释放了,所以要音隔一段时间发一个维持连接的心跳包给对方
      

  14.   

    感觉lz思路没有什么问题 ,在向外网发送UDP包的时候,路由器会建立映射和通路的,但是这个映射只会保留一定的时间.如果超时了,也是收不到的.
    建议1.当外网收到包时,立即向内网回复下,测试是不是映射时间过短的问题,如果是到路由上去做设置和修改.
      2.一个内网跟一个外网通信,打洞意义不大,何况lz的情况都单向通信成功了.
      3.看一下服务器上的返回包的程序,是不是有什么地方没有注意
      

  15.   

    不是所有的nat都可以打通的,采用80端口怎么走?