SNMP Overview

SNMP Overview

The Simple Network Management Protocol (SNMP) is by far the dominant protocol in network management. This Protocol (SNMP) was designed to be an easily implementable, basic network management tool that could be used to meet network management needs.

It is named Simple Network Management Protocol as it is really easy to understand. A key reason for its widespread acceptance, besides being the chief Internet standard for network management, is its relative simplicity. There are different versions of SNMP, such as SNMP V1, SNMP V2c, and SNMP V3.

Implementing SNMP management in a networked device is far more straightforward than most other standard or non-standard approaches to network management. Despite that, SNMP application development has not been as simple as one would like it to be. It has required significant effort to develop management applications to manage a variety of networked devices to be managed. This situation is now changing for the better, as more SNMP tools become available. With improved tools, SNMP is poised to deliver end-to-end management for all areas of the growing inter-networking industry.

Thus SNMP has become the dominant standardized network management scheme in use today. The SNMP set of standards provides a framework for the definition of management information along with a protocol for the exchange of that information. The SNMP model assumes the existence of Managers and Agents.

What Is an Agent?

Just think of insurance agents. They are the ones who help both the insurance companies and customers to get smooth access. Suppose we want to take an insurance policy, we do not have to spend anytime in taking that policy. The agent himself, will take care of it and just inform us the status.

In the same manner, Agent is a program which communicates with the Manager on one side and with Device or Application on the other side. It forms a  part of the Device or Application so that it can know everything about the Device or Application regularly.

It is a software module in the device responsible for maintaining local management information and delivering that information to a manager via SNMP. A management information exchange can be initiated by the manager (via polling) or by the agent (via a trap). Agent functions as a device that gathers and sends data about the managed resource in response to a request from a manager. UDP ports, 161 and 162, are the default ports reserved for SNMP. The agent listens for requests and replies to them over port 161 and reports asynchronous traps on port 162, unless it is instructed to use different ports. SNMP accommodates resources that do not implement the SNMP software by means of proxies. A proxy is an SNMP agent that maintains information on behalf of one or more non-SNMP devices.

Who Is a Manager?

Just imagine a Manager, as an entity managing one or more agents from a remote place. For example, let's take an organization which has its office premises in 4 places with more than 200 PCs, 4 to 5 printers, and just 3 System Administrators. To manage all these machines and printers, the System Administrators have to keep moving around all offices. Instead, if they have the Managers installed in their machines and agents installed in all other machines then they can easily handle all machines from their place. They just have to query the agent from the manager to know the status of the machine. If the Agent automatically informs the Manager when a problem is likely to occur (say, the number of paper is becoming less than 100 or 50 in a printer ), then the System Administrator will do the necessary changes (insert papers in the printer) to prevent the problem from occurring. If we come to know that the printer is running out of paper after giving a print, we will definitely be upset with it. Instead, if the printer itself notifies (through the agent) the person concerned (System Administrator) about its paper level or ink level then it will be very useful for the Administrator.

Manager and Agent Relationship

SNMP facilitates communication between a managed device (a device with an SNMP agent, e.g., a router) and an SNMP Manager or management application (represents a user of network management). The SNMP agent on the managed device provides access to data (managed objects) stored on the managed device. The SNMP manager or management application uses this access to monitor and control the managed device.

Communication is via SNMP Protocol Data Units (PDUs) that are typically encapsulated in UDP packets, and five kinds of operations are permitted between managers and agents (managed device).

• The manager can perform a get (or read) to obtain information from the agent about an attribute of a managed object.

• The manager can perform a get-next to do the same for the next object in  the tree of objects on the managed device.

• The manager can perform a get-bulk to obtain information about a group of data from the agent. This is not possible in the case of SNMP V1.

• The manager can perform a set (or write) to set the value of an attribute of a managed object.

• The agent can send a trap, or asynchronous notification, to the manager telling it about some event on the managed device.

To specify to the SNMP agent which managed objects are of interest, the SNMP manager or management application, uses a well-defined naming syntax. Object names in this syntax are called object identifiers (object IDs, or OIDs), and are a series of numbers that uniquely identifies an object to an SNMP agent.

What Is a MIB (Management Information Base)?

MIB is a document about the device or the application. There are a lot of syntaxes defined for defining the MIB, but the purpose of the MIB is simple. For example, if a company wants to build an application and wants the application to be remotely managed, then while building the application itself, the architects of the application or the device will write a MIB which will have information, such as what are the variables that should be published outside (to the Manager), what is the use of each variable, what each value in the variable represents, and so on.

Each variable is assigned a unique identifier in SNMP that is called an object identifier (OID). Object identifier is a unique ID (like registration numbers), but the uniqueness is maintained all over the world. Let us see how this uniqueness is maintained. The format of OID is a sequence of numbers with dots in between. There are two roots for object identifiers, they are iso (which is .1) and ccit (which starts with .0). Most object identifiers start with .1.3.6.1 (where 1 = iso, 3 = org, 6 = dod, 1 = internet). From internet, there are two branches, mgmt and private.

All standard MIBs reside under mgmt (.1.3.6.1.2) in this diagram - for example, MIB II (.1.3.6.1.2.1). The distinction between the standard and private MIBs is that of control over the object definitions (that is, defining the variables ). Standard MIBs are those that have been approved by the Internet Activities Board (IAB). MIBs defined unilaterally by equipment and software vendors are initially defined as private MIBs under private.enterprises. A branch within the private.enterprises sub-tree is allocated to each vendor that registers for an enterprises object identifier. zoho has got the enterprise OID as 2162. So all the variables we define for our device or application should fall under .1.3.6.1.4.1.2162 (.iso.org.dod.internet.private.enterprise.zoho). Till the enterprise number (like 2162), the uniqueness is maintained by the committee, after this the uniqueness should be maintained by each enterprise.

For example,  if we are going to manufacture a printer, then we can think of displaying the variables, such as  noOfPapers, inkLevel etc., so that at anytime the system administrators will know how many papers are there in the printer without going to the printer. They will just install the Manager in these machines and will query the printer agent and get this information. There are standard MIBs available. For exaple, RFC1213-MIB is a standard MIB for managing the system that each operating system will implement. This MIB contains information about the system, number of interfaces, and so on. There is also a standard MIB for printer. SNMP agents for different types of devices provide access to objects that are specific to the type of device. In order to enable the SNMP manager or management application to operate intelligently on the data available on the device, the manager needs to know the names and types of objects on the managed device.

This is made possible by Management Information Base (MIB) modules, which are specified in MIB files usually provided with managed devices. For example, rfc1213-MIB(also known as MIB-II) is a MIB module which is typically supported by all SNMP agents on TCP/IP enabled devices or systems. This MIB file contains a description of the object hierarchy on the managed device, as well as the name (Object ID), syntax, and access privileges for each variable in the MIB. For example, when the MIB module is loaded in a MIB browser, the label of the variable, e.g., sysDescr, can be used to identify it, since the MIB browser can use the MIB module to translate this label to an Object ID.

One key aspect of MIBs is that only the types of objects on the managed device are specified by the MIB, and not the specific objects (or instances). For example, ifInOctets in rfc1213-MIB specifies a type of object for number of input octets on an interface, but the specific objects or instances of that type are specified as ifInOctets.1, ifInOctets.2, etc., depending on the number of interfaces. When specifying an object to the SNMP agent, a proper Object ID which includes the instance needs to be used by the manager. When not properly specified, the agent responds with a "No such variable" error.

What Are MIB Groups?

A MIB group is a collection of managed objects, and is itself represented by the name or OID of a node in the OID tree. Groups may contain other groups. For example, bea is a MIB group that is a member of the private.enterprises MIB group. The nodes in the OID tree that are not groups - the base level of the OID tree - are the "leaves" of the OID tree. For example, in the following diagram:

• MIB group x contains a group of objects, a, b, and c.

• MIB group y contains a group of objects, d, e, and f.

MIB Data types Available

Following are the MIB data types and constructs supported by Agent Toolkit.

SNMP V1 Data Types

Data Type Name	Description
INTEGER	Used to specify a value whose range may include both positive and negative numbers. Range = -2e31 to 2e31 - 1 (SMIv1 doesn't specify minimum or maximum values for the range). Examples:  INTEGER(0..127) -- corresponds to an unsigned 8-bit int  INTEGER(0..40 | 50 | 65 | 90..100)  INTEGER(-2147483648..2147483647) -- corresponds to a signed 32-bit int
INTEGER (enumerated integer)	Used to specify a list of labeled integer values. In SMIv1, the values should be greater than 0, whereas SMIv2 allows any values in the range (-2e31 to 2e31- 1). Example:  INTEGER {true(1), false(2)}
Gauge	It represents a non-negative integer which may increase or decrease, but which holds at the maximum or minimum value specified in the range when the actual value goes over or below the range, respectively.
Counter	Used to specify a value which represents a count. The range is 0 to 4294967295.
TimeTicks	Used to specify the elapsed time between two events, in units of hundredth of a second. Range is 0 to 2e32 - 1.
OCTET STRING	Used to specify octets of binary or textual information. While SMIv1 doesn't limit the number of octets, SMIv2 specifies a limit of 65535 octets. A size may be specified which can be fixed, varying, or multiple ranges.  Examples:  OCTET STRING -- length can vary from 0 to 65535 bytes.   OCTET STRING (SIZE(0..255))   OCTET STRING (SIZE(4)) -- fixed length of 4 bytes.   OCTET STRING (SIZE(0 | 4 | 6)) -- varying with 0, 4, or 6 bytes.
OBJECT IDENTIFIER	Used to identify a type that has an assigned object identifier value.
IpAddress	This type is used to specify an IPv4 address as a string of 4 octets.
NetworkAddress	This type was designed to allow a network address of any type to be specified. However, it is now obsolete. A value of this type is an IPv4 address. SMIv2 supports this type via the IpAddress type.
Opaque	Used to specify octets of binary information. SMIv2 specifies a limit of 65535 octets while there is no limit in SMIv1. A size may be specified which can be fixed, varying, or multiple ranges. A value of this type must be an encapsulation of ASN.1 BER encoded value.  Examples:  Opaque -- length can vary from 0 to 65535 bytes.  Opaque (SIZE(0..255))  Opaque (SIZE(4)) -- fixed length of 4 bytes.  Opaque (SIZE(0 | 4 | 6)) -- varying with 0, 4, or 6 bytes.

SNMP V2 Data Types

Data Type Name	Description
Integer32	Used to specify a value whose range may include both positive and negative numbers. Range = -2e31 to 2e31 - 1 (SMIv1 doesn't specify minimum or maximum values for the range). Examples:  Integer32(0..127) -- corresponds to an unsigned 8-bit int  Integer32 -- same as -- Integer32(-2147483648..2147483647)  Integer32(0..40 | 50 | 65 | 90..100)
INTEGER (enumerated integer)	Used to specify a list of labeled integer values. In SMIv1, the values should be greater than 0, whereas SMIv2 allows any values in the range (-2e31 to 2e31- 1). Examples:  INTEGER { true(1), false(2) }   INTEGER { lessThan(-1), equal(0), greaterThan(1) }
Unsigned32	Used to specify a value whose range includes only non-negative integers (0 to 2e31 - 1).  Examples:  Unsigned32 -- same as Unsigned32(0..4294967295)  Unsigned32(0..65535) -- corresponds to an unsigned 16 bit int  Unsigned32(0..10 | 50 | 65 | 90..100)
Gauge32	It represents a non-negative integer which may increase or decrease, but which holds at the maximum or minimum value specified in the range when the actual value goes over or below the range, respectively.
Counter32	Used to specify a value which represents a count. The  range is 0 to 4294967295.
Counter64	Similar to Counter32, except the range is now (0 to 2e64  -1). This type may only be used when a 32-bit counter rollover could occur in less than an hour. Otherwise, the Counter32 type must be used. Since this type is not available in SNMPv1, it may only be used when backwards compatibility is not a requirement.
TimeTicks	Used to specify the elapsed time between two events, in units of hundredth of a second. Range is 0 to 2e32 - 1.
OCTET STRING	Used to specify octets of binary or textual information. While SMIv1 doesn't limit the number of octets, SMIv2 specifies a limit of 65535 octets. A size may be specified which can be fixed, varying, or multiple ranges.   Examples:   OCTET STRING -- length can vary from 0 to 65535 bytes.   OCTET STRING (SIZE(0..255))   OCTET STRING (SIZE(4)) -- fixed length of 4 bytes.   OCTET STRING (SIZE(0 | 4 | 6)) -- varying with 0, 4, or 6 bytes
OBJECT  IDENTIFIER	Used to identify a type that has an assigned object identifier value
IpAddress	This type is used to specify an IPv4 address as a string of 4 octets.
Opaque	Used to specify octets of binary information. SMIv2 specifies a limit of 65535 octets while there is no limit in SMIv1. A size may be specified which can be fixed, varying, or multiple ranges. A value of this type must be an encapsulation of ASN.1 BER encoded value.  Examples:  Opaque -- length can vary from 0 to 65535 bytes.   Opaque (SIZE(0..255))   Opaque (SIZE(4)) -- fixed length of 4 bytes.   Opaque (SIZE(0 | 4 | 6)) -- varying with 0, 4, or 6 bytes
BITS	Used to specify a collection of labeled bits. It provides a way to label individual bits in an octet (an extension of OCTET STRING type).  Examples:   BITS { 1 (TCP), 2(Netware), 3(NetBIOS)

MIB Constructs Available

The following tables describe the constructs supported by Agent Toolkit and the mandatory elements that must be defined if the construct is created/edited.
 

SNMPv1 Constructs	SMPv2 Constructs	Constructs Used Both in SNMPv1 and SNMPv2
TRAP-TYPE	MODULE-IDENTITY   TEXTUAL CONVENTION   OBJECT-IDENTITY   OBJECT-GROUP   NOTIFICATION-TYPE   NOTIFICATION-GROUP	OBJECT-IDENTIFIER   OBJECT-TYPE (SCALAR) OBJECT-TYPE (TABLE)

The Mandatory and the Optional fields for the various constructs :
 

Construct Name	Mandatory Fields	Optional Fields
OBJECT-IDENTIFIER  (v1 & v2 Construct)	--	COMMAND-TYP
OBJECT-TYPE  (SCALAR)  (v1 & v2 Construct)	SYNTAX MAX-ACCESS STATUS	DESCRIPTION REFERENCE DEFVAL COMMAND TYPE
OBJECT-TYPE (TABLE)  (v1 & v2 Construct)	SYNTAX SEQUENCE OF MAX-ACCESS STATUS	DESCRIPTION REFERENCE COMMAND TYPE
MODULE-IDENTITY  (v2 Construct)	LAST-UPDATED ORGANIZATION CONTACT-INFO DESCRIPTION	REVISION REV-DESCRIPTION
TEXTUAL-CONVENTION (v2 Construct)	STATUS DESCRIPTION SYNTAX	DISPLAY-HINT REFERENCE
OBJECT-IDENTITY  (v2 Construct)	STATUS DESCRIPTION	REFERENCE
OBJECT-GROUP  (v2 Construct)	OBJECTS STATUS DESCRIPTION	REFERENCE
NOTIFICATION-TYPE  (v2 Construct)	STATUS DESCRIPTION	OBJECTS REFERENCE
NOTIFICATION-GROUP  (v2 Construct)	NOTIFICATIONS STATUS DESCRIPTION	REFERENCE
TRAP-TYPE  (v1 Construct)	ENTERPRISE	VARIABLES DESCRIPTION REFERENCE

Supported Textual Conventions

The set of SNMPv2 Textual Conventions supported by the Agent Compiler and embedded agent are

• DisplayString

• PhyAddress

• MacAddress

• Truth Value

• TestAndIncr.

• Autonomous Type

• Variable Pointer

• Row Pointer

• RowStatus

• TimeStamp *

• TimeInterval *

• DateAndTime

• Storage Type

• TDomain

• TAddress

Note: The Agent Compiler supports these textual conventions but the relevant functionalities are not handled in the SNMP API.

Nodes

Following are the nodes present in SNMPv2-SMI mib:

• org OBJECT IDENTIFIER ::= {iso 3}

• dod OBJECT IDENTIFIER ::= {org 6}

• internet OBJECT IDENTIFIER ::= {dod 1}

• directory OBJECT IDENTIFIER  ::= {internet 1}

• mgmt  OBJECT IDENTIFIER  ::= {internet 2}

• mib-2  OBJECT IDENTIFIER  ::= {mgmt 1}

• transmission  OBJECT IDENTIFIER  ::= {mib-2 10}

• experimental  OBJECT IDENTIFIER  ::= {internet 3}

• private  OBJECT IDENTIFIER  ::= {internet 4}

• enterprises  OBJECT IDENTIFIER  ::= {private 1}

• security  OBJECT IDENTIFIER  ::= {internet 5}

• snmpV2  OBJECT IDENTIFIER  ::= {internet 6}

• snmpDomains  OBJECT IDENTIFIER  ::= {snmpV2 1}

• snmpProxys  OBJECT IDENTIFIER  ::= {snmpV2 2}

• snmpModules  OBJECT IDENTIFIER  ::= {snmpV2 3}

Object Identifiers

Relative and Absolute Object Identifiers

The examples on object identifiers discussed so far specifies the path to the variable always from the root of the OID tree. For example, the zoho object identifier .1.3.6.1.4.1.2162 specifies the path from the root of the tree. (The root does not have a name or a number, but the initial 1 in this OID is directly below root.) These are called absolute OIDs. However, a path to the variable may be specified relative to some node in the OID tree. For example, 2.1.1.7 specifies the sysContact object in the system group, relative to the internet (.1.3.6.1) node in the OID tree. This is called a relative OID.

Specifying Object Identifiers Symbolically

Until now, we have used only a series of integers separated by dots, called "dot-dot" notation, to describe OIDs. However, an OID can also be expressed symbolically, or by a combination of both integers and textual symbols. A symbolic OID uses mnemonic keywords to specify the managed object; for example:

mgmt.mib-2.system.sysDescr

The following numeric OID uses integers to specify the same managed object:

2.1.1.1

Note that this example is a relative OID. An OID may combine both symbolic and numeric representations of individual nodes of the OID tree; for example:

mgmt.mib-2.1.sysDescr

Absolute OID names always begin with a dot and must specify every node of the OID tree from the top-most node to the specific managed object:

.iso.org.dod.internet.mgmt.mib.system.sysDescr
.1.3.6.1.2.1.1.1
.iso.3.dod.1.mgmt.mib-2.1.sysDescr

Object Identifier with Instance Indexes

To obtain values of objects from the manager, it is necessary to specify the instance of the object. The instance of an object is specified by appending an instance index to the object identifier. For example, the last 0 in:

.iso.3.dod.1.mgmt.mib.1.sysUpTime.0

is the instance index. An instance index of "0" (zero) specifies the first instance, "1" specifies the second instance, and so on. Since sysUpTime is a scalar object, it has only one instance. Therefore, an instance index of zero is always specified when retrieving the value of a scalar object. An instance index higher than 0 can only be used in the case of columnar objects ( in table ), which can have multiple instances.

Suppose the employee table we saw above has the following data:

empNumber (index column)	empName	empAge
1	xxx	25
2	yyy	30
3	zzz	28

If a manager wants to do a snmpget and get the name of the 2nd employee then the manager will send a get request with the following OID:

.1.3.6.1.4.1.2162.1.1.2.2 (where 2 is the instance). So "yyy" will be returned from the agent as response to the manager.

Scalar and Tabular Objects

A managed object has both a type (defined in ASN.1) and a value. For example, the SNMP system group variable sysLocation ( this variable is defined in RFC1213-MIB ) has the type, DisplayString and may have the value, "WebNMS Velachery". So in our case, we can define noOfPapers or inkLevel of the printer as a scalar object in the MIB.

Managed objects, in SNMP, are of two types : scalar objects and tabular objects.

A managed object that always has a single instance is called a scalar object. Tabular objects, on the other hand, have multiple instances, such as the rows of a table. For example, the MIB II system group has seven "leaf" variables under it, as illustrated in Figure below. Each of these objects is a scalar object. For example, the value of sysUpTime is the duration of time since re-initialization of a system's network management software (SNMP agent), measured in hundredths of a second.

Tables in SNMP are two-dimensional objects defined as an ASN.1 type called SEQUENCE OF, which allows 0 or more members. Each element of the sequence is an entry (row) in the table, which itself is a sequence of scalar-valued objects. SNMP does not allow tables to be nested within tables.

For example, the MIB II at group contains simply one tabular object, the atTable, which contains one row for each of a system's physical interfaces. Each row in the table is an instance of the object atEntry. Each row contains instances of the scalar-valued leaf objects atIfIndex, atPhysAddress, and atNetAddress. The leaf objects are called columnar objects since the instances of each such object constitute one column in the table. Although these objects have scalar-valued instances, they are not scalar objects because they can have multiple instances.

Another example for a table is, consider an organization. Each organization will have Employees. Suppose we want to define it in a MIB, we cannot go for scalar objects. We can define it in table format only.

How an Agent Works

An agent communicates with an SNMP manager, on the one hand, and the device or application ( so called Managed resource ) on the other hand, in the following way:

The SNMP manager sends an SNMP PDU ( Protocol Data Unit ) to the agent. This PDU contains an encoded request (such as a request to GET the value, or SET the value, of a specific managed object).

When the agent receives the request, it parses the SNMP PDU (ASN.1 decoding) to determine the type of request (i.e., GET or SET) and the MIB group, and invokes the appropriate access function corresponding to the object within the MIB group.

The access function does the actual work of retrieving the object's current value (for a GET request) or modifying the object's value (for a SET request). The method used to perform the GET or SET depends on where the managed object resides (i.e., UNIX kernel, shared memory, file, or in another process) and does not involve SNMP. If the object resides in another process, you can use shared memory or a proprietary protocol, such as Sun RPC/XDR or DCE RPC.

Depending on the value received from the access function, the agent hook layer returns one of the following responses to the agent core:

• A value from a GET function

• An OK from a SET function

• An ERROR, if an error occurred

The agent core receives the response from the agent hook and builds the SNMP PDU (ASN.1 encoding). It then sends the response PDU to the SNMP manager.

Traps

In addition to retrieving data from the managed resource in response to requests from a management station, agents also send unsolicited messages to managers when they detect some significant event. An unsolicited message of this sort is called a trap notification. The fields that comprise the SNMP trap PDU occur in the order shown below:

PDU type

enterprise

agent address

generic trap type

specific trap type

time stamp

variable bindings

The fields have the following meaning:

• PDU type identifies the packet as a trap notification.

• enterprise is the vendor identification (OID) for the network management sub-system that generated the trap (.1.3.6.1.4.1.2162).

• agent address is the IP address of the node where the trap was generated.

• generic trap type is an integer in the range of 0 to 6. These values have the meanings indicated in Table 2-1.

• specific trap type is a number that further specifies the nature of the event that generated the trap in the case of traps of generic type 6 (enterpriseSpecific). The interpretation of this code is vendor-specific.

• timestamp is the duration between the last re-initialization of the agent that issued the trap and the time at which the trap was issued.

• variable bindings provide additional information pertaining to the trap. This field consists of name/value pairs. The significance of this field is vendor-specific.

The interpretation of generic trap types is described below:

Generic Trap Number	Name of Trap Type	Interpretation
0	coldStart	The agent that sends this trap re-initializes itself due to a reboot.
1	warmStart	The agent that sends this trap re-initializes itself due to a normal restart.
2	linkDown	One of the communication links on the agent node has failed. The first element in the variable bindings contains the name and value of the ifIndex instance for the downed interface.
3	linkUp	One of the communication links on the agent node has come up. The first element in the variable bindings is the name and value of the ifIndex instance for the affected interface.
4	authenticationFailure	The agent is reporting that it has received a request with an invalid community specification or a community with insufficient permissions to complete the request.
5	egpNeighborLoss:	相關推薦 snmp mib 資料型別 SNMP Overview SNMP Overview The Simple Network Management Protocol (SNMP) is by far the dominant protocol in network management. This net-snmp擴充套件trap型別的私有mib 注：本文介紹的是靜態編譯的方法擴充套件的私有mib，別的方法請看本人整理的《net-snmp agent開發（用net-snmp擴充套件MIB庫）》 1. 首先建立一個簡單的含有table變數的mib檔案取名test-trap.mib，字尾名也可以是.txt 實際操作 PHP報錯Cannot adopt OID in UCD-SNMP-MIB、 LM-SENSORS-MIB fig agg ror 怎麽辦 all output agent org temp Cannot adopt OID in UCD-SNMP-MIB: Cannot adopt OID in LM-SENSORS-MIB: lmTempSensorsValue 運行PHP遇 lwip 2.0.2 snmp mib ipv6 signed sna bject known sys OS ipmi face nbsp Submitted by Harald.T.Alvestrand at uninett.no from host aun.uninett.no (129.241.1.99) using c理解提高（1）資料型別的本質分析 資料型別本質分析 資料型別概念 “型別”是對資料的抽象  型別相同的資料有相同的表示形式、儲存格式以及相關的操作  程式中使用的所有資料都必定屬於某一種資料型別   資料型別的本質思考  思考資料型別和 Java中8種基本資料型別及其預設值 Java語言中有8種基本資料型別，基本情況彙總如下： Java中8種基本資料型別總結 序號 資料型別 大小/位 封裝類 預設值 可表示資料 JAVA面試知識點總結--資料型別 一、資料型別 基本資料型別 數值型別： 運算and型別轉換 自動裝拆箱and比較 bool redis安裝及其資料型別簡介 Windows下安裝 redis的安裝十分簡單，首先從github上下載安裝包，地址：下載地址 下載完成後解壓到c盤，為了方便操作可以將解壓後的檔案重新命名為“redis”，然後開啟一個cmd 視窗使用cd命令切換目錄到 C:\redis 之後輸入redis-server.ex 包裝類（Integer/Boolean等、字串與基本資料型別轉化，-127-128自動裝箱入池) 為什麼要有包裝類？ Object類可以接收所有引用資料型別。然而在Java中，資料型別分為基本資料型別和引用資料型別，那麼基本資料型別如何處理呢？ 使用包裝類 ：包裝類是將基本資料型別封裝到類中，因為Object無法接受基本資料型別，封裝成類後就可以用Object類來接收。 簡單定義一個in Object類（覆寫toString/equals/接收引用資料型別） 什麼是Objetc類？ Object是JAVA預設提供的類。 在Java中除了Object類，所有的類都有繼承關係，預設會繼承Object父類，所有類物件都可以通過Object類進行接收，即向上轉型。 ////Object可以接收任何類 class A{} class B{} publi Java初認識--基本資料型別（int 和byte之間賦值）預設值 型別強轉 主類和主方法 Test.java–是原始檔，原始檔必須與主類名(public class )保持一致，一個原始檔只能有一個主類 ，主方法存在與主類中。 Test.java 原始檔 主類：public class Test 主方法 ： public static void main(Strin JS中資料型別的分類 JS中資料型別的分類： (1).基本資料型別： 1.數字（number） 2.字串（string） 3.布林（boolean） 4.null 5.undefined (2).引用資料型別： 1.物件資料型別（object） 2.函式資料型別（function） 萬惡之源 - Python基礎資料型別三 字典 　　字典的簡單介紹 　　字典(dict)是python中唯⼀的⼀個對映型別.他是以{ }括起來的鍵值對組成. 　　在dict中key是 唯⼀的.在儲存的時候, 根據key來計算出⼀個記憶體地址. 然後將key-value儲存在這個地址中. 　　這種演算法被稱為hash演算法, 所以, 切記, 在 四、資料庫之資料型別   首先補充點了解的小知識; select * from mysql.user #顯示出來亂了 select * from mysql.user\G #加了\G後一行一行顯示了 一、資料型別:分不同種類去存不同型別的資料 儲存引 深入瞭解以太坊虛擬機器第2部分——固定長度資料型別的表示方法 在本系列的第一篇文章中，我們已經看到了一個簡單的Solidity合約的彙編程式碼： contract C { uint256 a; function C() { a = 1; } } 該合約歸結於sstore指令的呼叫： // a = 1 sstore(0x0, js的本質/資料型別 js的本質就是處理資料，資料來自於後臺的資料庫 所以變數就起到了一個臨時儲存資料的作用。 ECMAScript制定了js的資料型別 資料型別 string，number，boolean，null，undefined，object是基本資料型別 基本資料型別就是簡單的賦值 function obje mongodb修改欄位資料型別 今天遇到一個很尷尬的應用場景，因為新架構之前，我們mongodb的yfy_score_record表中DATE_TIME欄位的型別是string型別，後來上了新架構之後DATE_TIME欄位變成DateTime型別了，然後統計某一個月內資料的時候就出現問題了，因為string型別的資料查詢方式和 深入瞭解以太坊虛擬機器第3部分——動態資料型別的表示方法 Solidity提供了在其他程式語言常見的資料型別。除了簡單的值型別比如數字和結構體，還有一些其他資料型別，隨著資料的增加可以進行動態擴充套件的動態型別。動態型別的3大類： 對映(Mappings)：mapping(bytes32 => uint256)， mapping(addres js 資料型別 1.     js的本質就是處理資料。資料來自於後臺的資料庫。 所以變數就起到一個臨時儲存資料的作用。 ECMAScript制定了js的資料型別。 資料型別有哪些？ 1.        字串& python基礎—基本資料型別二（set 集合,深淺拷貝） 1、基礎資料型別彙總補充 str int list bool dict tuple 2、集合 set {} 可變的資料型別，（不可雜湊）裡面的元素必須是不可變的資料型別，無序，不重複 以下是集合最重要的兩點： 　　去重，把一個列表變成集合，就自動去重了。 　　關係測試，測試兩組資料之前的