本机测试UDP遇到的很DT的问题

 

        两台电脑测试Udp也许不难，自己一台电脑测试的时候真是令人不爽.

 

     在写自己的小项目“四人行五子棋”的时候，用的是面向连接的Tcp/Ip协议，创建连接后进行通信，后来在增加一项新的功能:添加私信。添加私信的时候想用下Udp通信，还是有点不太适应的感觉，所以代码还是比较简单的那种，就是测试出现令人很是DT的问题。

      先是在客户端A登录成功以后，除了Tcp登录连接外，自动启动另外一个线程，端口为9999，接受udp信息.客户端B按照道理来讲，客户端默认启动的接受udp的端口应该保持一致为9999，毕竟大家都是客户端。但是为了测试，B登录成功启动了端口9998，结果可想而知，A是阻塞在aceep(),只能先接受消息后才能发送。于是改为下面的：   

      客户端的用户A登录时，开启了一个线程，等待用户连接的DatagramSocket(9999),客户端还有发送 “私信”的功能又开了另外的一个口 DatagramSocket(9998). 是两个类。然后同时打开了另外的一个客户端B，运行客户端前先改了数据，分别是开了端口9997和9996.  9997是等待的线程，9996是为了发送的。按道理是：A的9998端口创建后，给B的等待着的9997发送的，B是用9996端口，给A等待着的9999发送。结果是：A发送消息，但是接受到的是自己，自己发送自己接受，B发送后还是A能接受。

 

      原因：发送和接受是两个类，可能跟编译何时运行有关系<具体两个类加载运行顺序不清楚>。在客户端B登录的时候，首先是改了端口信息：9999和9998改为了9997和9996.然后A在发送消息的时候，打开的已经不是想象的9998，而是9996了，9996是给9999发送消息的，所以出现了自己发送信息自己接受。

 

      一台电脑测试既能发送又能接受udp消息真是繁琐，在A登录后B登录前要改端口，除此之外B登录成功后，还要把端口该回来，如果想体验B不只是接受消息的乏味还要在A登录成功后，把端口改回来。当然整个都是采用了事件监听模型，按钮点击的时候才会回复或者叫发送udp消息。