jedellnniu さんのプロフィールWelcome my space's@jedel...フォトブログリストその他 ツール ヘルプ

Welcome my space's@jedellniu

challenging and fighting,Nevermore to say no!

動画

 
感谢访问!
しばらくお待ちください。
入力されたコメントは長すぎます。短くしてください。
何も入力されていません。もう一度やり直してください。
現在、コメントを追加できません。後でもう一度やり直してください。
コメントと書くには、保護者 (ほごしゃ) の方の許可 (きょか) をもらってください。許可をリクエストする
保護者 (ほごしゃ) の方が、あなたがコメントを書けないようにしています。
現在、コメントを削除できません。後でもう一度やり直してください。
1 日に投稿できるコメントの最大数を超えました。24 時間経過してから、もう一度やり直してください。
あなたが他のユーザーに対して迷惑行為を行っている可能性があると確認されたため、お使いのアカウントによるコメントの投稿を無効にしています。誤って無効にされたと思われる場合は、Windows Live のサポートにお問い合わせください。
コメントを投稿する前に、以下のセキュリティ チェックを完了してください。
セキュリティ チェックに入力する文字は、画像に表示されている文字または音声で流れた文字と一致していなければいけません。
沈 蔚媛さんの投稿:
哈哈  牛牛生日快乐啊  你生日可真大~  不亏是牛啊 我更喜欢牛市  嘿嘿
3 月 5 日
jedellnniuさんの投稿:
微笑
今天是自己的生日了,
还在上班没放假, 给自己留言,
审级鼓励与所有的失败~! 以增强以后一个顽强的自我~!
也祝广大朋友元宵节快乐,
希望2008年里我们大家都能有好的发展前景,
也祝福所有的家人健康幸福快乐~``````
2 月 21 日
3月10日

msn新病毒_各位大侠请指教

msn新病毒: 每当我开机登陆msn的时候, msn自动发心信息给我的msn上的好友, 真是烦啊~!````` 天天都是这样```类似以前qq尾巴, 前段文字为汉字,后面跟带一个网址;  这个病毒是我上中国缘那个网站www.meet8.com以后就天天这样子了~```, 开机开msn就自动给msn上的在线用户发信息, 烦死人了~!
    
信息内容为:     "加入,送股,试试。顺便帮我刷点分   http://www.life365world.org "
                   " 大家08年事业顺心, 人顺财顺事事顺~`````
                   http://www.meet8.com/member/regist_stock.html?inviterid=2477004&invitertype=42"

                   "好啊.. 想死你么了..
                   http://www.meet8.com/member/regist_stock.html?inviterid=2477004&invitertype=42"

                   "这是我中国缘的空间.你有吗?有的别忘记告诉我啊!
                   http://www.meet8.com/member/regist_stock.html?inviterid=2477004&invitertype=42"

                   "这是我中国缘的空间.你有吗?有的别忘记告诉我啊!
                   http://www.meet8.com/member/regist_stock.html?inviterid=2477004&invitertype=42    "
 
在网上找了也没找到能够解决的方法, 火急啊~~````` 求大侠们帮忙啊~~!!!!!!!
自己通过以下三种方法解决都无济于事``````   
      1) 360安全卫士通杀   2)卡巴7.0注册版通杀  3)自己在系统注册表里搜索相关信息内容删除 
这三部都做过了还是不起作用, 发贴敬请各位大哥大侠们帮忙啊~!!!!!!
1月30日

IETF RC 1213/RFC1213 MIB-Ⅱ

发表于:2008年1月8日 13时19分38秒阅读(0)评论(0)特效:[图]
本文链接: http://user.qzone.qq.com/249433686/blog/1199769578
IETF RFC 1213/RFC1213
链接地址: http://www.rfc-archive.org/getrfc.php?rfc=1213
IETF RFC 1213 / RFC1213
 Management Information Base for Network Management of TCP/IP-based internets:MIB-II
Network Working Group                                      K. McCloghrie
Request for Comments: 1213                      Hughes LAN Systems, Inc.
Obsoletes: RFC 1158                                              M. Rose
                                       Performance Systems International
                                                                 Editors
                                                              March 1991

           Management Information Base for Network Management
                       of TCP/IP-based internets:
                                 MIB-II
 Status of this Memo
   This memo defines the second version of the Management Information
   Base (MIB-II) for use with network management protocols in TCP/IP-
   based internets.  This RFC specifies an IAB standards track protocol
   for the Internet community, and requests discussion and suggestions
   for improvements.  Please refer to the current edition of the "IAB
   Official Protocol Standards" for the standardization state and status
   of this protocol.  Distribution of this memo is unlimited.
 Table of Contents
   1. Abstract...............................................    2
   2. Introduction ..........................................    2
   3. Changes from RFC 1156 .................................    3
   3.1 Deprecated Objects ...................................    3
   3.2 Display Strings ......................................    4
   3.3 Physical Addresses ...................................    4
   3.4 The System Group .....................................    5
   3.5 The Interfaces Group .................................    5
   3.6 The Address Translation Group ........................    6
   3.7 The IP Group .........................................    6
   3.8 The ICMP Group .......................................    7
   3.9 The TCP Group ........................................    7
   3.10 The UDP Group .......................................    7
   3.11 The EGP Group .......................................    7
   3.12 The Transmission Group ..............................    8
   3.13 The SNMP Group ......................................    8
   3.14 Changes from RFC 1158 ................. .............    9
   4. Objects ...............................................   10
   4.1 Format of Definitions ................................   10
   5. Overview ..............................................   10
   6. Definitions ...........................................   12
   6.1 Textual Conventions ..................................   12
   6.2 Groups in MIB-II .....................................   13
   6.3 The System Group .....................................   13
SNMP Working Group                                          Page 1 

RFC 1213                         MIB-II                       March 1991

   6.4 The Interfaces Group .................................   16
   6.5 The Address Translation Group ........................   23
   6.6 The IP Group .........................................   26
   6.7 The ICMP Group .......................................   41
   6.8 The TCP Group ........................................   46
   6.9 The UDP Group ........................................   52
   6.10 The EGP Group .......................................   54
   6.11 The Transmission Group ..............................   60
   6.12 The SNMP Group ......................................   60
   7. Acknowledgements ......................................   67
   8. References ............................................   69
   9. Security Considerations ...............................   70
   10. Authors' Addresses ...................................   70
1.  Abstract
   This memo defines the second version of the Management Information
   Base (MIB-II) for use with network management protocols in TCP/IP-
   based internets.  In particular, together with its companion memos
   which describe the structure of management information (RFC 1155)
   along with the network management protocol (RFC 1157) for TCP/IP-
   based internets, these documents provide a simple, workable
   architecture and system for managing TCP/IP-based internets and in
   particular the Internet community.
2.  Introduction
   As reported in RFC 1052, IAB Recommendations for the Development of
   Internet Network Management Standards [1], a two-prong strategy for
   network management of TCP/IP-based internets was undertaken.  In the
   short-term, the Simple Network Management Protocol (SNMP) was to be
   used to manage nodes in the Internet community.  In the long-term,
   the use of the OSI network management framework was to be examined.
   Two documents were produced to define the management information: RFC
   1065, which defined the Structure of Management Information (SMI)
   [2], and RFC 1066, which defined the Management Information Base
   (MIB) [3].  Both of these documents were designed so as to be
   compatible with both the SNMP and the OSI network management
   framework.
   This strategy was quite successful in the short-term: Internet-based
   network management technology was fielded, by both the research and
   commercial communities, within a few months.  As a result of this,
   portions of the Internet community became network manageable in a
   timely fashion.
   As reported in RFC 1109, Report of the Second Ad Hoc Network
   Management Review Group [4], the requirements of the SNMP and the OSI
 
SNMP Working Group                                          Page 2 

RFC 1213                         MIB-II                       March 1991

   network management frameworks were more different than anticipated.
   As such, the requirement for compatibility between the SMI/MIB and
   both frameworks was suspended.  This action permitted the operational
   network management framework, the SNMP, to respond to new operational
   needs in the Internet community by producing this document.
   As such, the current network management framework for TCP/IP- based
   internets consists of: Structure and Identification of Management
   Information for TCP/IP-based internets, RFC 1155 [12], which
   describes how managed objects contained in the MIB are defined;
   Management Information Base for Network Management of TCP/IP-based
   internets: MIB-II, this memo, which describes the managed objects
   contained in the MIB (and supercedes RFC 1156 [13]); and, the Simple
   Network Management Protocol, RFC 1098 [5], which defines the protocol
   used to manage these objects.
3.  Changes from RFC 1156
   Features of this MIB include:
   (1)  incremental additions to reflect new operational
        requirements;
   (2)  upwards compatibility with the SMI/MIB and the SNMP;
   (3)  improved support for multi-protocol entities; and,
   (4)  textual clean-up of the MIB to improve clarity and
        readability.
   The objects defined in MIB-II have the OBJECT IDENTIFIER prefix:
      mib-2      OBJECT IDENTIFIER ::= { mgmt 1 }
   which is identical to the prefix used in MIB-I.
3.1.  Deprecated Objects
   In order to better prepare implementors for future changes in the
   MIB, a new term "deprecated" may be used when describing an object.
   A deprecated object in the MIB is one which must be supported, but
   one which will most likely be removed from the next version of the
   MIB (e.g., MIB-III).
   MIB-II marks one object as being deprecated:
      atTable

SNMP Working Group                                          Page 3 

RFC 1213                         MIB-II                       March 1991

   As a result of deprecating the atTable object, the entire Address
   Translation group is deprecated.
   Note that no functionality is lost with the deprecation of these
   objects: new objects providing equivalent or superior functionality
   are defined in MIB-II.
3.2.  Display Strings
   In the past, there have been misinterpretations of the MIB as to when
   a string of octets should contain printable characters, meant to be
   displayed to a human.  As a textual convention in the MIB, the
   datatype
      DisplayString ::=
          OCTET STRING
   is introduced.  A DisplayString is restricted to the NVT ASCII
   character set, as defined in pages 10-11 of [6].
   The following objects are now defined in terms of DisplayString:
      sysDescr
      ifDescr
   It should be noted that this change has no effect on either the
   syntax nor semantics of these objects.  The use of the DisplayString
   notation is merely an artifact of the explanatory method used in
   MIB-II and future MIBs.
   Further it should be noted that any object defined in terms of OCTET
   STRING may contain arbitrary binary data, in which each octet may
   take any value from 0 to 255 (decimal).
3.3.  Physical Addresses
   As a further, textual convention in the MIB, the datatype
      PhysAddress ::=
          OCTET STRING
   is introduced to represent media- or physical-level addresses.
   The following objects are now defined in terms of PhysAddress:
      ifPhysAddress
      atPhysAddress
      ipNetToMediaPhysAddress
 
SNMP Working Group                                          Page 4 

RFC 1213                         MIB-II                       March 1991

   It should be noted that this change has no effect on either the
   syntax nor semantics of these objects.  The use of the PhysAddress
   notation is merely an artifact of the explanatory method used in
   MIB-II and future MIBs.
 
...............

RFC(Request for Comments)

 发表于:2008年1月8日 12时24分13秒阅读(0)评论(1)
本文链接:http://user.qzone.qq.com/249433686/blog/1199766253RFC及RFC编辑者:
  RFC(Request For Comments)-意即“请求注解”,包含了关于Internet的几乎所有重要的文字资料。
如果你想成为网络方面的专家,那么RFC无疑是最重要也是最经常需要用到的资料之一,所以RFC享有网络知识圣经之美誉。
通常,当某家机构或团体开发出了一套标准或提出对某种标准的设想,想要征询外界的意见时,就会在Internet上发放一份RFC,
对这一问题感兴趣的人可以阅读该RFC并提出自己的意见;绝大部分网络标准的指定都是以RFC的形式开始,
经过大量的论证和修改过程,由主要的标准化组织所指定的,但在RFC中所收录的文件并不都是正在使用或为大家所公认的,
也有很大一部分只在某个局部领域被使用或并没有被采用,一份RFC具体处于什么状态都在文件中作了明确的标识
  
       RFC由一系列草案组成,起始于1969年(第一个RFC文档发布于1969年4月7日,参见“RFC30年”,RFC2555”),
RFC文档是一系列关于Internet(早期为ARPANET)的技术资料汇编。这些文档详细讨论了计算机网络的方方面面,
重点在网络协议,进程,程序,概念以及一些会议纪要,意见,各种观点等。
  “RFC编辑者”是RFC文档的出版者,它负责RFC最终文档的编辑审订。“RFC编辑者”也保留有RFC的主文件,称为RFC索引,
用户可以在线检索。在RFC近30年的历史中,“RFC编辑者”一直由约翰?普斯特尔(Jon Postel)来担任,而现在“RFC编辑者”
则由一个工作小组来担任,这个小组受到“因特网社团”(Internet Society)的支助。
  RFC编辑者负责RFC以及RFC的整体结构文档,并维护RFC的索引。Internet协议族的文档部分(由Internet工程委员会“因特网工程师任务组”IETF
以及IETF 下属的“因特网工程师指导组”IESG 定义),也做为RFC文档出版。因此,RFC在Internet相关标准中有着重要的地位。
  RFC编辑者的职责是由Internet 中的大家提议形成的,所出版的语言也就和Internet一样。IETF和ISOC是代表了世界各地的国际性组织,
英语是IETF的第一工作语言,也是IETF的正式出版语言。RFC 2026 "The Internet Standards Process -- Revision 3" 允许RFC翻译成其他不同的语言。
但是不能保证其翻译版本是否正确。因此,RFC编辑不对非英语的版本负责,而只是指明了哪里有非英语的版本,将这些信息列在WEB页上。
RFC处理过程:
  一个RFC文件在成为官方标准前一般至少要经历三个阶段:建议标准、草案标准、因特网标准。
第一步RFC的出版是作为一个Internet 草案发布,可以阅读并对其进行注释。准备一个RFC草案,我们要求作者先阅读IETF的一个文档"Considerations for Internet Drafts". 它包括了许多关于RFC以及Internet草案格式的有用信息。作者还应阅读另外一个相关的文档RFC 2223 "Instructions to Authors"。
  一旦文档有了一个ID号后,你就可以向rfc-editor@rfc-editor.org发送e-mail ,说你觉得这个文档还可以,能够作为一个有价值或有经验的RFC文档 。RFC编辑将会向IESG请求查阅该文档并给其加上评论和注释。你可以通过RFC队列来了解你的文档的进度。一旦你的文档获得通过,RFC编辑就会将其编辑并出版。如果该文档不能出版,则会有email通知作者是什么原因。作者有48个小时来校对RFC编辑的意见。我们强烈建议作者要检测拼写错误和丢字的错误,应该确保有引用,联系和更新相关的信息。如你的文档是一个MIB,我们则要你对你的代码作最后一次检测。一旦RFC文档出版,我们就不会对其进行更改,因此你应该对你的文档仔细的检查。
  有时个别的文档会被正从事同一个项目的IETF工作组收回,如是这种情况,则该作者会被要求和IETF进行该文档的开发。在IETF中, Area Directors (ADs) 负责相关的几个工作组。这些工作者所开发的文档将由ADs 进行校阅,然后才作为RFC的出版物。
如要获得关于如何写RFC文档和关于RFC的Internet标准制定过程的更多详细信息,请各位参见:
RFC 2223 "Instructions to RFC Authors"。
RFC 2026 "The Internet Standards Process -- Revision 3"。
  实际上,在Internet上,任何一个用户都可以对Internet某一领域的问题提出自己的解决方案或规范,作为Internet草案(Internet Draffs,ID)提交给Internet工程任务组(IETF)。草案存放在美国、欧洲和亚太地区的工作文件站点上,供世界多国自愿参加的IETF成员进行讨论、测试和审查。最后,由Internet工程指导组(IESG)确定该草案是否能成为Internet的标准。
  如果一个Internet草案在IETF的相关站点上存在6个月后仍未被IESG建议作为标准发布,则它将被从上述站点中删除。事实上,在任何时候,一个Internet 草案都有可能被新的草案版本所替换掉,并重新开始6个月的存放期。
如果一个Internet草案被IESG确定为Internet的正式工作文件,则被提交给Internet体系结构委员会(IAB),并形成具有顺序编号的RFC文档,由Internet协会(ISOC)通过Internet向全世界颁布。每个Internet标准文件在被批准后都会分配一个独立于RFC的永久编号,这就是STD编号。有一个不断被更新的文件RFC-INDEX.TXT按照RFC的编号来索引所有的文件,对于因特网标准文件还列出了其相应的STD编号。
RFC文档必须被分配RFC编号后才能在网络上发布。例如,RFC2026的内容是“Internet标准进程-修订版3”、RFC1543的内容为“RFC作者指导”等等。需要时,可以复制或打印这些联机文档。用户也可以通过遍布全世界的数个联机资料数据库中获得RFC文档。例如,可以使用路径名RFC/RFCnnnn.TXT通过FTP的方式从ds.internic.net站点获得RFC,其中“nnnn”指的是RFC的编号。在这里,使用FTP登录时,所用的用户名和口令分别为“anonymous”和你的电子邮件地址。此外,用户还可以通过Internet网络信息中心(InterNIC)的目录服务功能、电子邮件、WWW等方式获得RFC文档.
  作为标准的RFC又分为几种,第一种是提议性的,就是说建议采用这个作为一个方案摆出来,Draft是已经有一部分在用了,希望被采用为正式的标准,还有一种就是完全被认可的标准,这种是大家都在用,而且是不应该改变的。还有一种就是现在的最佳实践法,它相当于一种介绍。这些文件产生的过程是一种从下往上的过程,而不是从上往下,也就是说不是一个由主席,或者由工作组负责人的给一个指令,说是要做什么,要做什么,而是有下边自发的提出,然后在工作组里边讨论,讨论了以后再交给刚才说的工程指导委员会进行审查。但是工程指导委员会只做审查不做修改,修改还是要打回到工作组来做。IETF工作组文件的产生就是任何人都可以来参加会议,任何人都可以提议,然后他和别人进行讨论,大家形成了一个共识就可以产出这样的文件。
1月29日

[顶]FCAPS的解释

表于:2008年1月8日 11时22分39秒阅读(1)评论(0)
文链接:http://user.qzone.qq.com/249433686/blog/1199762559
 
fcaps是国际电联的标准模型,为企业管理水平。
The five FCAPS domains are:五fcaps领域分别是:
F ault Management f ault      故障管理
C onfiguration Management   配置管理
A ccounting Management A ccounting      计费管理
P erformance Management p erformance     性能管理
S ecurity Management     安全管理
 
Fault Management故障管理
Fault management is the domain where network problems are discovered and corrected.故障管理是域网络的地方,发现问题和纠正。
Steps are then taken to prevent them from occurring or recurring.步骤,然后采取,以防止他们发生或复发。
By doing so, the network remains operational and downtime is minimized.这样,网络仍然是业务和停机时间减少到最低限度。
Configuration Management配置管理
Configuration management is where daily operations are monitored and controlled.配置管理是日常运作进行监控和控制。
All hardware and programming changes are coordinated.所有的硬件和节目的变化,重视协调发展。
In addition, new programs, new equipment, modification of existing systems and the removal of obsolete systems and programs are also coordinated.此外,新节目,新设备,改造现有的制度和去除过时的制度和程序也相协调。
Accounting Management 计费管理
Accounting management is devoted to determining how to optimally distribute resources among enterprise subscribers.会计管理,是专门以确定如何以最佳方式分配资源,其中企业用户。
This helps to minimize the cost of operations by making the most effective use of the systems available.这有利于最大限度地减少经营成本,使最有效地利用该系统提供的。
This level is also responsible for ensuring the appropriate billing of users.这一级也有责任确保适当的计费用户。
Performance Management 性能管理
Performance management is involved in managing the overall performance of the enterprise network.绩效管理是参与管理的整体表现,企业网络。 Potential problems are identified, throughput is maximized and bottlenecks are identified.潜在问题,确定后,吞吐量最大化和瓶颈确定。 Improvements that will yield the greatest enhancement to overall performance are identified.改善,将能取得最大的提升,以整体表现确定。
Security Management安全管理
Security management is responsible for protecting the network from unauthorized users and physical and electronic sabotage.安全管理是负责保护网络免受未经授权的用户和物理和电子破坏。
Security management is responsible for user authentication and authorization.安全管理部门负责用户认证和授权。
It also maintains the confidentiality of user information.它也保持了保密的用户信息。
12月19日

周三:windows盗版受害者提示的删除方法

__\\\今天天气很好, 二部老大请吃饭(公司乔迁新址时慰问劳动的兄弟们), 我也是其中的一份子就参加了这个patrol的小聚; 总的感觉今天的心情还好了, 就是在公司里天天由于新装修可能是装修的油漆味道没散发完吧, 天天熏的头疼~!  不过还好了, 头疼的时候打开窗户, 吹吹就好点了~!  吃饭也吃的稠糊, 呵呵, 大家也挺高兴的~! 这个中午就这么过去了......下午回到公司坐了下来, 刚打开电脑~!
 
奇迹发生: 任务栏下方出现新的提示: "你可能是windows盗版受害者" 这是我第二次系统自动更新是出现这个问题了~! ||
 
问题解决分两步:
    
     1)cmd => regedit 打开注册表:  删除系统这个提示的注册表项,具体位置在:
         HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft \Windows
         NT \CurrentVersion \Winlogon \Notify \WgaLogon
         到这项下(就是我们要找的注册表所在项),全部删除,刷新注册表,重新启动系统;
     2)重新启动了系统后, 然后把垃圾的文件删除干净: 把系统盘:\windows\system32中的wgatray.exe
        删除,还有wgatray.dll 文件相关的文件都删除干净; 
 
___///最好再f8模式安全模式下搜索下其他的wgatray相关文件统统删除;
 
___\\\这样的话,我们要的效果就完成了, 烦人的"盗版受害者" 的提示也彻底清楚了, 下午就可以好好的工作了~!!!!!!!!
 

Windows Media Player

全 15 枚中 1 枚目

jedellnniu

職業
所在地
好きなもの/好きなこと
不管怎样,太阳依然会照常升起,我们依然会走好;
一杯茶,品人生沉浮;平常心,造万千世界。█追求真善美... 希望前方有你的身影.█昆腾█指尖█神州泰岳█青鸟█我┏╮〃
╰★╮
〃╰┛*.⒈條路﹏ 辵捯死〣﹎﹎メ蒶掱¨ …→緣妢._你紸顁`
行者无疆,前方路有多远,我就走多远
リスト項目が追加されていません。
リスト項目が追加されていません。