BlogJava-地狱男爵之博客无限http://www.blogjava.net/hellboys/zh-cnSat, 11 Oct 2008 17:59:22 GMTSat, 11 Oct 2008 17:59:22 GMT60我想应聘中国男子国家足球队主教练一职http://www.blogjava.net/hellboys/archive/2008/06/16/208256.html地狱男爵(hellboys)地狱男爵(hellboys)Mon, 16 Jun 2008 02:56:00 GMThttp://www.blogjava.net/hellboys/archive/2008/06/16/208256.htmlhttp://www.blogjava.net/hellboys/comments/208256.htmlhttp://www.blogjava.net/hellboys/archive/2008/06/16/208256.html#Feedback5http://www.blogjava.net/hellboys/comments/commentRss/208256.htmlhttp://www.blogjava.net/hellboys/services/trackbacks/208256.html我想应聘中国男子国家足球队主教练一职，我有100分的信 心，带领中国队在2010年的时候，把大力神杯捧回中国。
　　根据中国足球的现状，我为中国足球队设 计了一整套战术打法，简称为圆环套圆环法。
　　让我们忘掉433还是442这些无聊的数字吧，从此，
足球场上只有一种几何图形，就是圆环。
　　中国队要冲出亚洲，我的战术是，除守门员以外，其他10个 队员手臂扣手臂，围成一个圆圈，其中，找两个射门准的面对圆心，其他的，都背对圆心。摆出此阵以后，守门员 以手抛球的方法把球抛到这个圆环里，然后，整个圆环开始向对方球门缓缓移动，对手一定束手无策，因为他们根 本看不清楚哪个是执球队员哪个是无球队员，稍一接触，就会犯规。当这个圆环移动到离开对方球门的距离小于1 米的时候，靠近球门的队员两条大腿一分，现出空挡，然后由面对圆心的两个射手中的一个突发冷箭，命中率应该 可以高于99%。
　　这个阵法虽然移动缓慢，但是在90分钟里，进他个10几20个球还是可以的！
　　这个只是圆环套圆环法的第一层境界，如果对手是日本，韩国这样二流队，全取三分应该没有什么问题，
但是如果碰到巴西、阿根廷这样的一流队，就要进行队型变化，变化如下：10个人分成两组，第一种是分成一个 4人圈和一个6人圈，6人圈把4人圈圈在中间，这样可以使防御力提高一倍，更加坚不可破；另外一种是分成两 个独立的5人圈，两个5人圈交替前进，只要队员腿够粗，对方根本不知道球在那个5人圈里面，防不胜防！ 结 合这两套战术，干掉巴西也只是小case。
　　我这套战术，是绝对有效和强大的，只要有心玩，场上控 球时间绝对可以达到80%以上，所以最后做技术统计的时候，数据也可以表明，中国队是当之无愧的强大！
　　当然，对方要破我这一套战术，也是有可能的，办法有两个，第一，所有球员排成一线，挡住球门，第二，
对方加上守门员在内组成11个人的大圆环，包住我方的圆环。这样的话，场上的比分会是0：0，每场取一分，
中国要世界杯出线应该也是没有问题的，总比现在这样好！
　　各位领导，对于这套战术，我研究很深，可 以说是毫无漏洞，请给予一个机会，让我执教中国男子国家足球队，我一定可以将中国足球带至前所未有的辉煌！
　　谢谢！ ”

]]>Android中文文档v0.1 beta低调发布,期待更多同学来参加reviewhttp://www.blogjava.net/hellboys/archive/2007/12/05/165574.html地狱男爵(hellboys)地狱男爵(hellboys)Wed, 05 Dec 2007 08:42:00 GMThttp://www.blogjava.net/hellboys/archive/2007/12/05/165574.htmlhttp://www.blogjava.net/hellboys/comments/165574.htmlhttp://www.blogjava.net/hellboys/archive/2007/12/05/165574.html#Feedback0http://www.blogjava.net/hellboys/comments/commentRss/165574.htmlhttp://www.blogjava.net/hellboys/services/trackbacks/165574.html第一阶段:Android中文文档v0.1 beta发布--由www.androidcn.net社区提供     

Android中文文档阅读地址:  http://www.androidcn.net/wiki/index.php/Documentation

Android中文文档大部分已经完成. 但是可能有不少细节和不足之处需要完善和修补.

感谢翻译的同学,已经在文档里面加入. 如果缺少,请联系我



第二阶段:请有时间的同学进行review.

review阶段既然采用wiki上面形式. 希望review的同学可以联系AndroidCN管理员和各版版主.

相信review阶段对同学理解Android可以有更快的理解和提高. 阅读文档也是对Android理解之初步.

所有在阅读文档的时候,希望同学们不吝啬自己的一笔之力,对于未完全或翻译有误的地方进行涂抹.

相信大家可以先阅读文档,然后提出翻译中的不足进行.

review 讨论区： http://www.androidcn.net/thread-119-1-1.html


]]>欢迎访问Android中国http://www.blogjava.net/hellboys/archive/2007/11/15/160794.html地狱男爵(hellboys)地狱男爵(hellboys)Thu, 15 Nov 2007 09:24:00 GMThttp://www.blogjava.net/hellboys/archive/2007/11/15/160794.htmlhttp://www.blogjava.net/hellboys/comments/160794.htmlhttp://www.blogjava.net/hellboys/archive/2007/11/15/160794.html#Feedback1http://www.blogjava.net/hellboys/comments/commentRss/160794.htmlhttp://www.blogjava.net/hellboys/services/trackbacks/160794.html
主页：http://www.androidcn.net  阅读全文

]]>ActiveMQ4.1 +Spring2.0的POJO JMS方案 扩展，以更加实用（基于ss）.二http://www.blogjava.net/hellboys/archive/2007/04/05/108737.html地狱男爵(hellboys)地狱男爵(hellboys)Thu, 05 Apr 2007 08:55:00 GMThttp://www.blogjava.net/hellboys/archive/2007/04/05/108737.htmlhttp://www.blogjava.net/hellboys/comments/108737.htmlhttp://www.blogjava.net/hellboys/archive/2007/04/05/108737.html#Feedback0http://www.blogjava.net/hellboys/comments/commentRss/108737.htmlhttp://www.blogjava.net/hellboys/services/trackbacks/108737.html一：续一，说明一的可使用性。

<amq:queue id="destination.report"  physicalName="active.jms.report"/>
    <amq:queue id="destination.point"  physicalName="active.jms.point"/>

queue : 队列的名字 for 制造者.

感觉org.springframework.jms.listener.DefaultMessageListenerContainer 做的不好，如果destination property能做一个可包含多个队列，并且有选择性的messageListener就好了，这样就避免下面的监听的尴尬了。呵呵
<!--  listener container，MDP无需实现接口 -->
    <bean id="fluxPerhourListenerContainer" class="org.springframework.jms.listener.DefaultMessageListenerContainer">        
        <property name="connectionFactory" ref="jmsConnectionFactory"/>
        <property name="destination" ref="destination.fluxPerhour"/>
        <property name="messageListener" ref="messageListener"/>
    </bean>
    <bean id="fluxPerDayListenerContainer" class="org.springframework.jms.listener.DefaultMessageListenerContainer">        
        <property name="connectionFactory" ref="jmsConnectionFactory"/>
        <property name="destination" ref="destination.fluxPerday"/>
        <property name="messageListener" ref="messageListener"/>
    </bean>

<bean id="reportPerdayProducer" class="com.jms.ReportPerdayProducer">
        <property name="template" ref="jmsTemplate"/>
        <property name="destination" ref="destination.report"/>
    </bean>
    <bean id="pointProducer" class="com.jms.PointProducer">
        <property name="template" ref="jmsTemplate"/>
        <property name="destination" ref="destination.point"/>
    </bean>

producer不能重用，因为send到不同destination，所有没办法重用。如果能对producer做一个默认统一的封装就好了. 但是DefaultProducer.那么应该注意队列线程安全方面，目前没有什么好的想法，就采用通用一些的办法，不过xml和代码稍多一些.


然后就用到 前面文章一 里面的内容了，非常简便。
<!--  Message Driven POJO (MDP) -->
    <bean id="messageListener" class="org.springframework.jms.listener.adapter.MessageListenerAdapter">
<!--  may be other method -->
        <constructor-arg>
            <bean class="com..jms.MessageConsumerAdapter" >
                <!--业务接口/业务门面-->
                <property name="transfersManager" ref="transfersManager"/>                
            </bean>            
        </constructor-arg>
        <!--  may be other method -->
        <property name="defaultListenerMethod" value="receive"/>
        <!-- custom MessageConverter define -->
        <property name="messageConverter" ref="messageConverter"/>
    </bean>    
<!--  Holder Message converter  -->
    <bean id="messageConverter" class="com.jms.CoverterHolder">
        <property name="defaultMessageConverter">
            <bean class="com.jms.DefaultMessageConverter"/>
        </property>
    </bean>


<!--  Spring JmsTemplate config -->
    <bean id="jmsTemplate" class="org.springframework.jms.core.JmsTemplate">
        <property name="connectionFactory">
            <!--  lets wrap in a pool to avoid creating a connection per send -->
            <bean class="org.springframework.jms.connection.SingleConnectionFactory">
                <property name="targetConnectionFactory" ref="jmsConnectionFactory"/>
            </bean>
        </property>
        <property name="messageConverter" ref="messageConverter"/>
    </bean>
 


二.单元测试有时加载 activemq的问题
1.这个可能和spring版本有关系，请采用比较稳定的版本。例如apache-activemq官方包里面提供的.
2.选择 xml解析的问题，例如
public abstract class SpringManagerTestCase extends
        AbstractTransactionalDataSourceSpringContextTests {

    public SpringManagerTestCase()
    {
        System.setProperty("javax.xml.parsers.DocumentBuilderFactory", "org.apache.xerces.jaxp.DocumentBuilderFactoryImpl");
        System.setProperty("javax.xml.parsers.SAXParserFactory", "org.apache.xerces.jaxp.SAXParserFactoryImpl");
        System.setProperty("javax.xml.transform.TransformerFactory", "org.apache.xalan.processor.TransformerFactoryImpl");
        
        setDependencyCheck(false);
        setDefaultRollback(false);
    }
    /**
     * 配置Spring的配置文件的方法。
     * @see org.springframework.test.AbstractDependencyInjectionSpringContextTests#getConfigLocations()
     */
    protected String[] getConfigLocations() {
        return new String[] {"classpath:applicationContext-activemq-embedded.xml"};
    }

}


三.为特殊的应用服务器，如resin ，也要选择特定的xml解析器
在web.xml中配置增加
<web-app>
  <!--
      In order to be able to compatiable with Resin 2.1.x and 3.0.x,
      both XML and XSLT have to be replaced.
      If only xalan is included, Resin 2.1.x will fail but not 3.0.x.
      Therefore the best way is to use the compatiable version of the
      XML parser ans XSLT.
       - Please refere to the following link for more detailed information.
       - http://www.caucho.com/resin-3.0/xml/jaxp.xtp
  -->
  <!-- xml -->
  <system-property javax.xml.parsers.DocumentBuilderFactory=
               "org.apache.xerces.jaxp.DocumentBuilderFactoryImpl"/>
  <system-property javax.xml.parsers.SAXParserFactory=
               "org.apache.xerces.jaxp.SAXParserFactoryImpl"/>
  <!--  xslt -->
  <system-property javax.xml.transform.TransformerFactory=
               "org.apache.xalan.processor.TransformerFactoryImpl"/>


</web-app>



以上的以全部在实施中测试通过并且运行。大家可以方向使用和理解。如有疑问，相互交流.


]]>ActiveMQ4.1 +Spring2.0的POJO JMS方案 扩展，以更加实用（基于ss）http://www.blogjava.net/hellboys/archive/2007/04/01/107834.html地狱男爵(hellboys)地狱男爵(hellboys)Sun, 01 Apr 2007 13:56:00 GMThttp://www.blogjava.net/hellboys/archive/2007/04/01/107834.htmlhttp://www.blogjava.net/hellboys/comments/107834.htmlhttp://www.blogjava.net/hellboys/archive/2007/04/01/107834.html#Feedback0http://www.blogjava.net/hellboys/comments/commentRss/107834.htmlhttp://www.blogjava.net/hellboys/services/trackbacks/107834.html阅读全文

]]>一台主机被多台电脑监控 (keyword:cacti,snmp,snmpd.conf)http://www.blogjava.net/hellboys/archive/2007/03/07/102331.html地狱男爵(hellboys)地狱男爵(hellboys)Wed, 07 Mar 2007 02:27:00 GMThttp://www.blogjava.net/hellboys/archive/2007/03/07/102331.htmlhttp://www.blogjava.net/hellboys/comments/102331.htmlhttp://www.blogjava.net/hellboys/archive/2007/03/07/102331.html#Feedback0http://www.blogjava.net/hellboys/comments/commentRss/102331.htmlhttp://www.blogjava.net/hellboys/services/trackbacks/102331.html


NAME
       share/snmp/snmpd.conf  -  configuration  file for the ucd-
       snmp SNMP agent.

DESCRIPTION
       snmpd.conf is the configuration file which defines how the
       ucd-smnp SNMP agent operates.  These files may contain any
       of the directives found in the DIRECTIVES  section  below.
       This  file  is  not  required for the agent to operate and
       report mib entries.

PLEASE READ FIRST
       First, make sure you have read the  snmp_config(5)  manual
       page  that  describes how the ucd-snmp configuration files
       operate, where they are located  and  how  they  all  work
       together.

EXTENSIBLE-MIB
       The  ucd-snmp  SNMP  agent reports much of its information
       through queries to the 1.3.6.1.4.1.2021 section of the mib
       tree.   Every  mib in this section has the following table
       entries in it.

       .1 -- index
              This is the table's index numbers for each  of  the
              DIRECTIVES listed below.

       .2 -- name
              The  name of the given table entry.  This should be
              unique, but is not required to be.

       .100 -- errorFlag
              This is a flag returning either the integer value 1
              or  0 if an error is detected for this table entry.

       .101 -- errorMsg
              This is a DISPLAY-STRING describing any error trig-
              gering the errorFlag above.

       .102 -- errorFix
              If  this entry is SNMPset to the integer value of 1
              AND the errorFlag defined above is indeed  a  1,  a
              program  or script will get executed with the table
              entry name from above as the argument.  The program
              to  be  executed is configured in the config.h file
              at compile time.

   Directives
       proc NAME

       proc NAME MAX

       proc NAME MAX MIN

              Checks to see if the NAME'd processes  are  running
              on  the  agent's  machine.  An error flag (1) and a
              description  message  are  then   passed   to   the
              1.3.6.1.4.1.2021.2.100  and  1.3.6.1.4.1.2021.2.101
              mib tables (respectively) if the NAME'd program  is
              not  found  in  the  process  table  as reported by
              "/bin/ps -e".

              If MAX and MIN are not specified, MAX is assumed to
              be infinity and MIN is assumed to be 1.

              If  MAX  is specified but MIN is not specified, MIN
              is assumed to be 0.

       procfix NAME PROG ARGS
              This registers a command  that  knows  how  to  fix
              errors   with   the   given   process  NAME.   When
              1.3.6.1.4.1.2021.2.102 for a given NAMEd program is
              set to the integer value of 1, this command will be
              called.  It defaults to a compiled value set  using
              the PROCFIXCMD definition in the config.h file.

       exec NAME PROG ARGS

       exec MIBNUM NAME PROG ARGS

              If  MIBNUM is not specified, the agent executes the
              named PROG with arguments of ARGS and  returns  the
              exit status and the first line of the STDOUT output
              of   the   PROG   program   to   queries   of   the
              1.3.6.1.4.1.2021.8.100  and  1.3.6.1.4.1.2021.8.101
              mib  tables  (respectively).   All  STDOUT   output
              beyond the first line is silently truncated.

              If  MIBNUM  is  specified,  it  acts  as  above but
              returns the exit status  to  MIBNUM.100.0  and  the
              entire  STDOUT  output to the table MIBNUM.101 in a
              mib table.  In this case, the MIBNUM.101  mib  con-
              tains the entire STDOUT output, one mib table entry
              per line of output (ie, the first line is output as
              MIBNUM.101.1,  the second at MIBNUM.101.2, etc...).

              Note:  The MIBNUM must be specified in dotted-inte-
                     ger  notation  and  can  not be specified as
                     ".iso.org.dod.internet..."  (should  instead
                     be

              Note:  The  agent caches the exit status and STDOUT
                     of the executed program for 30 seconds after
                     the  initial  query.   This  is  to increase
                     speed and maintain consistency  of  informa-
                     tion  for  consecutive  table  queries.  The
                     cache can be flushed by a  snmp-set  request
                     of  integer(1)  to 1.3.6.1.4.1.2021.100.VER-
                     CLEARCACHE.

       execfix NAME PROG ARGS
              This registers a command  that  knows  how  to  fix
              errors  with  the  given  exec  or  sh  NAME.  When
              1.3.6.1.4.1.2021.8.102 for a given NAMEd  entry  is
              set to the integer value of 1, this command will be
              called.  It defaults to a compiled value set  using
              the EXECFIXCMD definition in the config.h file.

       disk PATH

       disk PATH [ MINSPACE | MINPERCENT% ]

              Checks  the  named disks mounted at PATH for avail-
              able disk space.  If the disk space  is  less  than
              MINSPACE  (kB) if specified or less than MINPERCENT
              (%) if a  %  sign  is  specified,  or  DEFDISKMINI-
              MUMSPACE  (kB)  if  not  specified,  the associated
              entry in the 1.3.6.1.4.1.2021.9.100 mib table  will
              be  set to (1) and a descriptive error message will
              be returned to queries of 1.3.6.1.4.1.2021.9.101.

       load MAX1

       load MAX1 MAX5

       load MAX1 MAX5 MAX15

              Checks the load average of the machine and  returns
              an error flag (1), and an text-string error message
              to   queries   of    1.3.6.1.4.1.2021.10.100    and
              1.3.6.1.4.1.2021.10.101   (respectively)  when  the
              1-minute, 5-minute, or  15-minute  averages  exceed
              the associated maximum values.  If any of the MAX1,
              MAX5, or MAX15 values are unspecified, they default
              to a value of DEFMAXLOADAVE.

       file FILE [MAXSIZE]
              Monitors  file sizes and makes sure they don't grow
              beyond a certain size.  MAXSIZE defaults  to  infi-
              nite  if  not specified, and only monitors the size
              without reporting errors about it.

   Errors
       Any errors in obtaining the above information are reported
       via    the    1.3.6.1.4.1.2021.101.100    flag   and   the
       1.3.6.1.4.1.2021.101.101 text-string description.

SMUX SUB-AGENTS
       To enable and SMUX based sub-agent, such as gated, use the
       smuxpeer configuration entry

       smuxpeer OID PASS
              For gated a sensible entry might be

       .1.3.6.1.4.1.4.1.3 secret

ACCESS CONTROL
       snmpd  supports the View-Based Access Control Model (vacm)
       as defined in RFC 2275.  To this end,  it  recognizes  the
       following  keywords  in  the  configuration file: com2sec,
       group, access, and view  as  well  as  some  easier-to-use
       wrapper   directives:  rocommunity,  rwcommunity,  rouser,
       rwuser.

       rocommunity COMMUNITY [SOURCE] [OID]

       rwcommunity COMMUNITY [SOURCE] [OID]
              These create read-only and  read-write  communities
              that  can  be used to access the agent.  They are a
              quick method of using the following com2sec, group,
              access,  and view directive lines.  They are not as
              efficient either, as groups aren't created  so  the
              tables  are possibly larger.  In other words: don't
              use these if you have complex situations to set up.

              The  format  of the SOURCE is token is described in
              the com2sec directive section below.  The OID token
              restricts  access  for that community to everything
              below that given OID.

       rouser USER [noauth|auth|priv] [OID]

       rwuser USER [noauth|auth|priv] [OID]
              Creates a  SNMPv3  USM  user  in  the  VACM  access
              configuration  tables.   Again,  its more efficient
              (and powerful) to use the combined com2sec,  group,
              access, and view directives instead.

              The minimum level of authentication and privacy the
              user must use  is  specified  by  the  first  token
              (which  defaults  to  "auth").   The  OID parameter
              restricts access for that user to everything  below
              the given OID.

       com2sec NAME SOURCE COMMUNITY
              This   directive   specifies  the  mapping  from  a
              source/community pair to a  security  name.  SOURCE
              can be a hostname, a subnet, or the word "default".
              A subnet can be specified as  IP/MASK  or  IP/BITS.
              The first source/community combination that matches
              the incoming packet is selected.

       group NAME MODEL SECURITY
              This directive defines the mapping  from  security-
              model/securityname  to  group.  MODEL is one of v1,
              v2c, or usm.

       access NAME CONTEXT MODEL LEVEL PREFX READ WRITE NOTIFY
              The  access  directive  maps  from   group/security
              model/security  level  to  a view.  MODEL is one of
              any, v1, v2c, or usm.   LEVEL  is  one  of  noauth,
              auth,  or priv.  PREFX specifies how CONTEXT should
              be matched against the context of the incoming pdu,
              either  exact  or  prefix.   READ, WRITE and NOTIFY
              specifies the view to be used for the corresponding
              access.   For  v1  or  v2c  access,  LEVEL  will be
              noauth, and CONTEXT will be empty.

       view NAME TYPE SUBTREE [MASK]
              The defines the named view. TYPE is either included
              or  excluded.   MASK is a list of hex octets, sepa-
              rated by '.' or ':'.  The MASK defaults to "ff"  if
              not specified.

              The  reason  for the mask is, that it allows you to
              control access to one row in a table,  in  a  rela-
              tively  simple  way.  As  an example, as an ISP you
              might consider giving each customer access  to  his
              or her own interface:

              view cust1 included interfaces.ifTable.ifEntry.ifIndex.1 ff.a0
              view cust2 included interfaces.ifTable.ifEntry.ifIndex.2 ff.a0

              (interfaces.ifTable.ifEntry.ifIndex.1 == .1.3.6.1.2.1.2.2.1.1.1,
              ff.a0 == 11111111.10100000. which nicely covers up and including
              the row index, but lets the user vary the field of the row)

       VACM Examples:
              #       sec.name  source          community
              com2sec local     localhost       private
              com2sec mynet     10.10.10.0/24   public
              com2sec public    default         public

              #             sec.model  sec.name
              group mygroup v1         mynet
              group mygroup v2c        mynet
              group mygroup usm        mynet
              group local   v1         local
              group local   v2c        local
              group local   usm        local
              group public  v1         public
              group public  v2c        public
              group public  usm        public

              #           incl/excl subtree                          mask
              view all    included  .1                               80
              view system included  system                           fe
              view mib2   included  .iso.org.dod.internet.mgmt.mib-2 fc

              #              context sec.model sec.level prefix read   write notify
              access mygroup ""      any       noauth    exact  mib2   none  none
              access public  ""      any       noauth    exact  system none  none
              access local   ""      any       noauth    exact  all    all   all

       Default VACM model
              The default configuration of the agent, as shipped, is functionally
              equivalent to the following entries:
              com2sec   public    default   public
              group     public    v1   public
              group     public    v2c  public
              group     public    usm  public
              view      all  included  .1
              access    public    ""   any  noauth    exact     all  none none

SNMPv3 CONFIGURATION
       engineID STRING
              The  snmpd  agent  needs  to  be configured with an
              engineID to be able to respond to SNMPv3  messages.
              With  this  configuration  file  line, the engineID
              will be configured from STRING.  The default  value
              of  the  engineID  is  configured with the first IP
              address found for the hostname of the machine.

       createUser username (MD5|SHA) authpassphrase [DES]  [priv-
       passphrase]
              This directive should be placed into the "/var/ucd-
              snmp"/snmpd.conf  file  instead of the other normal
              locations.  The reason is that the  information  is
              read  from  the  file  and then the line is removed
              (eliminating the storage of the master password for
              that  user)  and  replaced  with  the  key  that is
              derived from it.  This key is a localized  key,  so
              that  if  it is stolen it can not be used to access
              other agents.  If the password is stolen,  however,
              it can be.

              MD5  and  SHA  are the authentication types to use,
              but you must have built the  package  with  openssl
              installed  in  order  to use SHA.  The only privacy
              protocol currently supported is DES.  If  the  pri-
              vacy  passphrase is not specified, it is assumed to
              be the same as the authentication passphrase.  Note
              that  the users created will be useless unless they
              are also added to the VACM  access  control  tables
              described above.

              Warning:  the minimum pass phrase length is 8 char-
              acters.

              SNMPv3 users can be created at  runtime  using  the
              snmpusm command.


SETTING SYSTEM INFORMATION
       syslocation STRING

       syscontact STRING

              Sets the system location and the system contact for
              the agent.  This information  is  reported  by  the
              'system' table in the mibII tree.

       authtrapenable NUMBER
              Setting  authtrapenable  to 1 enables generation of
              authentication failure traps. The default value  is
              2 (disable).

       trapcommunity STRING
              This  defines  the  default  community string to be
              used when sending traps.  Note  that  this  command
              must  be  used  prior to any of the following three
              commands  that  are  intended  use  this  community
              string.

       trapsink HOST [COMMUNITY [PORT]]

       trap2sink HOST [COMMUNITY [PORT]]

       informsink HOST [COMMUNITY [PORT]]
              These  commands  define  the hosts to receive traps
              (and/or inform notifications). The daemon  sends  a
              Cold  Start  trap when it starts up. If enabled, it
              also sends traps on authentication failures.   Mul-
              tiple  trapsink, trap2sink and informsink lines may
              be specified to specify multiple destinations.  Use
              trap2sink  to  send  SNMPv2 traps and informsink to
              send inform notifications.   If  COMMUNITY  is  not
              specified,  the  string from a preceding trapcommu-
              nity directive will be used. If PORT is not  speci-
              fied,  the  well known SNMP trap port (162) will be
              used.

PASS-THROUGH CONTROL
       pass MIBOID EXEC
              Passes entire control of MIBOID to  the  EXEC  pro-
              gram.   The  EXEC  program  is called in one of the
              following three ways:

              EXEC -g MIBOID

              EXEC -n MIBOID

                     These call lines match to SNMP get and  get-
                     next requests.  It is expected that the EXEC
                     program will take the arguments passed to it
                     and  return the appropriate response through
                     it's stdout.

                     The first line of stdout should be  the  mib
                     OID of the returning value.  The second line
                     should be the TYPE of value returned,  where
                     TYPE  is  one  of  the text strings: string,
                     integer,  unsigned,   objectid,   timeticks,
                     ipaddress,  counter,  or  gauge.   The third
                     line of stdout should be  the  VALUE  corre-
                     sponding with the returned TYPE.

                     For  instance, if a script was to return the
                     value integer value "42" when a request  for
                     .1.3.6.1.4.100  was  requested,  the  script
                     should return the following 3 lines:
                       .1.3.6.1.4.100
                       integer
                       42

                     To indicate that the  script  is  unable  to
                     comply with the request due to an end-of-mib
                     condition or an invalid request, simple exit
                     and  return  no  output to stdout at all.  A
                     snmp error will be  generated  corresponding
                     to the SNMP NO-SUCH-NAME response.

              EXEC -s MIBOID TYPE VALUE

                     For SNMP set requests, the above call method
                     is used.  The TYPE passed to the  EXEC  pro-
                     gram  is  one  of the text strings: integer,
                     counter, gauge, timeticks, ipaddress, objid,
                     or  string,  indicating  the  type  of value
                     passed in the next argument.

                     Return nothing to stdout, and the  set  will
                     assumed to have been successful.  Otherwise,
                     return one of the following error strings to
                     signal an error: not-writable, or wrong-type
                     and the appropriate error response  will  be
                     generated instead.

                      Note:  By   default,   the  only  community
                             allowed to  write  (ie  snmpset)  to
                             your  script  will  be the "private"
                             community,or community #2 if defined
                             differently by the "community" token
                             discussed above.  Which  communities
                             are  allowed  write  access are con-
                             trolled by the RWRITE definition  in
                             the snmplib/snmp_impl.h source file.

EXAMPLE
       See the EXAMPLE.CONF file in the top level  source  direc-
       tory for a more detailed example of how the above informa-
       tion is used in real examples.

RE-READING snmpd.conf and snmpd.local.conf
       The ucd-snmp agent can be forced to re-read its configura-
       tion files.  It can be told to do so by one of two ways:

       1.     An       snmpset       of       integer(1)       to
              1.3.6.1.4.1.2021.100.VERUPDATECONFIG.

       2.     A "kill -HUP" signal sent to the snmpd  agent  pro-
              cess.

FILES
       share/snmp/snmpd.conf

SEE ALSO
       snmp_config(5), snmpd(1), EXAMPLE.conf, read_config(3).



                           27 Jan 2000              SNMPD.CONF(5)


]]>妙解网络多台dhcp引起的IP冲突 http://www.blogjava.net/hellboys/archive/2006/11/15/81181.html地狱男爵(hellboys)地狱男爵(hellboys)Wed, 15 Nov 2006 02:22:00 GMThttp://www.blogjava.net/hellboys/archive/2006/11/15/81181.htmlhttp://www.blogjava.net/hellboys/comments/81181.htmlhttp://www.blogjava.net/hellboys/archive/2006/11/15/81181.html#Feedback1http://www.blogjava.net/hellboys/comments/commentRss/81181.htmlhttp://www.blogjava.net/hellboys/services/trackbacks/81181.html
　　那么我们的问题也出现了:常见的，很多用户抱怨用这种方法上不了网，但不是所有客户都上不了网。经过调查发现，住宾馆、酒店的人绝大多数是商务人员和工程师，他们携带的手提电脑一般安装的是Windows server版本，server版本默认启动了DHCP server功能，当一台这样的计算机连入网络，在他之后的计算机就会把他当成DHCP服务器，并被分配了不正确的IP地址，从而上不了网。

　　DHCP服务器地址分配方式

　　DHCP是一种用于简化主机IP配置管理的协议标准。通过采用DHCP标准，可以使用DHCP服务器为网络上所有启用了DHCP的客户端分配、配置、跟踪和更改(必要时)所有TCP/IP设置。此外，DHCP还可以确保不使用重复地址、重新分配未使用的地址，并且可以自动为主机连接的子网分配适当的IP地址。当一个网络中，有2个或2个以上的DHCP服务器时，提醒切勿将DHCP地址池定义的过大，以免多个地址池之间出现“包含于”的关系，或者是部分客户端手工指定的IP地址包含于DHCP服务器的地址池中，从而造成DHCP的一些异常故障。

　　针对不同的需求，DHCP服务器有三种机制分配IP地址:

　　自动分配 DHCP服务器给首次连接到网络的某些客户端分配固定IP地址，该地址由用户长期使用;

　　动态分配 DHCP服务器给客户端分配有时间限制的IP地址，使用期限到期后，客户端需要重新申请地址，客户端也可以主动释放该地址。绝大多数客户端主机得到的是这种动态分配的地址;

　　手动分配 由网络管理员为客户端指定固定的IP地址。

　　三种地址分配方式中，只有动态分配可以重复使用客户端不再需要的地址。

　　每项技术都是有利有弊的，DHCP也不例外，由于DHCP有着配置简单，管理方便的优点，问题也随之产生，由于DHCP的运作机制，通常服务器和客户端没有认证机制，如果网络上存在多台DHCP服务器将会给网络造成混乱。由于用户不小心配置了DHCP服务器引起的网络混乱非常常见，足可见此问题的普遍性。

　　本人在从事网络工作的几年里，遇到过很多问题，其中有关DHCP-server冲突的不在少数，在解决问题的同时也总结了一些经验，在这里简单介绍一下，与大家分享，希望给在解决此类问题的同行一些帮助，也希望广大高手指出其中的不足和需要改进的地方。

DHCP服务器冲突的解决方法

　　使用DHCP snooping技术来解决

　　针对这种DHCP服务器冲突的解决方法有很多，最直接的方法就是贴告示，让入住的客户在上网时关闭Windows的DHCP网络服务，这个选项在‘控制面板’，‘管理工具’里的‘DHCP网络服务’，进入关闭即可。这里要注意的是，非server版的Windows不用关闭，并且不要把‘控制面板’，‘管理工具’，‘服务’中的DHCP client给停止了，这样是分配不到地址的。

　　当然上面的方法比较被动也不合常理，更不便于我们网络的管理，所以还是应该从我们网络本身出发来解决问题。

　　既然是DHCP的问题，那么我们就用DHCP的技术来解决问题，比较有代表的就是DHCP snooping技术。DHCP snooping技术是DHCP安全特性，通过建立和维护DHCP snooping绑定表过滤不可信任的DHCP信息，这些信息是指来自不信任区域的DHCP信息。DHCP snooping绑定表包含不信任区域的用户mac地址、IP地址、租用期、vlan-id接口等信息。

　　首先定义交换机上的信任端口和不信任端口，其中信任端口连接DHCP服务器或其他交换机的端口;不信任端口连接用户或网络。不信任端口将接收到的DHCP服务器响应的DHCP ack 和DHCP off报文丢弃;而信任端口将此配置中的命令都是以CISCO的设备为基础，但不管是哪个公司的设备，总体设计思想是一致的，不同的可能在命令格式上略有差异，工作人员应该根据具体的实际情况来解决相应的问题。

　　在全局模式下启动DHCP snooping功能，这个默认是关闭的，而且不是所有设备都支持这个功能，最好先看使用说明。

　　switch(config)#ip dhcp-snooping

　　如果有vlan就使用下面的命令来监测具体的vlan

　　switch(config)#ip dhcp-snooping vlan vlan-id

　　然后定义可信任的端口，默认情况交换机的端口均为不信任端口，通常网络设备接口， TRUNK 接口和连接DHCP服务器的端口定义为可信任端口。

　　switch(config)#int f0/x

　　switch(config-if)#ip dhcp snooping trust

使用PVLAN技术来解决

　　有很多二层的技术可以防止DHCP-server冲突的，PVLAN就是其中一个运用比较广的技术。

　　PVLAN私有局域网(private vlan)，在PVLAN的概念里，端口有3种类型:Isolated port，Community port, Promiscuous port;它们分别对应不同的vlan类型:Isolated port属于Isolated PVLAN，Community port属于Community PVLAN，而代表一个Private vlan整体的是Primary vlan，前面两类vlan需要和它绑定在一起，同时它还包括Promiscuous port。在Isolated PVLAN中，Isolated port只能和Promiscuous port，彼此之间不能访问;在Community PVLAN中，vlan与vlan之间都不能访问，同一Community vlan的接口可以互相访问，并且所有Community vlan的接口都可以与Promiscuous port进行通信。利用这项技术，我们可以把上连或连接DHCP服务器的接口定义为Promiscuous port，其他接口分配到Isolated vlan里，这样所有接口都只能与上连或DHCP服务器进行通信，即使有一台机器设为DHCP服务器，其他机器也不会与它产生流量，把它做为服务器。

　　利用这个技术解决DHCP-server冲突的方法有很多，也很灵活，下面介绍一种比较简单的方法，也是用的比较多的:

　　首先把交换机配置成transparents模式:　　

　　switch(config)#vtp mode transparent

　　顺便可以打开端口的保护功能，它的意思是打开端口保护的端口之间不能访问，但打开保护的端口可以与没有开启此项功能的端口通信，可以根据自己的需求来打开保护功能:

　　switch(config)#int range f0/124

　　switch(config-if-range)#switchitchport protected

　　建立isolated vlan和primary vlan，把isolated vlan定义为primary lan的附属vlan，因为要与primary互相访问:

　　switch(config)#vlan 14

　　switch(config-vlan)private-vlan isolated

　　switch(config)#vlan 44

　　switch(config-vlan)#private-vlan primary

　　switch(config-vlan)#private-vlan association 14


]]>不得不笑！ 上班时什么人听什么音乐!!http://www.blogjava.net/hellboys/archive/2006/10/20/76405.html地狱男爵(hellboys)地狱男爵(hellboys)Fri, 20 Oct 2006 08:21:00 GMThttp://www.blogjava.net/hellboys/archive/2006/10/20/76405.htmlhttp://www.blogjava.net/hellboys/comments/76405.htmlhttp://www.blogjava.net/hellboys/archive/2006/10/20/76405.html#Feedback1http://www.blogjava.net/hellboys/comments/commentRss/76405.htmlhttp://www.blogjava.net/hellboys/services/trackbacks/76405.html

 

真的很不错呢！转载过来和大家一起分享！



我是一个普通的中层领导,每天有条有序的工作,顺便听听能使人放松的流行音乐...

 

我们的老板就不一样了,他很喜欢听节奏感很强的舞曲..

 

隔壁的小王是个很激进的年轻人..他喜欢听朋克..


 

董事长是个有生活有故事的人...没事总带两张古典唱片..


 

总监活着比较累,听音乐的时候还要看着大家干没干活儿...


 

对面新来的小伙子总是边听着嘻哈音乐边打字..


 

副总长相比较深沉,但其实他只听刀郎和火风...


 

市场部的小伙子总是出差,听音乐的时候表情像ET..压力比较大吧

 

技术部的同事压力也是比较大的那种..听音乐的时候动作比较亢奋..


 

底层的销售人员他们通常爱听重金属音乐,时不时放两声开开嗓子..

 

财务部的会计老张记帐的时候总爱听茉莉花..


 

美工MM是个哈日的小女孩..听着宇多田还要仔细盯着电脑做图..


．．．．．．

．．．．．．

．．．．．．

下班了..大家共同的爱好就是看看A片什么的..






]]>P2P之UDP穿透NAT的原理与实现http://www.blogjava.net/hellboys/archive/2006/09/13/69263.html地狱男爵(hellboys)地狱男爵(hellboys)Tue, 12 Sep 2006 16:32:00 GMThttp://www.blogjava.net/hellboys/archive/2006/09/13/69263.htmlhttp://www.blogjava.net/hellboys/comments/69263.htmlhttp://www.blogjava.net/hellboys/archive/2006/09/13/69263.html#Feedback1http://www.blogjava.net/hellboys/comments/commentRss/69263.htmlhttp://www.blogjava.net/hellboys/services/trackbacks/69263.htmlP2P之UDP穿透NAT的原理与实现 - 增强篇(附修改过的源代码)

------------------------------------------------------------------------------------------------------------

NAT(The IP Network Address Translator) 的概念和意义是什么?

NAT, 中文翻译为网络地址转换。具体的详细信息可以访问RFC 1631 - http://www.faqs.org/rfcs/rfc1631.html, 这是对于NAT的定义和解释的最权威的描述。网络术语都是很抽象和艰涩的，除非是专业人士，否则很难从字面中来准确理解NAT的含义。

要想完全明白NAT 的作用，我们必须理解IP地址的两大分类，一类是私有IP地址，在这里我们称作内网IP地址。一类是非私有的IP地址，在这里我们称作公网IP地址。关于IP地址的概念和作用的介绍参见我的另一篇文章: http://hwycheng.blogchina.com/2402121.html

内网IP地址: 是指使用A/B/C类中的私有地址, 分配的IP地址在全球不惧有唯一性，也因此无法被其它外网主机直接访问。
公网IP地址: 是指具有全球唯一的IP地址，能够直接被其它主机访问的。

NAT 最初的目的是为使用内网IP地址的计算机提供通过少数几台具有公网的IP地址的计算机访问外部网络的功能。NAT 负责将某些内网IP地址的计算机向外部网络发出的IP数据包的源IP地址转换为NAT自己的公网的IP地址，目的IP地址不变, 并将IP数据包转发给路由器，最终到达外部的计算机。同时负责将外部的计算机返回的IP数据包的目的IP地址转换为内网的IP地址，源IP地址不变，并最 终送达到内网中的计算机。
                                                
        ----------------------                           ----------------------              
        | 192.168.0.5        |  Internat host            | 192.168.0.6        |  Internat host
        ----------------------                           ----------------------              
                ^ port:2809                                      ^port: 1827                           
                |                                                |                           
                V                                                V                           
        ----------------------                           ----------------------              
        | 192.168.0.1        | NAT device                | 192.168.0.2        | NAT device   
        | 61.51.99.86        |                           | 61.51.77.66        |              
        ----------------------                           ----------------------              
                ^                                                ^                           
                |                                                |                           
                V port:80                                        V port: 80                          
        ----------------------                           ----------------------              
        | 61.51.202.88       | Internet host             | 61.51.76.102       | Internet host
        ----------------------                           ----------------------              
                                                           
                              图一: NAT 实现了私有IP的计算机分享几个公网IP地址访问Internet的功能。
                             
随 着网络的普及，IPv4的局限性暴露出来。公网IP地址成为一种稀缺的资源，此时NAT 的功能局限也暴露出来，同一个公网的IP地址，某个时间只能由一台私有IP地址的计算机使用。于是NAPT(The IP Network Address/Port Translator)应运而生，NAPT实现了多台私有IP地址的计算机可以同时通过一个公网IP地址来访问Internet的功能。这在很大程度上暂 时缓解了IPv4地址资源的紧张。

NAPT 负责将某些内网IP地址的计算机向外部网络发出的TCP/UDP数据包的源IP地址转换为NAPT自己的公网的IP地址，源端口转为NAPT自己的一个端 口。目的IP地址和端口不变, 并将IP数据包发给路由器，最终到达外部的计算机。同时负责将外部的计算机返回的IP数据包的目的IP地址转换内网的IP地址，目的端口转为内网计算机的 端口，源IP地址和源端口不变，并最终送达到内网中的计算机。

                                                
                ----------------------                           ----------------------              
                | 192.168.0.5        |  Internat host            | 192.168.0.6        |  Internat host
                ----------------------                           ----------------------              
                        port: 2809      ^                   ^ port: 1827
                                         \                 /
                                          v               v                            
                                        ----------------------           
                                        | 192.168.0.1        | NAT device
                                        | 61.51.99.86        |           
                                        ----------------------                                 
        map port:9882 to 192.168.0.5:2809 ^              ^ map port: 9881 to 192.168.0.6:1827
                                         /                \
                             port:80    v                  v    port:80                        
                ----------------------                           ----------------------              
                | 61.51.202.88       | Internet host             | 61.51.76.102       | Internet host
                ----------------------                           ----------------------                                
                               
                              图二: NAPT 实现了私有IP的计算机分享一个公网IP地址访问Internet的功能。                                            
 
在 我们的工作和生活中, NAPT的作用随处可见，绝大部分公司的网络架构，都是通过1至N台支持NAPT的路由器来实现公司的所有计算机连接外部的Internet网络的。包括 本人在写这篇文章的时候，也是在家中使用一台IBM笔记本通过一台宽带连接的台式机来访问Internet的。我们本篇文章主要讨论的NAPT的问题。

NAPT(The IP Network Address/Port Translator) 为何阻碍了P2P软件的应用?

通 过NAPT 上网的特点决定了只能由NAPT内的计算机主动向NAPT外部的主机发起连接，外部的主机想直接和NAPT内的计算机直接建立连接是不被允许的。IM(即 时通讯)而言，这意味着由于NAPT内的计算机和NAPT外的计算机只能通过服务器中转数据来进行通讯。对于P2P方式的下载程序而言，意味着NAPT内 的计算机不能接收到NAPT外部的连接，导致连接数用过少，下载速度很难上去。因此P2P软件必须要解决的一个问题就是要能够在一定的程度上解决NAPT 内的计算机不能被外部连接的问题。

NAT(The IP Network Address Translator) 进行UDP穿透的原理是什么?

TCP/IP 传输时主要用到TCP和UDP协议。TCP协议是可靠的，面向连接的传输协议。UDP是不可靠的，无连接的协议。根据TCP和UDP协议的实现原理，对于 NAPT来进行穿透，主要是指的UDP协议。TCP协议也有可能，但是可行性非常小，要求更高，我们此处不作讨论，如果感兴趣可以到Google上搜索， 有些文章对这个问题做了探讨性的描述。下面我们来看看利用UDP协议来穿透NAPT的原理是什么:

                        ----------------------                           ----------------------              
                        | 192.168.0.5        |  Internat host            | 192.168.0.6        |  Internat host
                        ----------------------                           ----------------------              
                          UDP port: 2809        ^                   ^ UDP port: 1827
                                                 \                 /
                                                  v               v                            
                                                ----------------------           
                                                | 192.168.0.1        | NAT device
                                                | 61.51.99.86        |           
                                                ----------------------                                 
  Session(192.168.0.6:1827 <-> 61.51.76.102:8098) ^              ^ Session(192.168.0.6:1827 <-> 61.51.76.102:8098)
               map port:9882 to 192.168.0.5:2809 /                \map port: 9881 to 192.168.0.6:1827
                                  UDP port:8098 v                  v    UDP port:8098                          
                        ----------------------                           ----------------------              
                        | 61.51.202.88       | Internet host             | 61.51.76.102       | Internet host
                        ----------------------                           ----------------------                
                                                       
                                       
                                      图三: NAPT 是如何将私有IP地址的UDP数据包与公网主机进行透明传输的。

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的实现还会根据设备的忙碌状态进行智能 计算超时时间的长短。

                  [192.168.0.6:1827]
                            | UDP Packet[src ip:192.168.0.6 src port:1827 dst ip:61.51.76.102 dst port 8098]
                            v
        [pub ip: 61.51.99.86]NAT[priv ip: 192.168.0.1]
                            | UDP Packet[src ip:61.51.99.86 src port:9881 dst ip:61.51.76.102 dst port 8098]
                            v                  
                  [61.51.76.102:8098]
                 
                                    图四: NAPT 将内部发出的UDP协议包的源地址和源端口改变传输给公网IP主机。
                                   
                                   
                  [192.168.0.6:1827]
                            ^
                            | UDP Packet[src ip:61.51.76.102 src port:8098 dst ip:192.168.0.6 dst port 1827]
        [pub ip: 61.51.99.86]NAT[priv ip: 192.168.0.1]
                            ^  
                            | UDP Packet[src ip:61.51.76.102 src port:8098 dst ip:61.51.99.86 dst port 9881]   
                  [61.51.76.102:8098]
                 
                                    图五: NAPT 将收到的公网IP主机返回的UDP协议包的目的地址和目的端口改变传输给内网IP计算机。                               
现在我们大概明白了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.

        [202.223.98.78:9696] [202.223.98.78:9696] [202.223.98.78:9696]
                ^               ^                       ^
                |               |                       |
                v               v                       v
               9883            9882                    9881
                                 |
                             \ [NAT] /
                                 ^
                                 |
                                 v                       
                          [192.168.0.6:1827]
                         
                          图六: Symmetric 的英文意思是对称。多个端口对应多个主机，平行的，对称的!
                 
Cone NAPT:
对于到同一个IP地址，任意端口的连接分配使用同一个Session; 对于到不同的IP地址，任意端口的连接也使用同一个Session.
我们称此种NAPT为 Cone NAPT. 也就是只要本地绑定的UDP端口相同， 发出的目的地址不管是否相同， 都使用同一个Session.

        [202.223.98.78:9696] [202.223.98.78:9696] [202.223.98.78:9696]

                        ^          ^         ^
                         \         |        /
                          v        v       v
                                 9881
                                 [NAT]
                                   ^
                                   |
                                   v                     
                          [192.168.0.6:1827]
                         
                          图七: Cone 的英文意思是锥。一个端口对应多个主机，是不是像个锥子?

现 在绝大多数的NAPT属于后者，即Cone NAT。本人在测试的过程中，只好使用了一台日本的Symmetric NAT。还好不是自己的买的，我从不买日货, 希望看这篇文章的朋友也自觉的不要购买日本的东西。Win9x/2K/XP/2003系统自带的NAPT也是属于 Cone NAT的。这是值的庆幸的，因为我们要做的UDP穿透只能在Cone NAT间进行，只要有一台不是Cone NAT，对不起，UDP穿透没有希望了，服务器转发吧。后面会做详细分析!

下面我们再来分析一下NAPT 工作时的一些数据结构，在这里我们将真正说明UDP可以穿透Cone NAT的依据。这里描述的数据结构只是为了说明原理，不具有实际参考价值，真正感兴趣可以阅读Linux的中关于NAT实现部分的源码。真正的NAT实现 也没有利用数据库的，呵呵，为了速度！

Symmetric NAPT 工作时的端口映射数据结构如下:

内网信息表:

[NAPT 分配端口] [ 内网IP地址 ] [ 内网端口 ] [ 外网IP地址 ] [ SessionTime 开始时间 ]

PRIMARY KEY( [NAPT 分配端口] ) -> 表示依据[NAPT 分配端口]建立主键，必须唯一且建立索引，加快查找.
UNIQUE( [ 内网IP地址 ], [ 内网端口 ] ) -> 表示这两个字段联合起来不能重复.
UNIQUE( [ 内网IP地址 ], [ 内网端口 ], [ 外网IP地址 ] ) -> 表示这三个字段联合起来不能重复.

映射表:

[NAPT 分配端口] [ 外网端口 ]

UNIQUE( [NAPT 分配端口], [ 外网端口 ] ) -> 表示这两个字段联合起来不能重复.

Cone NAPT 工作时的端口映射数据结构如下:

内网信息表:

[NAPT 分配端口] [ 内网IP地址 ] [ 内网端口 ] [ SessionTime 开始时间 ]

PRIMARY KEY( [NAPT 分配端口] ) -> 表示依据[NAPT 分配端口]建立主键，必须唯一且建立索引，加快查找.
UNIQUE( [ 内网IP地址 ], [ 内网端口 ] ) -> 表示这两个字段联合起来不能重复.

外网信息表:

[ wid 主键标识 ] [ 外网IP地址 ] [ 外网端口 ]

PRIMARY KEY( [ wid 主键标识 ] ) -> 表示依据[ wid 主键标识 ]建立主键，必须唯一且建立索引，加快查找.
UNIQUE( [ 外网IP地址 ], [ 外网端口 ] ) -> 表示这两个字段联合起来不能重复.

映射表: 实现一对多，的

[NAPT 分配端口] [ wid 主键标识 ]

UNIQUE( [NAPT 分配端口], [ wid 主键标识 ] ) -> 表示这两个字段联合起来不能重复.
UNIQUE( [ wid 主键标识 ] ) -> 标识此字段不能重复.

看完了上面的数据结构是更明白了还是更晕了？ 呵呵! 多想一会儿就会明白了。通过NAT,内网计算机计算机向外连结是很容易的，NAPT会自动处理，我们的应用程序根本不必关心它是如何处理的。那么外部的计算机想访问内网中的计算机如何实现呢？我们来看一下下面的流程：

c 是一台在NAPT后面的内网计算机，s是一台有外网IP地址的计算机。c 主动向 s 发起连接请求，NAPT依据上面描述的规则在自己的数据结构中记录下来，建立一个Session. 然后 c 和 s 之间就可以实现双向的透明的数据传输了。如下面所示:

   c[192.168.0.6:1827] <-> [priv ip: 192.168.0.1]NAPT[pub ip: 61.51.99.86:9881] <-> s[61.51.76.102:8098]

由 此可见，一台外网IP地址的计算机想和NAPT后面的内网计算机通讯的条件就是要求NAPT后面的内网计算机主动向外网IP地址的计算机发起一个UDP数 据包。外网IP地址的计算机利用收到的UDP数据包获取到NAPT的外网IP地址和映射的端口，以后就可以和内网IP的计算机透明的进行通讯了。
   
现 在我们再来分析一下我们最关心的两个NAPT后面的内网计算机如何实现直接通讯呢? 两者都无法主动发出连接请求，谁也不知道对方的NAPT的公网IP地址和NAPT上面映射的端口号。所以我们要靠一个公网IP地址的服务器帮助两者来建立 连接。当两个NAPT后面的内网计算机分别连接了公网IP地址的服务器后，服务器可以从收到的UDP数据包中获取到这两个NAPT设备的公网IP地址和这 两个连接建立的Session的映射端口。两个内网计算机可以从服务器上获取到对方的NAPT设备公网IP地址和映射的端口了。

我们假设两个内网计算机分别为A和B，对应的NAPT分别为AN和BN， 如果A在获取到B对应的BN的IP地址和映射的端口后，迫不急待的向这个IP
地 址和映射的端口发送了个UDP数据包，会有什么情况发生呢？依据上面的原理和数据结构我们会知道，AN会在自己的数据结构中生成一条记录，标识一个新 Session的存在。BN在收到数据包后，从自己的数据结构中查询，没有找到相关记录，因此将包丢弃。B是个慢性子，此时才慢吞吞的向着AN的IP地址 和映射的端口发送了一个UDP数据包，结果如何呢？当然是我们期望的结构了，AN在收到数据包后，从自己的数据结构中查找到了记录，所以将数据包进行处理 发送给了A。A 再次向B发送数据包时，一切都时畅通无阻了。OK, 大工告成！且慢，这时对于Cone NAPT而言，对于Symmetric NAPT呢？呵呵，自己分析一下吧...

NAPT(The IP Network Address/Port Translator) 进行UDP穿透的具体情况分析!

首先明确的将NAPT设备按照上面的说明分为: Symmetric NAPT 和 Cone NAPT, Cone NAPT 是我们需要的。Win9x/2K/XP/2003 自带的NAPT也为Cone NAPT。

第一种情况, 双方都是Symmetric NAPT:

此情况应给不存在什么问题，肯定是不支持UDP穿透。

第二种情况, 双方都是Cone NAPT:

此情况是我们需要的，可以进行UDP穿透。

第三种情况, 一个是Symmetric NAPT, 一个是Cone NAPT:

此情况比较复杂，但我们按照上面的描述和数据机构进行一下分析也很容易就会明白了, 分析如下,

假设: A -> Symmetric NAT, B -> Cone NAT

1. A 想连接 B, A 从服务器那儿获取到 B 的NAT地址和映射端口, A 通知服务器，服务器告知 B A的NAT地址和映射端口, B 向 A 发起连接，A 肯定无法接收到。此时 A 向 B 发起连接， A 对应的NAT建立了一个新的Session，分配了一个新的映射端口， B 的 NAT 接收到UDP包后，在自己的映射表中查询，无法找到映射项，因此将包丢弃了。

2. B 想连接 A, B 从服务器那儿获取到 A 的NAT地址和映射端口, B 通知服务器, 服务器告知 A B的NAT地址和映射端口,A 向 B 发起连接, A 对应的NAT建立了一个新的Session，分配了一个新的映射端口B肯定无法接收到。此时 B 向 A 发起连接, 由于 B 无法获取 A 建立的新的Session的映射端口，仍是使用服务器上获取的映射端口进行连接， 因此 A 的NAT在接收到UDP包后，在自己的映射表中查询，无法找到映射项, 因此将包丢弃了。

根据以上分析，只有当连接的两端的NAT都为Cone NAT的情况下，才能进行UDP的内网穿透互联。


NAPT(The IP Network Address/Port Translator) 进行UDP穿透如何进行现实的验证和分析!

需要的网络结构如下:

三个NAT后面的内网机器，两个外网服务器。其中两台Cone NAPT，一台 Symmetric NAPT。

验证方法:

可 以使用本程序提供的源码，编译，然后分别运行服务器程序和客户端。修改过后的源码增加了客户端之间直接通过IP地址和端口发送消息的命令，利用此命令，你 可以手动的验证NAPT的穿透情况。为了方便操作，推荐你使用一个远程登陆软件，可以直接在一台机器上操作所有的相关的计算机