今天上百合系版，惊见30w人气的大作。整个世界震惊了！左右一想，不对，以人为的力量这得多少人多大的耐心呐。嗯，是了，肯定是借助了某种共具。

  受了启发，我已迅雷不及掩耳盗铃之势，打开可爱的eclipse。四处搜刮了一些资料，真是顺呐，这年头想在茫茫85899345920字节海的电脑里找到我想要的东东，居然就是信手拈来。。。

  立马开工，很快，即两个多小时后，页面刷新工具新鲜出炉。为了提高实用性，又增加了一些功能及参数，可谓能够在各大高低速不等的BBS间游刃有余得骗取点击率了。

  说了这么多废话，总得把简单的原理记下，要不怎对得起这空间？我是利用了URL封装类，直接创建连接，但是不必从连接中获取详细数据，每创建一个连接相当于页面刷新一次。同时为了防止界面失去响应，按钮事件里加入线程处理刷新页面事件；为了多个连接并行工作，为每个URL连接请求创建一个线程。另外，防止连接超时及刷新效率以及对网站增加负载的可控性，分“刷新块”（我创的名词，凑活用吧）来处理，比如一个块50次刷新，下一个块必须等待这个块全部刷新结束，即50个连接线程终止，包括异常在内。

  本次设计基于的URL类还是太高级了，可控制能力弱。考虑用并行连接方式发送HTTP报头来创建连接，估计效率还会提高。

  今天原想早点睡的，看看时间都2点快40了，明天还得早起，看样子考试期间的睡眠百分比要低于25%了。。。

Java中有许多可以制作音频播放的包和类，包括java.applet.AudioClip、com.sun.media.sound.JavaSoundAudioClip和javax.sound.midi.spi&javaw.sound.sampled.spi等，其中java.applet.AudioClip是从JDK1.0就存在的一个接口，其余的多个类是对这个接口的实现及丰富其功能。

 

构造AudioPlay类－－音频播放wav，注意异常处理

// import com.sun.media.sound.JavaSoundAudioClip; import java.io.*; //生成音频流 　private JavaSoundAudioClip locate;　 　　try { 　　　FileInputStream ff = new FileInputStream(f); 　　　locate = new JavaSoundAudioClip(ff); 　　} 　　catch (Exception e) { 　　　System.out.println("error"); 　　} //播放 　　　　try { 　　　　　locate.play(); 　　　　　　　　　} 　　　　catch (Exception ee) {} //停止 　　　　locate.stop();

 

UDP协议包经NAPT透明传输的说明:

NAPT为每一个Session分配一个NAPT自己的端口号，依据此端口号来判断将收到的公网IP主机返回的TCP/IP数据包转发给那台内网IP地址的计算机。在这里Session是虚拟的，UDP通讯并不需要建立连接，但是对于NAPT而言，的确要有一个Session的概念存在。NAPT对于UDP协议包的透明传输面临的一个重要的问题就是如何处理这个虚拟的Session。我们都知道TCP连接的Session以SYN包开始，以FIN包结束，NAPT可以很容易的获取到TCP Session的生命周期，并进行处理。但是对于UDP而言，就麻烦了，NAPT并不知道转发出去的UDP协议包是否到达了目的主机，也没有办法知道。而且鉴于UDP协议的特点，可靠很差，因此NAPT必须强制维持Session的存在，以便等待将外部送回来的数据并转发给曾经发起请求的内网IP地址的计算机。NAPT具体如何处理UDP Session的超时呢？不同的厂商提供的设备对于NAPT的实现不近相同，也许几分钟，也许几个小时，些NAPT的实现还会根据设备的忙碌状态进行智能计算超时时间的长短。

现在来看一下NAPT是依据什么策略来判断是否要为一个请求发出的UDP数据包建立Session的主要有一下几个策略:

A. 源地址(内网IP地址)不同，忽略其它因素, 在NAPT上肯定对应不同的Session
B. 源地址(内网IP地址)相同，源端口不同，忽略其它的因素，则在NAPT上也肯定对应不同的Session
C. 源地址(内网IP地址)相同，源端口相同，目的地址(公网IP地址)相同，目的端口不同，则在NAPT上肯定对应同一个Session
D. 源地址(内网IP地址)相同，源端口相同，目的地址(公网IP地址)不同，忽略目的端口，则在NAPT上是如何处理Session的呢？

D的情况正式我们关心和要讨论的问题。依据目的地址(公网IP地址)对于Session的建立的决定方式我们将NAPT设备划分为两大类:

Symmetric NAPT:
对于到同一个IP地址，任意端口的连接分配使用同一个Session; 对于到不同的IP地址, 任意端口的连接使用不同的Session.
我们称此种NAPT为 Symmetric NAPT. 也就是只要本地绑定的UDP端口相同， 发出的目的IP地址不同，则会建立不同的Session.

Cone NAPT:
对于到同一个IP地址，任意端口的连接分配使用同一个Session; 对于到不同的IP地址，任意端口的连接也使用同一个Session.
我们称此种NAPT为 Cone NAPT. 也就是只要本地绑定的UDP端口相同， 发出的目的地址不管是否相同， 都使用同一个Session.

客户端都处于相同的NAT之后

我们假设，Client A 和 Client B 要使用上一节我们所描述的 “UDP打洞技术”，并通过服务器S这个“媒人”来认识，这样Client A 和Client B首先从服务端S得到了彼此的公网IP地址和端口，然后就往对方的公网IP地址和端口上发送消息。在这种情况下，如果NAT 仅仅允许在 内部网主机与其他内部网主机（处于同一个NAT之后的网络主机）之间打开UDP会话通信通道，而内部网主机与其他外部网主机就不允许的话，那么Client A 和Client B就可以通话了。我们把这种情形叫做“loopback translation”(“回环转换”)，因为数据包首先从局域网的私有IP发送到NAT转换，然后“绕一圈”，再回到局域网中来，但是这样总比这些数据通过公网传送好。举例来说，当 Client A发送了一个UDP数据包到 Client B的公网IP地址，这个数据包的报头中就会有一个源地址10.0.0.1:124和一个目标地址155.99.25.11:62001。NAT接收到这个包以后，就会(进行地址转换)解析出这个包中有一个公网地址源地址155.99.25.11:62000和一个目标地址10.1.1.3:1234，然后再发送给B，虽说NAT支持“loopback translation”，我们也发现，在这种情形下,这个解析和发送的过程有些多余，并且这个Client A 和Client B 之间的对话可能潜在性地给NAT增加了负担。

 UDP打洞技术有很多实用的地方：

第一，一旦这种处于NAT之后的端对端的直连建立之后，连接的双方可以轮流担任 对方的“媒人”，把对方介绍给其他的客户端，这样就极大的降低了服务器S的工作量；第二，应用程序不用关心这个NAT是属于cone还是symmetric，即便要，如果连接的双方有一方或者双方都恰好不处于NAT之后，基于上叙的步骤，他们之间还是可以建立很好的通信通道；第三，打洞技术能够自动运作在多重NAT之后，不论连接的双方经过多少层NAT才到达Internet，都可以进行通信。

UPD端口号预言
明显的，有许多因素会导致这个方法失败：如果这个预言的新端口（62001和31001） 恰好已经被一个不相关的会话所使用，那么NAT就会跳过这个端口号，这个连接就会宣告失败；如果两个NAT有时或者总是不按照顺序来生成新的端口号，那么这个方法也是行不通的。

如果隐藏在NAT A后的一个不同的客户端X（或者在NAT B后）打开了一个新的“外出”UDP 连接，并且无论这个连接的目的如何；只要这个动作发生在 客户端A 建立了与服务器S 的连接之后，客户端A 与 客户端B 建立连接之前；那么这个无关的客户端X 就会趁人不备地“偷” 到这个我们渴望分配的端口。所以，这个方法变得如此脆弱而且不堪一击，只要任何一个NAT方包含以上碰到的问题，这个方法都不会奏效。
 自从使用这种方法来实践P2P的应用程序以来,在处于 cone NAT 系列的网络环境中这个方法还是实用的；如果有一方为 cone NAT 而另外一方为 symmetric NAT，那么应用程序就应该预先发现另外一方的 NAT 是什么类型，再做出正确的行为来处理通信，这样就增大了算法的复杂度，并且降低了在真实网络环境中的普适性。

    最后，如果P2P的一方处在两级或者两级以上的NAT下面，并且这些NATs 接近这个客户端是 symmetric的话，端口号预言 是无效的！

 

保持端口绑定
在使用“UDP打洞技术”时有一点必须要注意：它只能在双方的NAT都是cone NAT（或者干脆没有NAT）时才能正常工作；这些NAT在自己的公网UDP端口被使用时保持着端口的绑定——[私有IP，私有UDP端口]对和[公网IP，公网UDP端口]对的一一对应。如果像 symmetricNAT那样给每个新的会话都分配一个新的公网端口，那么UDP应用程序想要与其他外部客户端进行通话，就无法重复使用已经建立好的通信转换。

伴随着 cone NAT 的推广，“UDP打洞技术”也被越来越广泛的应用。然而，仍存在一小部分使用 symmetric NAT 的网络，那么在这小部分网络环境中，就不能使用“UDP打洞技术”。

（注：因为我国的国情，网络技术应用得比较晚，所以可以说绝大部分的网络都是cone NAT，所以 UDP打洞技术基本上可以畅通无阻的使用，只是还要注意对NAT是否支持“loopback translation”的测试）

  这是一个视图操作与数据操作相分离的组件。

  对视图操作如下，用一个视图图类定义，实现ListCellRenderer接口即可。

  public class BWCRoomCellRenderer extends JLabel implements ListCellRenderer
  {
    private BWCRoomListData data = null;

    public Component getListCellRendererComponent(JList list, Object value,
        int index, boolean isSelected, boolean hasFocus)
    {
      // 这里就是列表框的数据，其中BWCRoomListData是另外一个数据类.
      data = (BWCRoomListData)value;
      //在JLabel上放上图标和字符串 并设置文本在右边,以及两者的间距 

     setText(String.valueOf(data.getRoomIndex() + "  " + data.getRoomName()
          + "  (" + data.getReadyUsers() + "/" + data.getTotalUsers() + ")"));
      if(data.getReadyUsers() == 2)
        setIcon(startIcon);
      else setIcon(waitIcon);
      setHorizontalTextPosition(SwingConstants.RIGHT);
      setIconTextGap(5);
      // setBorder(BorderFactory.createEmptyBorder(0, 5, 0, 5));

      // 设置项目被选中时的颜色
       
      if(isSelected)
      {
    //    setBackground(list.getSelectionBackground());
        setBackground(new Color(252, 209, 0));
        setForeground(Color.BLACK);
      ///  setForeground(list.getSelectionForeground());
      }
      else
      {
        setBackground(list.getBackground());
        setForeground(list.getForeground());
      }
      setEnabled(list.isEnabled());
      setFont(list.getFont());
      setOpaque(true);
      return this;
    }
  }

 

  再添加数据类，如下即可

 public class BWCRoomListData
  {
    private Icon icon;

    private int roomIndex;

    private int readyUsers = 0;

    private int totalUsers = 0;

    private String roomName;

    BWCRoomListData(int roomIndex, String roomName, int readyUsers,
        int totalUsers)
    {
      this.roomIndex = roomIndex;
      this.readyUsers = readyUsers;
      this.totalUsers = totalUsers;
      this.roomName = roomName;
      // this.icon = icon;
    }

    public int getRoomIndex()
    {
      return this.roomIndex;
    }

    public int getReadyUsers()
    {
      return this.readyUsers;
    }

    public int getTotalUsers()
    {
      return this.totalUsers;
    }

    public String getRoomName()
    {
      return this.roomName;
    }   
  }

  最后设置好数据，可以为上述数据类对象的数组，然后调用JList的函数

  jlRoomList.setCellRenderer(new BWCRoomCellRenderer());

再添加数据jlRoomList.setListData(data);即可。

注意这里会实际更新data里的数据并显示出来，如果data=null，列表视图也为空

  我在写黑白棋网络版，大厅与游戏界面（两个JFrame）切换时遇到一个很隐藏的问题，花了半天时间才搞明白。

  具体现象是，游戏界面dispose并调出大厅界面，然后大厅中的readObject()完全读不到东西，异常大概是EOFException。经过长时间分析(怎么解决bug的过程在此略过了) ，确定原因是由于界面类(BWCClient)通过关闭窗口的事件响应里开启大厅线程，而BWCClient里另外一个处理接受消息的线程，包含readObject指令。而大厅线程启动后也开启了监听消息线程，此时原来的BWCClient里并没有完全释放掉资源，线程也未退出，即同时有了两个readObject()函数在执行，造成了异常。

  解决方案当然多种多样，我只试了一下通过服务器来转发通知数据包给本界面线程的readObject循环，当读到该通知信息后，线程退出并解除循环等待(Flag = false)，窗口监听事件用一个循环等待

while(Flag)

{

   Thread.sleep(100);

 

1，ObjectOutputStream osToServer = new ObjectOutputStream(connectToServer
            .getOutputStream());
        ObjectInputStream isFromServer = new ObjectInputStream(connectToServer
            .getInputStream());

这两句话貌似对顺序有一定的要求，换一下会读不出Stream

 

2，getOutputStream().reset() 在输出一个对象流的时候 往往另一端会读到null（一般不会全是null，而是某些如ArrayList的对象会读出来null），这时候用输出对象的reset可以保证流的传输正确。

-------------------------我素华丽的分割线----------------------

以上两点有些困惑。

 

3, JTextArea.setCaretPosition(jChat.getText().length());通过每次添加字符串后调用此方法，可以使光标移至最后，保证其自动滚动

 

P2P 之 UDP穿透NAT的原理与实现（附源代码）
原创：shootingstars
参考：http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt

论坛上经常有对P2P原理的讨论，但是讨论归讨论，很少有实质的东西产生（源代码）。呵呵，在这里我就用自己实现的一个源代码来说明UDP穿越NAT的原理。

首先先介绍一些基本概念：
    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的端口是顺序分配的，那么我们或许可以猜测这个端口号，可是由于可能导致失败的因素太多，我们不推荐这种猜测端口的方法）。
   
    下面是一个模拟P2P聊天的过程的源代码，过程很简单，P2PServer运行在一个拥有公网IP的计算机上，P2PClient运行在两个不同的NAT后（注意，如果两个客户端运行在一个NAT后，本程序很可能不能运行正常，这取决于你的NAT是否支持loopback translation，详见http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt，当然，此问题可以通过双方先尝试连接对方的内网IP来解决，但是这个代码只是为了验证原理，并没有处理这些问题），后登录的计算机可以获得先登录计算机的用户名，后登录的计算机通过send username message的格式来发送消息。如果发送成功，说明你已取得了直接与对方连接的成功。
    程序现在支持三个命令：send , getu , exit
   
    send格式：send username message
    功能：发送信息给username
   
    getu格式：getu
    功能：获得当前服务器用户列表
   
    exit格式：exit
    功能：注销与服务器的连接（服务器不会自动监测客户是否吊线）
       
    代码很短，相信很容易懂，如果有什么问题，可以给我发邮件zhouhuis22@sina.com  或者在CSDN上发送短消息。同时，欢迎转发此文，但希望保留作者版权8-）。
   
    最后感谢CSDN网友 PiggyXP 和 Seilfer的测试帮助