⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 rfc2249.txt

📁 <VC++网络游戏建摸与实现>源代码
💻 TXT
📖 第 1 页 / 共 4 页
字号:
Freed & Kille               Standards Track                     [Page 7]RFC 2249                  Mail Monitoring MIB               January 1998       received since MTA initialization.  Recipients this MTA       has no responsibility for, i.e. inactive envelope       recipients or ones referred to in message headers,       should not be counted even if information about such       recipients is available.  This includes messages       transmitted to this MTA from other MTAs as well as       messages that have been submitted to the MTA directly       by end-users or applications."    ::= {mtaEntry 7}mtaStoredRecipients OBJECT-TYPE    SYNTAX Gauge32    MAX-ACCESS read-only    STATUS current    DESCRIPTION      "The total number of recipients specified in all messages       currently stored in the MTA.  Recipients this MTA has no       responsibility for, i.e. inactive envelope recipients or       ones referred to in message headers, should not be       counted.  This includes messages that are awaiting       transmission to some other MTA or are waiting for       delivery to an end-user or application."    ::= {mtaEntry 8}mtaTransmittedRecipients OBJECT-TYPE    SYNTAX Counter32    MAX-ACCESS read-only    STATUS current    DESCRIPTION      "The total number of recipients specified in all messages       transmitted since MTA initialization.  Recipients this       MTA had no responsibility for, i.e. inactive envelope       recipients or ones referred to in message headers,       should not be counted.  This includes messages that were       transmitted to some other MTA or are waiting for       delivery to an end-user or application."    ::= {mtaEntry 9}mtaSuccessfulConvertedMessages OBJECT-TYPE    SYNTAX Counter32    MAX-ACCESS read-only    STATUS current    DESCRIPTION      "The number of messages that have been successfully       converted from one form to another since MTA       initialization."    ::= {mtaEntry 10}Freed & Kille               Standards Track                     [Page 8]RFC 2249                  Mail Monitoring MIB               January 1998mtaFailedConvertedMessages OBJECT-TYPE    SYNTAX Counter32    MAX-ACCESS read-only    STATUS current    DESCRIPTION      "The number of messages for which an unsuccessful       attempt was made to convert them from one form to       another since MTA initialization."    ::= {mtaEntry 11}mtaLoopsDetected OBJECT-TYPE    SYNTAX Counter32    MAX-ACCESS read-only    STATUS current    DESCRIPTION      "A message loop is defined as a situation where the MTA       decides that a given message will never be delivered to       one or more recipients and instead will continue to       loop endlessly through one or more MTAs.  This variable       counts the number of times the MTA has detected such a       situation since MTA initialization. Note that the       mechanism MTAs use to detect loops (e.g. trace field       counting, count of references to this MTA in a trace       field, examination of DNS or other directory information,       etc.), the level at which loops are detected (e.g. per       message, per recipient, per directory entry, etc.), and       the handling of a loop once it is detected (e.g. looping       messages are held, looping messages are bounced or sent       to the postmaster, messages that the MTA knows will loop       won't be accepted, etc.) vary widely from one MTA to the       next and cannot be inferred from this variable."    ::= {mtaEntry 12}-- MTAs typically group inbound reception, queue storage, and-- outbound transmission in some way, rather than accounting for-- such operations only across the MTA as a whole. In the most-- extreme case separate information will be maintained for each-- different entity that receives messages and for each entity-- the MTA stores messages for and delivers messages to.  Other-- MTAs may elect to treat all reception equally, all queue-- storage equally, all deliveries equally, or some combination-- of this. Overlapped groupings are also possible, where an MTA-- decomposes its traffic in different ways for different-- purposes.-- In any case, a grouping abstraction is an extremely useful for-- breaking down the activities of an MTA. For purposes of-- labelling this will be called a "group" in this MIB.Freed & Kille               Standards Track                     [Page 9]RFC 2249                  Mail Monitoring MIB               January 1998-- Each group contains all the variables needed to monitor all-- aspects of an MTA's operation.  However, the fact that all-- groups contain all possible variables does not imply that all-- groups must use all possible variables. For example, a single-- group might be used to monitor only one kind of event (inbound-- processing, outbound processing, or storage). In this sort of-- configuration all unused counters would be inaccessible; e.g.,-- returning either a noSuchName error (for an SNMPv1 get), or a-- noSuchInstance exception (for an SNMPv2 get).-- Groups can be created at any time after MTA initialization. Once-- a group is created it should not be deleted or its mtaGroupIndex-- changed unless the MTA is reinitialized.-- Groups are not necessarily mutually exclusive. A given event may-- be recorded by more than one group, a message may be seen as-- stored by more than one group, and so on.  Groups should be all-- inclusive, however: if groups are implemented all aspects of an-- MTA's operation should be registered in at least one group. This-- freedom lets implementors use different sets of groups to-- provide differents "views" of an MTA.-- The possibility of overlap between groups means that summing-- variables across groups may not produce values equal to those in-- the mtaTable. mtaTable should always provide accurate information-- about the MTA as a whole.-- The term "channel" is often used in MTA implementations; channels-- are usually, but not always, equivalent to a group. However,-- this MIB does not use the term "channel" because there is no-- requirement that an MTA supporting this MIB has to map its-- "channel" abstraction one-to-one onto the MIB's group abstration.-- An MTA may create a group or group of groups at any time. Once-- created, however, an MTA cannot delete an entry for a group from-- the group table.  Deletation is only allowed when the MTA is-- reinitialized, and is not required even then.  This restriction-- is imposed so that monitoring agents can rely on group-- assignments being consistent across multiple query operations.-- Groups may be laid out so as to form a hierarchical arrangement,-- with some groups acting as subgroups for other groups.-- Alternately, disjoint groups of groups may be used to provide-- different sorts of "snapshots" of MTA operation.  The-- mtaGroupHierarchy variable provides an indication of how each-- group fits into the overall arrangement being used.mtaGroupTable OBJECT-TYPEFreed & Kille               Standards Track                    [Page 10]RFC 2249                  Mail Monitoring MIB               January 1998    SYNTAX SEQUENCE OF MtaGroupEntry    MAX-ACCESS not-accessible    STATUS current    DESCRIPTION      "The table holding information specific to each MTA group."    ::= {mta 2}mtaGroupEntry OBJECT-TYPE    SYNTAX MtaGroupEntry    MAX-ACCESS not-accessible    STATUS current    DESCRIPTION      "The entry associated with each MTA group."    INDEX {applIndex, mtaGroupIndex}    ::= {mtaGroupTable 1}MtaGroupEntry ::= SEQUENCE {    mtaGroupIndex        INTEGER,    mtaGroupReceivedMessages        Counter32,    mtaGroupRejectedMessages        Counter32,    mtaGroupStoredMessages        Gauge32,    mtaGroupTransmittedMessages        Counter32,    mtaGroupReceivedVolume        Counter32,    mtaGroupStoredVolume        Gauge32,    mtaGroupTransmittedVolume        Counter32,    mtaGroupReceivedRecipients        Counter32,    mtaGroupStoredRecipients        Gauge32,    mtaGroupTransmittedRecipients        Counter32,    mtaGroupOldestMessageStored        TimeInterval,    mtaGroupInboundAssociations        Gauge32,    mtaGroupOutboundAssociations        Gauge32,    mtaGroupAccumulatedInboundAssociations        Counter32,    mtaGroupAccumulatedOutboundAssociationsFreed & Kille               Standards Track                    [Page 11]RFC 2249                  Mail Monitoring MIB               January 1998        Counter32,    mtaGroupLastInboundActivity        TimeInterval,    mtaGroupLastOutboundActivity        TimeInterval,    mtaGroupLastOutboundAssociationAttempt        TimeInterval,    mtaGroupRejectedInboundAssociations        Counter32,    mtaGroupFailedOutboundAssociations        Counter32,    mtaGroupInboundRejectionReason        DisplayString,    mtaGroupOutboundConnectFailureReason        DisplayString,    mtaGroupScheduledRetry        TimeInterval,    mtaGroupMailProtocol        OBJECT IDENTIFIER,    mtaGroupName        DisplayString,    mtaGroupSuccessfulConvertedMessages        Counter32,    mtaGroupFailedConvertedMessages        Counter32,    mtaGroupDescription        DisplayString,    mtaGroupURL        URLString,    mtaGroupCreationTime        TimeInterval,    mtaGroupHierarchy        INTEGER,    mtaGroupOldestMessageId        DisplayString,    mtaGroupLoopsDetected        Counter32}mtaGroupIndex OBJECT-TYPE    SYNTAX INTEGER (1..2147483647)    MAX-ACCESS not-accessible    STATUS current    DESCRIPTION      "The index associated with a group for a given MTA."    ::= {mtaGroupEntry 1}mtaGroupReceivedMessages OBJECT-TYPEFreed & Kille               Standards Track                    [Page 12]RFC 2249                  Mail Monitoring MIB               January 1998    SYNTAX Counter32    MAX-ACCESS read-only    STATUS current    DESCRIPTION      "The number of messages received to this group since       group creation."    ::= {mtaGroupEntry 2}mtaGroupRejectedMessages OBJECT-TYPE    SYNTAX Counter32    MAX-ACCESS read-only    STATUS current    DESCRIPTION      "The number of messages rejected by this group since       group creation."    ::= {mtaGroupEntry 3}mtaGroupStoredMessages OBJECT-TYPE    SYNTAX Gauge32    MAX-ACCESS read-only    STATUS current    DESCRIPTION      "The total number of messages currently stored in this       group's queue."    ::= {mtaGroupEntry 4}mtaGroupTransmittedMessages OBJECT-TYPE    SYNTAX Counter32    MAX-ACCESS read-only    STATUS current    DESCRIPTION      "The number of messages transmitted by this group since       group creation."    ::= {mtaGroupEntry 5}mtaGroupReceivedVolume OBJECT-TYPE    SYNTAX Counter32    UNITS "K-octets"    MAX-ACCESS read-only    STATUS current    DESCRIPTION      "The total volume of messages received to this group since       group creation, measured in kilo-octets.  This volume       should include all transferred data that is logically above       the mail transport protocol level.  For example, an       SMTP-based MTA should use the number of kilo-octets in the       message header and body, while an X.400-based MTA should use       the number of kilo-octets of P2 data."Freed & Kille               Standards Track                    [Page 13]RFC 2249                  Mail Monitoring MIB               January 1998    ::= {mtaGroupEntry 6}mtaGroupStoredVolume OBJECT-TYPE    SYNTAX Gauge32    UNITS "K-octets"    MAX-ACCESS read-only    STATUS current    DESCRIPTION      "The total volume of messages currently stored in this       group's queue, measured in kilo-octets.  This volume should       include all stored data that is logically above the mail       transport protocol level.  For example, an SMTP-based       MTA should use the number of kilo-octets in the message       header and body, while an X.400-based MTA would use the       number of kilo-octets of P2 data."    ::= {mtaGroupEntry 7}mtaGroupTransmittedVolume OBJECT-TYPE    SYNTAX Counter32    UNITS "K-octets"    MAX-ACCESS read-only    STATUS current    DESCRIPTION      "The total volume of messages transmitted by this group       since group creation, measured in kilo-octets.  This       volume should include all transferred data that is logically       above the mail transport protocol level.  For example, an       SMTP-based MTA should use the number of kilo-octets in the       message header and body, while an X.400-based MTA should use       the number of kilo-octets of P2 data."    ::= {mtaGroupEntry 8}mtaGroupReceivedRecipients OBJECT-TYPE    SYNTAX Counter32    MAX-ACCESS read-only    STATUS current    DESCRIPTION      "The total number of recipients specified in all messages       received to this group since group creation.       Recipients this MTA has no responsibility for should not       be counted."    ::= {mtaGroupEntry 9}mtaGroupStoredRecipients OBJECT-TYPE    SYNTAX Gauge32    MAX-ACCESS read-only    STATUS current    DESCRIPTIONFreed & Kille               Standards Track                    [Page 14]

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -