DHCP的RFC文档-RFC2131
Network Working Group R. Droms
Request for Comments: 2131 Bucknell University
Obsoletes: 1541 March 1997
Category: Standards Track
Dynamic Host Configuration Protocol
Status of this memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Abstract
The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCPIP network. DHCP is based on the Bootstrap Protocol (BOOTP) [7], adding the
capability of automatic allocation of reusable network addresses and additional configuration options [19]. DHCP captures the behavior of BOOTP relay agents [7, 21], and DHCP participants can interoperate with BOOTP participants [9].
Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1 Changes to RFC1541. . . . . . . . . . . . . . . . . . . . . . 3 1.2 Related Work. . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3 Problem definition and issues . . . . . . . . . . . . . . . . 4 1.4 Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 5 1.5 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.6 Design goals. . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Protocol Summary. . . . . . . . . . . . . . . . . . . . . . . 8 2.1 Configuration parameters repository . . . . . . . . . . . . . 11
2.2 Dynamic allocation of network addresses . . . . . . . . . . . 12
3. The Client-Server Protocol. . . . . . . . . . . . . . . . . . 13 3.1 Client-server interaction - allocating a network address. . . 13 3.2 Client-server interaction - reusing a previously allocated
network address . . . . . . . . . . . . . . . . . . . . . . . 17 3.3 Interpretation and representation of time values. . . . . . . 20 3.4 Obtaining parameters with externally configured network
address . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.5 Client parameters in DHCP . . . . . . . . . . . . . . . . . . 21 3.6 Use of DHCP in clients with multiple interfaces . . . . . . . 22
3.7 When clients should use DHCP. . . . . . . . . . . . . . . . . 22
4. Specification of the DHCP client-server protocol. . . . . . . 22
Droms Standards Track [Page 1]
RFC 2131 Dynamic Host Configuration Protocol March 1997
4.1 Constructing and sending DHCP messages. . . . . . . . . . . . 22 4.2 DHCP server administrative controls . . . . . . . . . . . . . 25 4.3 DHCP server behavior. . . . . . . . . . . . . . . . . . . . . 26
4.4 DHCP client behavior. . . . . . . . . . . . . . . . . . . . . 34
5. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . .42
6. References . . . . . . . . . . . . . . . . . . . . . . . . . .42
7. Security Considerations. . . . . . . . . . . . . . . . . . . .43
8. Author's Address . . . . . . . . . . . . . . . . . . . . . . .44
A. Host Configuration Parameters . . . . . . . . . . . . . . . .45 List of Figures
1. Format of a DHCP message . . . . . . . . . . . . . . . . . . . 9
2. Format of the 'flags' field. . . . . . . . . . . . . . . . . . 11
3. Timeline diagram of messages exchanged between DHCP client and servers when allocating a new network address. . . . . . . . . 15
4. Timeline diagram of messages exchanged between DHCP client and servers when reusing a previously allocated network address. . 18
5. State-transition diagram for DHCP clients. . . . . . . . . . . 34 List of Tables
1. Description of fields in a DHCP message. . . . . . . . . . . . 10
2. DHCP messages. . . . . . . . . . . . . . . . . . . . . . . . . 14
3. Fields and options used by DHCP servers. . . . . . . . . . . . 28
4. Client messages from various states. . . . . . . . . . . . . . 33
5. Fields and options used by DHCP clients. . . . . . . . . . . . 37 1. Introduction
The Dynamic Host Configuration Protocol (DHCP) provides configuration parameters to Internet hosts. DHCP consists of two components: a protocol for delivering host-specific configuration parameters from a
DHCP server to a host and a mechanism for allocation of network
addresses to hosts.
DHCP is built on a client-server model, where designated DHCP server hosts allocate network addresses and deliver configuration parameters to dynamically configured hosts. Throughout the remainder of this document, the term "server" refers to a host providing initialization parameters through DHCP, and the term "client" refers to a host
requesting initialization parameters from a DHCP server.
A host should not act as a DHCP server unless explicitly configured to do so by a system administrator. The diversity of hardware and protocol implementations in the Internet would preclude reliable operation if random hosts were allowed to respond to DHCP requests. For example, IP requires the setting of many parameters within the protocol implementation software. Because IP can be used on many dissimilar kinds of network hardware, values for those parameters cannot be guessed or assumed to have correct defaults. Also,
distributed address allocation schemes depend on a polling/defense
Droms Standards Track [Page 2]
RFC 2131 Dynamic Host Configuration Protocol March 1997
mechanism for discovery of addresses that are already in use. IP hosts may not always be able to defend their network addresses, so that such a distributed address allocation scheme cannot be
guaranteed to avoid allocation of duplicate network addresses.
DHCP supports three mechanisms for IP address allocation. In
"automatic allocation", DHCP assigns a permanent IP address to a
client. In "dynamic allocation", DHCP assigns an IP address to a client for a limited period of time (or until the client explicitly relinquishes the address). In "manual allocation", a client's IP address is assigned by the network administrator, and DHCP is used simply to convey the assigned address to the client. A particular network will use one or more of these mechanisms, depending on the policies of the network administrator.
Dynamic allocation is the only one of the three mechanisms that
allows automatic reuse of an address that is no longer needed by the client to which it was assigned. Thus, dynamic allocation is
particularly useful for assigning an address to a client that will be connected to the network only temporarily or for sharing a limited pool of IP addresses among a group of clients that do not need
permanent IP addresses. Dynamic allocation may also be a good choice for assigning an IP address to a new client being permanently
connected to a network where IP addresses are sufficiently scarce that it is important to reclaim them when old clients are retired. Manual allocation allows DHCP to be used to eliminate the error-prone process of manually configuring hosts with IP addresses in
environments where (for whatever reasons) it is desirable to manage IP address assignment outside of the DHCP mechanisms.
The format of DHCP messages is based on the format of BOOTP messages, to capture the BOOTP relay agent behavior described as part of the BOOTP specification [7, 21] and to allow interoperability of existing BOOTP clients with DHCP servers. Using BOOTP relay agents eliminates the necessity of having a DHCP server on each physical network
segment.
1.1 Changes to RFC 1541
This document updates the DHCP protocol specification that appears in RFC1541. A new DHCP message type, DHCPINFORM, has been added; see section 3.4, 4.3 and 4.4 for details. The classing mechanism for identifying DHCP clients to DHCP servers has been extended to include "vendor" classes as defined in sections 4.2 and 4.3. The minimum lease time restriction has been removed. Finally, many editorial changes have been made to clarify the text as a result of experience gained in DHCP interoperability tests.
Droms Standards Track [Page 3]
RFC 2131 Dynamic Host Configuration Protocol March 1997
1.2 Related Work
There are several Internet protocols and related mechanisms that address some parts of the dynamic host configuration problem. The Reverse Address Resolution Protocol (RARP) [10] (through the
extensions defined in the Dynamic RARP (DRARP) [5]) explicitly
addresses the problem of network address discovery, and includes an automatic IP address assignment mechanism. The Trivial File Transfer Protocol (TFTP) [20] provides for transport of a boot image from a boot server. The Internet Control Message Protocol (ICMP) [16]
provides for informing hosts of additional routers via "ICMP
redirect" messages. ICMP also can provide subnet mask information through the "ICMP mask request" message and other information through the (obsolete) "ICMP information request" message. Hosts can locate routers through the ICMP router discovery mechanism [8].
BOOTP is a transport mechanism for a collection of configuration information. BOOTP is also extensible, and official extensions [17] have been defined for several configuration parameters. Morgan has proposed extensions to BOOTP for dynamic IP address assignment [15]. The Network Information Protocol (NIP), used by the Athena project at MIT, is a distributed mechanism for dynamic IP address assignment [19]. The Resource Location Protocol RLP [1] provides for location of higher level services. Sun Microsystems diskless workstations use a boot procedure that employs RARP, TFTP and an RPC mechanism called "bootparams" to deliver configuration information and operating
system code to diskless hosts. (Sun Microsystems, Sun Workstation and SunOS are trademarks of Sun Microsystems, Inc.) Some Sun
networks also use DRARP and an auto-installation mechanism to
automate the configuration of new hosts in an existing network.
In other related work, the path minimum transmission unit (MTU)
discovery algorithm can determine the MTU of an arbitrary internet path [14]. The Address Resolution Protocol (ARP) has been proposed as a transport protocol for resource location and selection [6]. Finally, the Host Requirements RFCs [3, 4] mention specific
requirements for host reconfiguration and suggest a scenario for
initial configuration of diskless hosts.
1.3 Problem definition and issues
DHCP is designed to supply DHCP clients with the configuration
parameters defined in the Host Requirements RFCs. After obtaining parameters via DHCP, a DHCP client should be able to exchange packets with any other host in the Internet. The TCP/IP stack parameters supplied by DHCP are listed in Appendix A.
Droms Standards Track [Page 4]
RFC 2131 Dynamic Host Configuration Protocol March 1997
Not all of these parameters are required for a newly initialized client. A client and server may negotiate for the transmission of only those parameters required by the client or specific to a
particular subnet.
DHCP allows but does not require the configuration of client
parameters not directly related to the IP protocol. DHCP also does not address registration of newly configured clients with the Domain Name System (DNS) [12, 13].
DHCP is not intended for use in configuring routers.
1.4 Requirements
Throughout this document, the words that are used to define the
significance of particular requirements are capitalized. These words are:
o "MUST"
This word or the adjective "REQUIRED" means that the
item is an absolute requirement of this specification.
o "MUST NOT"
This phrase means that the item is an absolute prohibition
of this specification.
o "SHOULD"
This word or the adjective "RECOMMENDED" means that there
may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course.
o "SHOULD NOT"
This phrase means that there may exist valid reasons in
particular circumstances when the listed behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
Droms Standards Track [Page 5]
RFC 2131 Dynamic Host Configuration Protocol March 1997
o "MAY"
This word or the adjective "OPTIONAL" means that this item is truly optional. One vendor may choose to include the item
because a particular marketplace requires it or because it
enhances the product, for example; another vendor may omit the same item.
1.5 Terminology
This document uses the following terms:
o "DHCP client"
A DHCP client is an Internet host using DHCP to obtain
configuration parameters such as a network address.
o "DHCP server"
A DHCP server is an Internet host that returns configuration
parameters to DHCP clients.
o "BOOTP relay agent"
A BOOTP relay agent or relay agent is an Internet host or router that passes DHCP messages between DHCP clients and DHCP servers. DHCP is designed to use the same relay agent behavior as specified in the BOOTP protocol specification.
o "binding"
A binding is a collection of configuration parameters, including at least an IP address, associated with or "bound to" a DHCP
client. Bindings are managed by DHCP servers.
1.6 Design goals
The following list gives general design goals for DHCP.
o DHCP should be a mechanism rather than a policy. DHCP must allow local system administrators control over configuration parameters where desired; e.g., local system administrators should be able to enforce local policies concerning allocation and access to local resources where desired.
Droms Standards Track [Page 6]
RFC 2131 Dynamic Host Configuration Protocol March 1997
o Clients should require no manual configuration. Each client should be able to discover appropriate local configuration
parameters without user intervention and incorporate those
parameters into its own configuration.
o Networks should require no manual configuration for individual clients. Under normal circumstances, the network manager
should not have to enter any per-client configuration
parameters.
o DHCP should not require a server on each subnet. To allow for scale and economy, DHCP must work across routers or through the intervention of BOOTP relay agents.
o A DHCP client must be prepared to receive multiple responses to a request for configuration parameters. Some installations may include multiple, overlapping DHCP servers to enhance
reliability and increase performance.
o DHCP must coexist with statically configured, non-participating hosts and with existing network protocol implementations.
o DHCP must interoperate with the BOOTP relay agent behavior as described by RFC 951 and by RFC 1542 [21].
o DHCP must provide service to existing BOOTP clients.
The following list gives design goals specific to the transmission of the network layer parameters. DHCP must:
o Guarantee that any specific network address will not be in
use by more than one DHCP client at a time,
o Retain DHCP client configuration across DHCP client reboot. A DHCP client should, whenever possible, be assigned the same configuration parameters (e.g., network address) in response to each request,
o Retain DHCP client configuration across server reboots, and,
whenever possible, a DHCP client should be assigned the same configuration parameters despite restarts of the DHCP mechanism,
o Allow automated assignment of configuration parameters to new clients to avoid hand configuration for new clients,
o Support fixed or permanent allocation of configuration
parameters to specific clients.
Droms Standards Track [Page 7]
RFC 2131 Dynamic Host Configuration Protocol March 1997
2. Protocol Summary
From the client's point of view, DHCP is an extension of the BOOTP mechanism. This behavior allows existing BOOTP clients to
interoperate with DHCP servers without requiring any change to the clients' initialization software. RFC 1542 [2] details the
interactions between BOOTP and DHCP clients and servers [9]. There are some new, optional transactions that optimize the interaction between DHCP clients and servers that are described in sections 3 and 4.
Figure 1 gives the format of a DHCP message and table 1 describes each of the fields in the DHCP message. The numbers in parentheses indicate the size of each field in octets. The names for the fields given in the figure will be used throughout this document to refer to the fields in DHCP messages.
There are two primary differences between DHCP and BOOTP. First, DHCP defines mechanisms through which clients can be assigned a
network address for a finite lease, allowing for serial reassignment of network addresses to different clients. Second, DHCP provides the mechanism for a client to acquire all of the IP configuration
parameters that it needs in order to operate.
DHCP introduces a small change in terminology intended to clarify the
meaning of one of the fields. What was the "vendor extensions" field in BOOTP has been re-named the "options" field in DHCP. Similarly, the tagged data items that were used inside the BOOTP "vendor
extensions" field, which were formerly referred to as "vendor
extensions," are now termed simply "options."
Droms Standards Track [Page 8]
RFC 2131 Dynamic Host Configuration Protocol March 1997
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | op (1) | htype (1) | hlen (1) | hops (1) | +---------------+---------------+---------------+---------------+ | xid (4) | +-------------------------------+-------------------------------+ | secs (2) | flags (2) | +-------------------------------+-------------------------------+ | ciaddr (4) | +---------------------------------------------------------------+
| yiaddr (4) | +---------------------------------------------------------------+ | siaddr (4) | +---------------------------------------------------------------+ | giaddr (4) | +---------------------------------------------------------------+ | | | chaddr (16) | | | | | +---------------------------------------------------------------+ | | | sname (64) | +---------------------------------------------------------------+ | | | file (128) | +---------------------------------------------------------------+ | | | options (variable) | +---------------------------------------------------------------+
Figure 1: Format of a DHCP message
DHCP defines a new 'client identifier' option that is used to pass an explicit client identifier to a DHCP server. This change eliminates the overloading of the 'chaddr' field in BOOTP messages, where
'chaddr' is used both as a hardware address for transmission of BOOTP reply messages and as a client identifier. The 'client identifier' is an opaque key, not to be interpreted by the server; for example, the 'client identifier' may contain a hardware address, identical to the contents of the 'chaddr' field, or it may contain another type of identifier, such as a DNS name. The 'client identifier' chosen by a DHCP client MUST be unique to that client within the subnet to which the client is attached. If the client uses a 'client identifier' in one message, it MUST use that same identifier in all subsequent
messages, to ensure that all servers correctly identify the client.
Droms Standards Track [Page 9]
RFC 2131 Dynamic Host Configuration Protocol March 1997
DHCP clarifies the interpretation of the 'siaddr' field as the
address of the server to use in the next step of the client's
bootstrap process. A DHCP server may return its own address in the 'siaddr' field, if the server is prepared to supply the next
bootstrap service (e.g., delivery of an operating system executable image). A DHCP server always returns its own address in the 'server identifier' option.
FIELD OCTETS DESCRIPTION
----- ------ -----------
op 1 Message op code / message type.
1 = BOOTREQUEST,
2 = BOOTREPLY
htype 1 Hardware address type, see ARP section in "Assigned Numbers" RFC; e.g., '1' = 10mb ethernet.
hlen 1 Hardware address length (e.g. '6' for 10mb
ethernet).
hops 1 Client sets to zero, optionally used by relay agents when booting via a relay agent.
xid 4 Transaction ID, a random number chosen by the
client, used by the client and server to associate messages and responses between a client and a
server.
secs 2 Filled in by client, seconds elapsed since client began address acquisition or renewal process.
flags 2 Flags (see figure 2).
ciaddr 4 Client IP address; only filled in if client is in BOUND, RENEW or REBINDING state and can respond to ARP requests.
yiaddr 4 'your' (client) IP address.
siaddr 4 IP address of next server to use in bootstrap;
returned in DHCPOFFER, DHCPACK by server.
giaddr 4 Relay agent IP address, used in booting via a
relay agent.
chaddr 16 Client hardware address.
sname 64 Optional server host name, null terminated string. file 128 Boot file name, null terminated string; "generic" name or null in DHCPDISCOVER, fully qualified
directory-path name in DHCPOFFER.
options var Optional parameters field. See the options
documents for a list of defined options.
Table 1: Description of fields in a DHCP message
The 'options' field is now variable length. A DHCP client must be prepared to receive DHCP messages with an 'options' field of at least length 312 octets. This requirement implies that a DHCP client must be prepared to receive a message of up to 576 octets, the minimum IP
Droms Standards Track [Page 10]
RFC 2131 Dynamic Host Configuration Protocol March 1997
datagram size an IP host must be prepared to accept [3]. DHCP
clients may negotiate the use of larger DHCP messages through the 'maximum DHCP message size' option. The options field may be further extended into the 'file' and 'sname' fields.
In the case of a client using DHCP for initial configuration (before the client's TCP/IP software has been completely configured), DHCP requires creative use of the client's TCP/IP software and liberal interpretation of RFC 1122. The TCP/IP software SHOULD accept and forward to the IP layer any IP packets delivered to the client's hardware address before the IP address is configured; DHCP servers and BOOTP relay agents may not be able to deliver DHCP messages to clients that cannot accept hardware unicast datagrams before the TCP/IP software is configured.
To work around some clients that cannot accept IP unicast datagrams before the TCP/IP software is configured as discussed in the previous paragraph, DHCP uses the 'flags' field [21]. The leftmost bit is defined as the BROADCAST (B) flag. The semantics of this flag are discussed in section 4.1 of this document. The remaining bits of the flags field are reserved for future use. They MUST be set to zero by clients and ignored by servers and relay agents. Figure 2 gives the format of the 'flags' field.
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B| MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
B: BROADCAST flag
MBZ: MUST BE ZERO (reserved for future use)
Figure 2: Format of the 'flags' field
2.1 Configuration parameters repository
The first service provided by DHCP is to provide persistent storage of network parameters for network clients. The model of DHCP
persistent storage is that the DHCP service stores a key-value entry for each client, where the key is some unique identifier (for
example, an IP subnet number and a unique identifier within the
subnet) and the value contains the configuration parameters for the client.
For example, the key might be the pair (IP-subnet-number, hardware- address) (note that the "hardware-address" should be typed by the
Droms Standards Track [Page 11]
RFC 2131 Dynamic Host Configuration Protocol March 1997
type of hardware to accommodate possible duplication of hardware addresses resulting from bit-ordering problems in a mixed-media, bridged network) allowing for serial or concurrent reuse of a
hardware address on different subnets, and for hardware addresses that may not be globally unique. Alternately, the key might be the pair (IP-subnet-number, hostname), allowing the server to assign parameters intelligently to a DHCP client that has been moved to a different subnet or has changed hardware addresses (perhaps because the network interface failed and was replaced). The protocol defines that the key will be (IP-subnet-number, hardware-address) unless the client explicitly supplies an identifier using the 'client
identifier' option. A client can query the DHCP service to
retrieve its configuration parameters. The client interface to the configuration parameters repository consists of protocol messages to request configuration parameters and responses from the server
carrying the configuration parameters.
2.2 Dynamic allocation of network addresses
The second service provided by DHCP is the allocation of temporary or permanent network (IP) addresses to clients. The basic mechanism for the dynamic allocation of network addresses is simple: a client
requests the use of an address for some period of time. The
allocation mechanism (the collection of DHCP servers) guarantees not to reallocate that address within the requested time and attempts to return the same network address each time the client requests an address. In this document, the period over which a network address is allocated to a client is referred to as a "lease" [11]. The
client may extend its lease with subsequent requests. The client may issue a message to release the address back to the server when the client no longer needs the address. The client may ask for a
permanent assignment by asking for an infinite lease. Even when assigning "permanent" addresses, a server may choose to give out lengthy but non-infinite leases to allow detection of the fact that the client has been retired.
In some environments it will be necessary to reassign network
addresses due to exhaustion of available addresses. In such
environments, the allocation mechanism will reuse addresses whose lease has expired. The server should use whatever information is available in the configuration information repository to choose an address to reuse. For example, the server may choose the least
recently assigned address. As a consistency check, the allocating server SHOULD probe the reused address before allocating the address, e.g., with an ICMP echo request, and the client SHOULD probe the newly received address, e.g., with ARP.
Droms Standards Track [Page 12]
RFC 2131 Dynamic Host Configuration Protocol March 1997
3. The Client-Server Protocol
DHCP uses the BOOTP message format defined in RFC 951 and given in table 1 and figure 1. The 'op' field of each DHCP message sent from a client to a server contains BOOTREQUEST. BOOTREPLY is used in the 'op' field of each DHCP message sent from a server to a client.
The first four octets of the 'options' field of the DHCP message contain the (decimal) values 99, 130, 83 and 99, respectively (this is the same magic cookie as is defined in RFC 1497 [17]). The
remainder of the 'options' field consists of a list of tagged
parameters that are called "options". All of the "vendor extensions" listed in RFC 1497 are also DHCP options. RFC 1533 gives the
complete set of options defined for use with DHCP.
Several options have been defined so far. One particular option - the "DHCP message type" option - must be included in every DHCP
message. This option defines the "type" of the DHCP message.
Additional options may be allowed, required, or not allowed,
depending on the DHCP message type.
Throughout this document, DHCP messages that include a 'DHCP message type' option will be referred to by the type of the message; e.g., a DHCP message with 'DHCP message type' option type 1 will be referred to as a "DHCPDISCOVER" message.
3.1 Client-server interaction - allocating a network address
The following summary of the protocol exchanges between clients and servers refers to the DHCP messages described in table 2. The
timeline diagram in figure 3 shows the timing relationships in a typical client-server interaction. If the client already knows its address, some steps may be omitted; this abbreviated interaction is described in section 3.2.
1. The client broadcasts a DHCPDISCOVER message on its local physical subnet. The DHCPDISCOVER message MAY include options that suggest values for the network address and lease duration. BOOTP relay agents may pass the message on to DHCP servers not on the same physical subnet.
2. Each server may respond with a DHCPOFFER message that includes an
available network address in the 'yiaddr' field (and other
configuration parameters in DHCP options). Servers need not
reserve the offered network address, although the protocol will work more efficiently if the server avoids allocating the offered network address to another client. When allocating a new address, servers SHOULD check that the offered network address is not
Droms Standards Track [Page 13]
RFC 2131 Dynamic Host Configuration Protocol March 1997
already in use; e.g., the server may probe the offered address with an ICMP Echo Request. Servers SHOULD be implemented so that network administrators MAY choose to disable probes of newly
allocated addresses. The server transmits the DHCPOFFER message to the client, using the BOOTP relay agent if necessary.
Message Use
------- ---
DHCPDISCOVER - Client broadcast to locate available servers.
DHCPOFFER - Server to client in response to DHCPDISCOVER with offer of configuration parameters.
DHCPREQUEST - Client message to servers either (a) requesting
offered parameters from one server and implicitly declining offers from all others, (b) confirming correctness of previously allocated address after, e.g., system reboot, or (c) extending the lease on a particular network address.
DHCPACK - Server to client with configuration parameters,
including committed network address.
DHCPNAK - Server to client indicating client's notion of network
address is incorrect (e.g., client has moved to new subnet) or client's lease as expired
DHCPDECLINE - Client to server indicating network address is already
in use.
DHCPRELEASE - Client to server relinquishing network address and cancelling remaining lease.
DHCPINFORM - Client to server, asking only for local configuration parameters; client already has externally configured network address.
Table 2: DHCP messages
Droms Standards Track [Page 14]
RFC 2131 Dynamic Host Configuration Protocol March 1997
Server Client Server
(not selected) (selected)
v v v
| | |
| Begins initialization |
| | |
| _____________/|\____________ |
|/DHCPDISCOVER | DHCPDISCOVER \|
| | |
Determines | Determines
configuration | configuration
| | |
|\ | ____________/ |
| \________ | /DHCPOFFER |
| DHCPOFFER\ |/ |
| \ | |
| Collects replies |
| \| |
| Selects configuration |
| | |
| _____________/|\____________ |
|/ DHCPREQUEST | DHCPREQUEST\ |
| | |
| | Commits configuration
| | |
| | _____________/|
| |/ DHCPACK |
| | |
| Initialization complete |
| | |
. . .
. . .
| | |
| Graceful shutdown |
| | |
| |\ ____________ |
| | DHCPRELEASE \|
| | |
| | Discards lease
| | |
v v v
Figure 3: Timeline diagram of messages exchanged between DHCP
client and servers when allocating a new network address
Droms Standards Track [Page 15]
RFC 2131 Dynamic Host Configuration Protocol March 1997
数据库需求分析
数据库设计：需求分析? 设计一个性能良好的数据库系统，明确应用环境对系统的要求是首要的和基本的。因此，应该把对用户需求的收集和分析作为数据库设计的第一步。 需求分析的主要任务是通过详细调查要处理的对象，包括某个组织、某个部门、某个企业的业务管理等，充分了解原手工或原计算机系统的工作概况及工作流程，明确用户的各种需求，产生数据流图和数据字典，然后在此基础上确定新系统的功能，并产生需求说明书。值得注意的是，新系统必须充分考虑今后可能的扩充和改变，不能仅仅按当前应用需求来设计数据库。 如图所示，需求分析具体可按以下几步进行： (1)?? 用户需求的收集。 (2)?? 用户需求的分析。 (3)?? 撰写需求说明书。 图 ?需求分析的过程 需求分析的重点是调查、收集和分析用户数据管理中的信息需求、处理需求、安全性与完整性要求。信息需求是指用户需要从数据库中获得的信息的内容和性质。由用户的信息需求可以导出数据需求，即在数据库中应该存储哪些数据。处理需求是指用户要求完成什么处理功能，对某种处理要求的响应时间，处理方式指是联机处理还是批处理等。明确用户的处理需求，将有利于后期应用程序模块的设计。 调查、收集用户要求的具体做法是： (1)?? 了解组织机构的情况，调查这个组织由哪些部门组成，各部门的职责是什么，为分析信息流程做准备。
(2)?? 了解各部门的业务活动情况，调查各部门输入和使用什么数据，如何加工处理这些数据。输出什么信息，输出到什么部门，输出的格式等。在调查活动的同时，要注意对各种资料的收集，如票证、单据、报表、档案、计划、合同等，要特别注意了解这些报表之间的关系，各数据项的含义等。 (3)?? 确定新系统的边界。确定哪些功能由计算机完成或将来准备让计算机完成，哪些活动由人工完成。由计算机完成的功能就是新系统应该实现的功能。 在调查过程中，根据不同的问题和条件，可采用的调查方法很多，如跟班作业、咨询业务权威、设计调查问卷、查阅历史记录等。但无论采用哪种方法，都必须有用户的积极参与和配合。强调用户的参与是数据库设计的一大特点。 收集用户需求的过程实质上是数据库设计者对各类管理活动进行调查研究的过程。设计人员与各类管理人员通过相互交流，逐步取得对系统功能的一致的认识。但是，由于用户还缺少软件设计方面的专业知识，而设计人员往往又不熟悉业务知识，要准确地确定需求很困难，特别是某些很难表达和描述的具体处理过程。针对这种情况，设计人员在自身熟悉业务知识的同时，应该帮助用户了解数据库设计的基本概念。对于那些因缺少现成的模式、很难设想新的系统、不知应有哪些需求的用户，还可应用原型化方法来帮助用户确定他们的需求。就是说，先给用户一个比较简单的、易调整的真实系统，让用户在熟悉使用它的过程中不断发现自己的需求，而设计人员则根据用户的反馈调整原型，反复验证最终协助用户发现和确定他们的真实需求。 调查了解用户的需求后，还需要进一步分析和抽象用户的需求，使之转换为后续各设计阶段可用的形式。在众多分析和表达用户需求的方法中，结构化分析(Structured Analysis，SA)是一个简单实用的方法。SA方法采用自顶向下，逐层分解的方式分析系统，用数据流图(Data Flow Diagram，DFD)、数据字典(Data Dictionary，DD)描述系统。 1. 使用数据流图分析信息处理过程 数据流图是软件工程中专门描绘信息在系统中流动和处理过程的图形化工具。因为数据流图是逻辑系统的图形表示，即使不是专业的计算机技术人员也容易理解，所以是极好的交流工具。图给出了数据流图中所使用的符号及其含义。
如何申请刊号
如何申请刊号(2009-11-18 14:47:02)转载▼标签：主管单位刊号准印证xx期刊中国文化1. 申请刊号的关键:申请刊号的关键是寻找一个能负政治责任和新闻行政单位认可的主管单位，由其出面申请。为什么大家申请难，就是没有主管单位 1.1什么是主管单位:在我国新闻行政单位认可的主管单位有如下副厅以上的行政和事业单位（包括行政机关、学校、研究机构、事业单位、社会团体、协会、国有企业），或正县一级政府机构以上，(包括政协、人大、法院、检察院）或相当于县一级的如地市的新闻出版局，宣传部、广播电视局、日报社、新闻办、地市级总工会、纪律委员会、政法委、编制委，民族自治地区的科委，侨乡地区的侨办，大的出版社或其他认可的主管单位（如我国十四个副省级城市的副厅级单位和某些相当于副厅级民办大学和研究机构）。具体可以查寻当地的年鉴。 1.2.怎样寻找主管单位:由于要负政治责任，一般单位主管单位都不太愿意，根据经验。有两个渠道，一个是找到一个副省以上领导，退下的也可以，由他出面联系。另一个就是从下往上走，找到主管单位一定级别的主要领导。这很重要，没有他们支持无法申请。 2.申请流程:中国刊号申请归口有四个单位，国家新闻出版署、国家科委，国家侨办，解放军总政治部。一般期刊通过省市新闻出版局报国家新闻出版署，科技类通过省市新闻出版局和省科委报国家科委再到新闻出版署。侨刊报国家侨办再到新闻出版署。 3.民间办刊关键:目前民间办刊的五个出口： 1) 科协、2) 工商联、3) 相当于副厅级民办大学和研究机构（如深圳综合研究院或海南改革发展研究院，另外有50个大的民办大学中有部分相当副厅级的）；4) 某些国家字头的学会、研究会、基金会、论坛。他们一般是部省级别领导下来办的事业单位，是民间协会。 5) 中图渠道和省新闻出版局的出版社渠道。 4.申请技巧和注意事项:一般申请需要先办6期以上的杂志，一般是用丛刊、协作出版、书号形式、光碟号形式、增刊形式、内部准印证形式。（千万不要用国际刊号）。要求期发行量如消费经济类在20000份以上、技术经济类5000以上、学术类1000以上（不能底于500份），我国目前有几百种发行量在500份左右的学术期刊，这是充分条件，但不是必要条件，但许多期刊是通过这样说服主管单位的或找到主管单位,一定要有过程。 5.如何通过挂靠主管单位合作出版 1) 直接申请，请几个副省级别的领导或院士出面做顾问，一般3个人以上，强调重要性、必要性，可行性和经费保障。向新闻行政单位或市科协，国家科协申请。能请到副委员长或政协副主席以上领导，会很快。 2) 如果是所在地区指标缺，可以请主管部门出面，到其他地区调一个刊号，一般也是选同行业方面的，将他的刊号转过来，他们的内容可以合到其他杂志。或他们的内容用协作出版的方式用书号出版。国际刊号不变。类似目前许多学术期刊形式。 3) 以上都是过程，有时申请可能需要一两年，对时机而言，时间太久，风险大。可以用收购合作的形式办，我们讲收购期刊也要通过主管单位进行。有省内收购和出省收购。有省内收购一般可以逐渐用新的主管单位接手。出省收购则需要用合办的形式或者购买一个新指标补偿原有的地区。 4) 与新闻出版局下的出版社合作，他们派编审，费用10000--15000元每期。他们可以帮你用增刊号的形式，或安排某杂志合办的方式。这一般是新办杂志的过度。 5) 打主管单位本身杂志的主意，捆绑在一起的方法，待市场培养较好后再创刊一种是 A、B卷形式将A卷为《要办的杂志》，B卷为原来的主管单位杂志，定价不变还是原样。但A卷为《要办的杂志》进入用打折的方式零售市场，如只卖？元等。另外是将主管单位杂志改书号协作出版将其刊号用于《要办的杂志》出版，但这样最好能改月刊或半月刊安排
WT整理国家对出版单位的管理
国家对出版单位的管理 版权所有：126电化教育WT(26122678) （本文仅限2011出版专业资格考试中级班同学学习使用，未经许可，任何人不得转载） 前言： 我国的出版单位包括“报社”、“期刊社”、“图书出版社”、“音像出版社”、“电子出版物出版社”和“互联网出版单位”。关于国家对这些出版单位的管理规定，分散在初级、中级的四本教材以及法律法规选编中。 虽然有关行政管理的知识对编辑实际工作意义并不大，但是考纲对这些内容的要求基本都是“掌握”，而且每年这类试题都不见少（据说“出一堆行政管理题是出题者为了拍领导马屁”，不管你信不信，反正我信了，呵呵）。所以有必要统一列出来，通过对照加深记忆。 一、设立出版物生产经营单位应具备哪些条件？ 答：我国出版行政管理有四大准入制度，即“法人准入”、“职业准入”、“岗位准入”和“产品准入”。无论是设立出版社，还是设立期刊社或非独立的期刊编辑部，都应该具备一定条件，这就是所谓的“法人准入”制度： 第一，有出版单位的名称、章程（创办期刊社，还要有确定的期刊名称）。 第二，有符合国务院出版行政主管部门认定的主办单位及其主管机关。 第三，有确定的业务范围。 第四，有符合国家规定的注册资本和固定的工作场所。 第五，有适应业务范围需要的组织机构和符合国家规定的资格条件的编辑出版专业人员。（注：《出版管理条例》对所有出版单位的设立提出30万以上注册资本的要求。 《音像制品出版管理规定》对设立音像出版单位特别提出，工作场所不低于200平方米，出版专业技术人员不少于10人，其中中级以上不得少于5人。 《电子出版物出版管理规定》对设立电子出版物出版单位特别提出，注册资本200万以上，工作场所不少于200平方米，中级以上出版专业技术人员不少于2人。） 第六，法律、行政法规规定的其他条件。 此外，审批设立出版单位，还要符合国家关于出版单位总量、结构、布局的规划。 二、我国对出版单位的设立实行什么制度？出版单位的变更和注销应办理什么手续？ 答：我国对出版单位的设立实行审批制度： 审批流程是：由主办单位向所在地“省局”申请，“省局”审核同意后，报“总署”审批（60日内作出是否批准的决定）→“总署”审批通过后，主办单位在收到批准决定60日内，到“省局”登记（领取出版许可证）→再根据本单位性质办理相应的登记手续： 事业单位要办理机构编制审批手续，并到事业单位管理机关登记（领取事业单位法人证书）；企业到工商部门登记（领取营业执照）； 互联网出版单位到省电信管理机构办理相关手续。 变更的手续： 出版单位变更名称、主办单位或者其主管机关、业务范围、资本结构，合并或者分立，设立分支机构，出版新的报纸、期刊，或者报纸、期刊变更名称，均应依照新设立出版单位的规定办理审批手续。 除上述变更之外的其他变更，应当经主办单位及其主管机关审查同意，向“省局”申请变更登记，并报“总署”备案（其他需根据本单位性质办理的登记手续同上）。 注销的手续： 出版单位中止出版活动的，应该当向所在地“省局”备案并说明理由和期限（中止活动不得
国际书刊号代理申请协议书完整版
编号：TQC/K347 国际书刊号代理申请协议 书完整版 In the case of disputes between the two parties, the legitimate rights and interests of the partners should be protected. In the process of performing the contract, disputes should be submitted to arbitration. This paper is the main basis for restoring the cooperation scene. 【适用合作签约/约束责任/违约追究/维护权益等场景】 甲方：________________________ 乙方：________________________ 签订时间：________________________ 签订地点：________________________
国际书刊号代理申请协议书完整版 下载说明：本协议资料适合用于需解决双方争议的场景下，维护合作方各自的合法权益，并在履行合同的过程中，双方当事人一旦发生争议，将争议提交仲裁或者诉讼，本文书即成为复原合作场景的主要依据。可直接应用日常文档制作，也可以根据实际需要对其进行修改。 甲方：_____ 乙方：_____ 1.甲乙双方经友好协商，乙方现就为甲 方申请国际刊号提供的服务签订以下协 议： 2.甲方同意委托乙方于_____年_____月 _____日为甲方代申请国际刊号。 3.申请国际刊号费用为：_____，申办 前甲方付清全部费用：_____。 4.甲方必须提供的以下资料，供乙方做 申请之用： （1）在香港出版的印刷品样稿三本
大数据分析平台的需求报告模板
大数据分析平台的需求报告 提供统一的数据导入工具，数据可视化工具、数据校验工具、数据导出工具和公共的数据查询接口服务管理工具是建立大数据分析平台的方向。 一、项目范围的界定 没有明确项目边界的项目是一个不可控的项目。基于大数据分析平台的需求，需要考虑的问题主要包括下面几个方面： （1）业务边界：有哪些业务系统的数据需要接入到大数据分析平台。 （2）数据边界：有哪些业务数据需要接入大数据分析平台，具体的包括哪些表，表结构如何，表间关系如何（区别于传统模式）。 （3）功能边界：提供哪些功能，不提供哪些功能，必须明确界定，该部分详见需求分析； 二、关键业务流程分析 业务流程主要考虑包括系统间数据交互的流程、传输模式和针对大数据平台本身涉及相关数据处理的流程两大部分。系统间的数据交互流程和模式，决定了大数据平台的架构和设计，因此必须进行专项分析。大数据平台本身需要考虑的问题包括以下几个方面： 2.1 历史数据导入流程 2.2 增量数据导入流程 2.3 数据完整性校验流程
2.4 数据批量导出流程 2.5 数据批量查询流程 三、功能性需求分析 3.1.历史数据导入3.1.1 XX系统数据3.1.1.1 数据清单 (3) 3.1.1.2 关联规则 (3) 3.1.1.3 界面 (3) 3.1.1.4 输入输出 (3) 3.1.1.5 处理逻辑 (3) 3.1.1.6 异常处理 (3) 3.2 增量数据导入3.3 数据校验 3.4 数据导出 3.5 数据查询 四、非功能性需求 4.1 性能
4.2 安全性 4.3 可用性 … 五、接口需求 5.1 数据查询接口 5.2 批量任务管理接口 5.3 数据导出接口 六、集群需求 大数据平台的技术特点，决定项目的实施必须考虑单独的开发环境和生产环境，否则在后续的项目实施过程中，必将面临测试不充分和性能无法测试的窘境，因此前期需求分析阶段，必须根据数据规模和性能需求，构建单独的开发环境和生产环境。 6.1开发环境 6.1.1 查询服务器 6.1.2 命名服务器 6.1.3 数据服务器 6.2 生产环境 6.2.1 查询服务器
归档文件整理培训课程
归档文件整理讲义 一、收集工作 （一）收集（归档）范围 凡本单位在职能活动中形成的、办理完毕、应作为文书档案保存的各种纸质文件材料，均属归档范围。它包括三个方面：一是本单位制发的正式文件（包括代上级机关起草的文件）；二是外单位的来文；三是本单位形成的没有文号的文件。 （二）收集要求与方法 １、要求：指对文件材料的要求。 （）要齐全完整。本单位的发文要签发手续齐全，正文与底稿(或发文稿纸)齐全；会议记录要有时间、地点，参加对象、记录人、会议主要内容。 （）用纸要规范。特别是记录本，不能用小于的普通练习本，应选择或用纸。过小的要进行粘贴。 （）要求使用耐久的字迹材料，如黑墨水、红印泥、激光打印；不能用圆珠笔、复写纸、传真纸、色带打印等不耐久的字迹材料。 ２、收集方法 定期收集与平时收集相结合，要主动收集，还要把好发文关和用印关，不但要收集纸质的文件材料，还要同时收集电子文本，要有规范的文书处理程序。 二、整理
归档文件的整理是将应该归档的文件以件为单位进行装订、分类、排列、编号、编目、装盒，使之有序化的过程。首先要做到四个分开。 （一）归档与不归档的文件材料分开 收集来的文件并不是每一份都要归档的，我们要纠正两种错误认识，一是有文必档，二是红头文件（上级来文）都要归档。一般有以下几种文件可以不归档。 、上级机关的文件材料中，普发性不需本机关办理的文件材料，任免、奖惩非本机关工作人员的文件材料，供工作参考的抄件等； 、本机关文件材料中的重份文件，无查考利用价值的事务性、临时性文件，一般性文件的历次修改稿、各次校对稿，无特殊保存价值的信封，不需办理的一般性人民来信、电话记录，机关内部互相抄送的文件材料，本机关负责人兼任外单位职务形成的与本机关无关的文件材料，有关工作参考的文件材料； 、同级机关的文件材料中，不需贯彻执行的文件材料，不需办理的抄送文件材料； 、下级机关的文件材料中，供参阅的简报、情况反映，抄报或越级抄报的文件材料。 （二）年度分开 文书档案是按年度进行整理的，如果你这个单位几年未整理了，那么首先要将各年度的材料分开，同一个年度的文
数据库需求分析报告
高校学生学籍管理 §１概述 编写说明: 本章描述本软件开发得背景，系统目标，用户得业务情况,以便于需求理解。 §1·１背景 在学籍管理中,需要从大量得日常教学活动中提取相关信息，以反映教学情况．传统得手工操作方式，易发生数据丢失,统计错误,劳动强度高，且速度慢.使用计算机可以高速,快捷地完成以上工作。在计算机联网后，数据在网上传递,可以实现数据共享，避免重复劳动，规范教学管理行为,从而提高了管理效率与水平. §1·２系统目标 学籍管理信息系统以计算机为工具,通过对教务管理所需得信息管理,把管理人员从繁琐得数据计算处理中解脱出来,使其有更多得精力从事教务管理政策得研究实施,教学计划得制定执行与教学质量得监督检查，从而全面提高教学质量。 §１·3 业务模式 本系统就是运行在Ｗin9８、Win2０00、WiｎdｏwsNＴ等操作系统环境下得多台计算机构成得局域网，主要业务流程如下: ·按某学生某学期，学年考试及补考成绩，自动生成该学生就是否升留降级，退学。 ·按某学生在校期间累计补考科目门数与成绩自动生成该学生就是否结业，毕业,授位。 ·按某学生因非成绩原因所引起得学籍变更作自动处理． ·按每学期各年级班学生考试成绩自动生成补考名单,科目。 ·按每学期各年级学生考试成绩自动生成某课程统计分析表。 ·按同一年级学习成绩进行同一课程不同班级间成绩比较。 §2用户需求 编写说明: 此系统专门为高校学籍管理所设置。本节主要描述用户需求得使用范围,功能要求信息采集与各部门得使用权限 §2·１使用范围 按成都信息工程学院全日制学生学籍管理等相关文件完成本科与专科学生学籍状况得系统管理(本科生用学年学分制,专科生用学年制）。 系统中保留五个年级学生得信息，学生毕业一年后信息转储，但随时可以查询，输出. §2·２功能要求 ·学生档案管理: 学生得一般情况,及奖励，处分情况; ·学生成绩管理: 学习成绩,补考成绩; ·学籍处理: 学生留降级处理，休复学处理,退学处理; ·日常教务管理: 日常报表，如通知书,补考通知书等，学生学习成绩得各种分类统计; ·毕业生学籍处理：结业处理,毕业处理，授位处理,学籍卡片等。 §2·3信息采集与各部门得使用权限 每学期考试完毕由各系录入成绩，然后由教务科收集。为了信息得安全与数据得权威性,对于网上信息得使用权限与责任规定如下： 数据收集前得系统权限
如何查询刊物或刊号
如何查询刊物或刊号 关于合法期刊与非法期刊 合法期刊分为正式期刊和非正式期刊，正式科技期刊是由国家新闻出版署与国家科委在商定的数额内审批，并编入“国内统一刊号”，办刊申请比较严格，要有一定的办刊实力，主编与副主编必须由高级专业技术职务的人员担任，对编辑人员的素质名额都有一定的要求，正式期刊有独立的办刊方针。非正式期刊是指通行政部门审核领取“内部报刊准印证”作为行列内部交流的期刊（一般只限行业内交流不公开发行），也叫做“内刊”，它也是合法期刊的一种，一般正式期刊都经历过非正式期刊过程。 非法期刊系没有通国家新闻出版署和国家科委批准也没有注册为“内部刊物”的非法出版物，以营利为首要目的，收取高额的版面费，在技术上和政治上不负责任，不能在国内公开发行或内部发行，它们通常是在国外花300元购买一个ISSN刊号来欺骗教师。 其实国内刊号是非常紧张的，目前一个省和部委每年最多3个号，中央直属单位1个号，教育学术部门5个号。中国刊号申请归口有四个单位，国家新闻出版署、国家科委，国家侨办，解放军总政治部。一般期刊通过省市新闻出版局报国家新闻出版署，科技类通过省市新闻出版局和省科委报国家科委再到新闻出版署。侨刊报国家侨办再到新闻出版署。
刊物或刊号，自己根据刊物名到下列网站查询： 国家新闻出版总署（https://www.wendangku.net/doc/1e14191773.html,）右侧新闻机构查询中国期刊网 （https://www.wendangku.net/doc/1e14191773.html,/bjb/abjbzydy.htm）论发表文小知识 ■ cn：国内统一发行刊号■ issn：国际发行刊号 ■ isbn：图书刊号■ hk/NR：香港刊号 ■ 正刊：编辑部正规发行的杂志，与市场同步■ 增刊：在发行正刊之余发行的刊物 ■ 论文集：由某些出版社出版的论文集合，图书■ 版面费：给编辑部的钱，论文所占的版面需要交钱 ■ 写作费：指按要求写好论文应得的稿酬■ 发表费：指将指定论文发表后的手续费 第一招：认准刊物 不完全相信对方提供的刊物或刊号，自己根据刊物名到
数据库需求分析
第一章系统概要介绍 1.1 系统概述 《数据库原理及应用》课程的学习，其主要的目标是能利用课程中学习到的数据库知识与技术较好地开发设计出数据库应用系统，去解决各行各业信息化处理的要求。本实验主要在于巩固学生对数据库的基本原理和基础理论的理解，掌握数据库应用系统的设计开发的基本方法，进一步提高学生的综合运用所学的知识能力。 为了使数据库的应用系统开发设计合理、规范、有序、正确、高效进行，现在广泛采用的是工程化6阶段开发设计过程与方法，它们是需求分析阶段、概念结构设计阶段、逻辑结构设计阶段、物理结构设计阶段、数据库实施、数据库系统运行与维护阶段。我们按照以上几点开发了机房上机管理系统数据库。 1.2 系统研发背景 随着我国高等教育的快速发展及大学招生规模的不断扩大以至于校园数字化的发展和我国高校机房的数量与规模在不断扩大,。各个高校都建设了自己的校园网络，越来越多的学生到校机房上网。这对校园机房进行联合计费管理和机房的配置管理等也提出了更高的要求。为了更好的发挥学校公共机房的职能,解决机房管理过程中的一些实际问题就要开发出一套满足高校需求的机房管理系统是非常必要的。 机房作为一种信息资源的集散地，有很多的信息数据需要管理，由于数据信息处理工作量大、数据繁多，因此原有的手工管理方式就存在容易出错、数据易丢失，且不易查找和低效率等弊病。总的来说，就是缺乏系统，规范的信息管理手段。基于这此问题，我认为有必要建立一个机房管理系统，使机房管理工作规范化，系统化，程序化，避免机房管理的随意性，提高信息处理的速度和准确性，能够及时、准确、有效的查询和统计相关情况。 1.3 系统研发的目的和意义 我们根据所学的数据库原理与程序设计的知识，能够针对一个小型的数据库管理系统，进行系统的需求分析，系统设计，数据库设计，编码，测试等，完成 第6/26页题目要求的功能，从而达到掌握开发一个小型数据库的目的。我校的计算机设备和学生上网上机管理还处于较为原始的手工阶段。缺少一套实用可靠的设备和课程管理系统软件。随着电气化教学和无纸化办公的一步步完善，利用机房管理系统管理我校的机房势在必行 第7/26页第二章需求分析 2.1 需求描述 针对一般高校机房管理系统的需求分析、通过对学生上机过程、注册过程、充值过程、的内容的数据流程分析一现设计如下数据项和数据结构
出版专业职业资格考试资料整理
2011出版资格考试：理论与实务全真模拟题二及答案 一、单项选择题 1.某出版社创办不久，为在市场上较快地站稳脚跟，宜采用( )策略进入目标市场。 A.强化定位 B.首席定位 C.避强定位 D.分散定位 2.图书商品竞争中不包括( )。 A.品种竞争 B.宣传竞争 C.价格竞争 D.消费水平竞争 3.期刊的审稿时限，即编辑部收到稿件后应作出答复的时间，我国著作权法规定为稿件寄 出后( )天。 A.15 B.30 C.60 D.90 4.学术期刊著录参考文献的方法和形式，有顺序编码制和( )两种。 A.音序编排制 B.著者一出版年制 C.文献类型编码制 D.著者姓氏顺序制 5.全国音像制品的出版、制作和复制的监督管理工作由( )负责。 A.文化部 B.国家版权局 C.新闻出版总署 D.国家广播电影电视总局 6.与图书编辑相比，音像编辑在进行选题定位时，还要注意考虑( )等问题。 A.预期的社会效益和经济效益 B.成本预算 C.现有的技术手段能否实现 D.读者对象和预计的发行量 7.关于国家对电子出版物复制单位的要求，下列说法中错误的是( )。 A.不得接受非电子出版物出版单位和个人委托复制电子出版物 B.不得擅自复制电子出版物和计算机软件 C.不得擅自复制电子媒体非卖品 D.不得保留所复制电子出版物的样本 8.原创性非连续型电子出版物指( )的电子出版物。 A.利用现有纸质出版物转化后制作出版 B.接受制作单位汇编的作品并经审定后出版 C.通过著作权贸易引进海外作品并作加工后出版 D.出版单位自行策划选题、组织开发并作编辑加工后制作出版 9.根据《图书质量保障体系》的规定，出版社的( )对本版图书的广告质量负全部责任。 A.发行部或广告部经理 B.社长 C.编辑部或编辑室主任 D.责任编辑 10.电子出版物复制单位复制光盘类电子出版物，必须依照有关规定在光盘内圈表面压制 ( )。 A.音像制品编码 B.来源识别码 C.条形码 D.出版者代码 11.从事出版物总发行业务不必具备的条件是( )。 A.属于国有或国有资本控股的出版物发行企业 B.有与出版物总发行业务相适应的发行专业人员 C.注册资金不少于2000 万元 D.具备相应的计算机管理条件和健全的管理制度 12.十届全国人大四次会议于2006 年3月14 日通过了( )。 A.《中华人民共和国国民经济和社会发展第十个五年规划纲要》 B.《中华人民共和国国民经济和社会发展第十一个五年规划纲要》 C.《建设社会主义和谐社会纲要》 D.《建设社会主义新农村规划纲要》 13.2006年3 月28 日全国文化体制改革工作会议在北京召开，对推进文化体制改革作出具 体部署。会议指出，要以( )为重点，着力培育新型文化市场主体。 A.激发活力，改善服务 B.培育现代文化市场体系 C.创新文化管理体制 D.推进经营陛文化单位转企改制 14.下列关于辞书出版业务的表述中，错误的是( )。 A.少数民族语言与汉语对照的语文辞书由各民族
校对文稿的基本方法
百科名片 校对(Text-proofing)，古代称之为“校堪”或“校雠”，是出版编辑过程里的一个必须工序，主要工作是按照原稿去审查订正排印或缮写的错误。“校对”也可以是从事这个工序的人员“校对员”(Proofreader)的中文简称。 目录 展开 编辑本段文人笔下的校对
校对是保证学报质量的重要环节 是对编辑工作的继续和补充。校对 校对人员 必须高度负责，认真细致，树立严谨周密，一丝不苟的作风。 1．根据原稿，核对并清除校样上的差错。 2．改正在政治思想上和科学性上遗留的不准确的提法和词句。 3．清除语法修辞上遗留的差错和毛病。 4．清除错别字。 5．解决和消除任何疑点。 把握校对标准 1．编辑负责校对、印刷工作的组织和实施，及时送取稿件和校样，做好与印刷厂的业务联系。 2．校对以原稿为准，不得在校样上随意增补、删减，发现原稿错误及编辑处理的疏漏和失误做出标示，由编辑对原稿、校样予以处理。若作者提出修改时，要尽量坚持不动版面、不动字数的原则，减少改版的麻烦。 3．准确使用校对符号，消灭错字，补齐遗漏，纠正版式错误，严格执行三校
校对人员 加点校制度，保证期刊质量。 4．校对以对校、折校为主，根据实际情况，部分稿件由作者校对一次，校后由编辑对格式、质量复校一次。 5．校对时要注意版面的规范、美观，排版的合理。校对差错率要保持在万分之二以下。 遵循校对的程序 交叉三校制 1．一校（作者、责任编辑各校一次）：侧重对原稿校对，力求校样与原稿的一致，纠正版式错误，对有疑问处做出标示。校后通读一遍。要求作者不能对原稿作大的改动。 2．二校（责任编辑、执行编辑各校一次）：校对时要确定一校校出错误已改正，纠正版式错误，并对文稿中的疑问予以处理，填补遗缺，统一体例。 3．三校（执行编辑校一次）：校对时要确定二校校出错误已改正，对校样 校对符号 进行综合检查，清理差错，确定版面格式。 4．点校：对三校校出错误予以核对，并对文章、版式作最后通校，确保清样无差错。 5．校对签名。校对者应在每次校样上签名，并标明校次，以防差错。 6．责任编辑甩开原稿和三校样，对清样进行阅读，寻找差错。在读样后，进行总体扫描，检查有无错字、漏字、表格与插图是否合乎规范，字体、字号使用是否正确等。 明确校对内容 1．检查多、漏、错文字及标点、符号错误；核对标题、署名，文中人名、地名、数字、公式。
出版管理规定全文
出版管理规定全文 ----WORD文档，下载后可编辑修改---- 下面是小编收集整理的范本，欢迎您借鉴参考阅读和下载，侵删。您的努力学习是为了更美好的未来！ 出版管理规定全文如下第一章总则 第一条为了加强对出版活动的管理，发展和繁荣有中国特色社会主义出版产业和出版事业，保障公民依法行使出版自由的权利，促进社会主义精神文明和物质文明建设，根据宪法，制定本条例。 第二条在中华人民共和国境内从事出版活动，适用本条例。 本条例所称出版活动，包括出版物的出版、印刷或者复制、进口、发行。 本条例所称出版物，是指报纸、期刊、图书、音像制品、电子出版物等。 第三条出版活动必须坚持为人民服务、为社会主义服务的方向，坚持以马克思列宁主义、毛泽东思想、邓小平理论和“三个代表”重要思想为指导，贯彻落实科学发展观，传播和积累有益于提高民族素质、有益于经济发展和社会进步的科学技术和文化知识，弘扬民族优秀文化，促进国际文化交流，丰富和提高人民的精神生活。 第四条从事出版活动，应当将社会效益放在首位，实现社会效益与经济效益相结合。 第五条公民依法行使出版自由的权利，各级人民政府应当予以保障。
公民在行使出版自由的权利的时候，必须遵守宪法和法律，不得反对宪法确定的基本原则，不得损害国家的、社会的、集体的利益和其他公民的合法的自由和权利。 第六条国务院出版行政主管部门负责全国的出版活动的监督管理工作。国务院其他有关部门按照国务院规定的职责分工，负责有关的出版活动的监督管理工作。 县级以上地方各级人民政府负责出版管理的部门(以下简称出版行政主管部门)负责本行政区域内出版活动的监督管理工作。县级以上地方各级人民政府其他有关部门在各自的职责范围内，负责有关的出版活动的监督管理工作。 第七条出版行政主管部门根据已经取得的违法嫌疑证据或者举报，对涉嫌违法从事出版物出版、印刷或者复制、进口、发行等活动的行为进行查处时，可以检查与涉嫌违法活动有关的物品和经营场所;对有证据证明是与违法活动有关的物品，可以查封或者扣押。 第八条出版行业的社会团体按照其章程，在出版行政主管部门的指导下，实行自律管理。 第二章出版单位的设立与管理 第九条报纸、期刊、图书、音像制品和电子出版物等应当由出版单位出版。 本条例所称出版单位，包括报社、期刊社、图书出版社、音像出版社和电子出版物出版社等。 法人出版报纸、期刊，不设立报社、期刊社的，其设立的报纸编
数据需求分析
4.1 引言 4.1.1 编写目的 为了更好地完成商店管理系统项目，为项目的进一步开发工作做准备，客户访谈，问题分析与确认，了解具体数据，有利于软件的实现， 商店客户：根据购物客户大概总结客户的需求； 商家：开商店的具体要求，资金，管理，进销存等； 商店管理员：进行问题分析与确认； 系统分析员：总结系统所需实现功能 4.1.2 背景 各种商店遍布大街小巷，给人们的生活带来了很大的方便。做好商店内部的人员，商品和销售的管理工作，对商店的成功经营十分重要。然而传统的商店管理，主要以人工为主，不但费时费力，风险也不小。21世纪，商店销售的竞争也进入到了一个全新的领域，竞争已不再是规模的竞争，而是技术的竞争、管理的竞争、人才的竞争。技术的提升和管理的升级是销售业的竞争核心。该商店管理系统将用于各种商店的商品进出货，消费者信息和职工信息的管理，实现以计算机辅助形式代替传统的手工查询记录形式，减轻商店管理人员的劳动强度，提高工作质量和效率，从而使商店管理更加合理化和科学化。 4.1.3 术语定义 商品条形码：每种商品具有唯一的条形码，对于某些价格一样的商品，可以使用自定义条形码。 交易清单：包括交易的流水账号、每类商品的商品名、数量、该类商品的总金额、交易的时间、负责本次收银的员工号。 商品积压：在一定时期内，远无法完成销售计划的商品会造成积压。 促销：在一定时期内，某些商品会按低于原价的促销价格销售。库存告警提示：当商品的库存数量低于库存报警数量时发出提示。 盘点：计算出库存、销售额、盈利等经营指标。 4.1.4 参考资料 《商场管理系统可行性分析报告》 《SQL server2005案例分析设计》
数据分析需求PRD
数据分析后台需求文档 交流QQ：415149534 编号文档版本修订章节修订原因修订日期修订人 请与以下部门讨论PRD 序号OK？部门沟通内容 1.□运营部： 运营主管、 运营专员、 客服?完善产品的需求 ?改善产品操作体验 ?评估产品的实用性 ?预测客服成本、工作量 ?协助评估诈欺/数据窜改风险：欺诈/数据窜改风险、 不当使用风险 2.□技术部：?进行技术可行性分析，提出关键问题的技术解决方案 ?评估系统规模，数据量，所需资源等 ?协助确定产品发布日期 ?协助确定产品成本 ?协助评估风险
目录 1. 概述 (3) 1.1. 名词说明 (3) 1.2. 产品概述 (3) 1.3. 产品目的 (3) 1.4. 产品目标 (3) 2. 使用者需求 (4) 2.1 需求描述 (4) 3. 功能管理模块 (5) 3.1. 功能总览 (5) 3.2. 功能总表 (5) 4. 功能需求 (8) 4.1. 功能流程 (8) 4.1.1. 游戏后台-系统道具管理流程 (8) 4.2. 功能详情 (10) 4.2.1. 游戏后台－GM管理－系统道具管理 (10) 4.2.2. 玩家武将管理 (12) 4.2.3. 运营工具 (15) 4.2.4. 流失率用户统计及分析 (19) 4.2.5. 活动收益分析 (24)
1. 概述 1.1. 名词说明 其它详见数据分析名词说明文档.doc 1.2. 产品概述 现已有游戏后台，主要运营于游戏客服对玩家的维护与部分游戏数据的查询，但功能不完善，有所欠缺，且缺少对平台数据、游戏数据的查询、统计、分析，系统管理，权限分配等功能，无法深度进行挖掘，对游戏运营产生应有的作用。 现产品增加此块功能内容，聚合游戏客服、游戏运营专员、运营主管等使用者的需求，有效的结合在一起。 能够让游戏客服更好的维护玩家的游戏利益，给出数据依据，更好的服务玩家，另一方面给运营专员在游戏运营时做出数据依据，做到有据可查，充分掌控对游戏进程，从数据中了解玩家潜在需求，给出对应的游戏活动、道具促销等运营手段，为游戏赚取更多利益。 1.3. 产品目的 针对平台多游戏特征，实行戏客服对玩家统一化管理，降低维护成本，并实现同平台用户数据可多次利用（精准数据营销）； 准确的网络推广，降低转化成本，提高转化率； 智能化、自定义挖掘潜在付费玩家，让游戏客服高效率维护付费玩家； 挖掘潜在付费需求，为运营活动、游戏更新提供数据支持； 可一目了然了解游戏运营收支状况； 1.4. 产品目标 产品roadmap 产品发展阶段阶段描述时间 数据分析后台1期———系统管理和游戏后台1、能够基本满足游戏客服人员对维护玩家及查询相关内 容的、发放奖励等基本操作需求； 2011．3~4 数据分析后台2期———网站数据1、可以统计网站流量、网站用户信息、记录并查询登录 失败、广告商所带来的流量并估算成本等； 2、能够管理后台管理员，分配相应等级权限，查看系统 日志等操作； 2011．7~8 数据分析后台3期———游戏数据和数据分析1、能够基本满足运营人员查询游戏务项统计数据； 2、对各项数据进行有效组合并分析，显示有效内容，促 进游戏良性运营； 2012．2~3
软件需求文档格式的标准写法
软件需求文档格式的标准写法 1．引言 1．1 编写目的 ·阐明开发本软件的目的； 1．2 项目背景 ·标识待开发软件产品的名称、代码； ·列出本项目的任务提出者、项目负责人、系统分析员、系统设计员、程序设计员、程序员、资料员以及与本项目开展工作直接有关的人员和用户； ·说明该软件产品与其他有关软件产品的相互关系。 1．3 术语说明 列出本文档中所用到的专门术语的定义和英文缩写词的原文。 1．4 参考资料（可有可无） 列举编写软件需求规格说明时所参考的资料，包括项目经核准的计划任务书、合 同、引用的标准和规范、项目开发计划、需求规格说明、使用实例文档，以及相关产品
的软件需求规格说明。 在这里应该给出详细的信息，包括标题、作者、版本号、发表日期、出版单位或资 料来源。 2．项目概述 2．1 待开发软件的一般描述 描述待开发软件的背景，所应达到的目标，以及市场前景等。 2．2 待开发软件的功能 简述待开发软件所具有的主要功能。为了帮助每个读者易于理解，可以使用列表或 图形的方法进行描述。使用图形表示，可以采用： ·顶层数据流图； ·用例UseCase图； ·系统流程图； ·层次方框图。
2．3 用户特征和水平（是哪类人使用） 描述最终用户应具有的受教育水平、工作经验及技术专长。 2．4 运行环境 描述软件的运行环境，包括硬件平台、硬件要求、操作系统和版本，以及其他的软 件或与其共存的应用程序等。 2．5 条件与限制 给出影响开发人员在设计软件时的约束条款，例如： ·必须使用或避免使用的特定技术、工具、编程语言和数据库； ·硬件限制； ·所要求的开发规范或标准。 3．功能需求 3．1 功能划分
发表论文需了解的基本刊号知识
发表论文需了解的基本刊号知识 一、国内统一刊号CN标准格式 1、它以CN前缀,由6位数字和分类号组成,其结构格式 2、为CNXX-XXXX/YY,CN后面2位数字为地区号,缀后 3、4位数字为序号,亦即报刊登记号=地区号+序号,斜线后字母为图书分类号, A马克思主义、列宁主义、毛泽东思想、邓小平理论 B哲学、宗教 C 社会科学类 D 政治、法律 F 经济 G 文化、科学、教育、体育 H 语言、文字 I 文学 J 艺术 K 历史、地理 N 自然科学总论 O 数理科学和化学 Q 生物科学 R 医药、卫生 S 农业科学 T-TN 工业技术 TP 自动化技术、计算机技术 Q 化学工业 TU 建筑科学 TV 水利工程 U 交通运输 V 航空、航天 X 环境科学、安全科学 Z 综合性图书 二、正确辨别非法期刊的基本特征 目前出现的非法期刊一般具有以下的基本特征： 1、期刊的“名头”都很大，具有诱惑性。很多期刊基本上都是“国”字号的，例如，有的叫《中国教育××》，还有的在封面上注着“国际中文核心期刊”、“世界××期刊”、“××统计源期刊”等。刊物主办、协办、支持单位都是“中国××研究院”、“中国××研究中心”、“香港现代××研究会”、“亚太××交流中心”等。有的还邀请了一大批名人、专家做顾问、特邀编辑。 2、期刊都标有标准刊号或统一刊号，具有欺骗性。一般非法期刊，绝大多数都是既有国际标准期刊刊号即ISSN号，也有国内统一刊号即CN号。但仔细研究就会发现，有些刊号根本就不符合正规刊号的结构式，有些国内统一刊号CN后面，大多都缀有NR或者HK即香港刊号的标识。
3、期刊基本上都是自办发行，具有隐蔽性。自办发行即不通过邮局，没有邮发代号。没有邮发代号的期刊从邮局或国家报刊发行网上是查不到他们任何信息的。也有少数非法期刊会编上一个邮发代号，但这些邮发代号要么根本不存在，要么是盗用其它期刊的邮发代号。 4、大多数非法期刊，社址、编辑部地址或注册地址都在香港、深圳、北京、广州等大城市，通信地址一般只注明“××信箱”、“××大厦××室”或“××楼××座”，也常常在异地设办事机构。所以，社址、编辑部地址、注册地址与办公地址分离，是这类非法期刊的另一个重要特点。 5、从网上查询，常常发现这类非法期刊同名现象很多，同一名称的期刊甚至还有多个不同的刊号。例如同是《×国教育》就有3家，同是《中国教育××研究杂志》就有北京、广州2家，又如《中国××教育研究》1个期刊，就有4个不同的刊号。 6、非法期刊都以盈利为目的，所有要发表的文章，都要交纳为数不菲的版面费。可以说，“拿钱发文章”是这类期刊最重要的特点。一般来说，这类期刊基本上是“来稿就登”，没有严格的审稿程序，版面费的多少视文章的长短而定，多则上千元，少则几百元。 7、非法期刊的内容繁杂，版面混乱。不少非法期刊在内容的编排上没有规律，不设置分类栏目，文章杂乱无序，不符合正式期刊在内容编排方面规范化、标准化的格式要求。 三、如何识别国内正式刊物 1、合法期刊与非法期刊 期刊分为正式期刊和非正式期刊，正式科技期刊是由国家新闻出版署与国家科委在商定的数额内审批，并编入“国内统一刊号”，办刊申请比较严格，要有一定的办刊实力，主编与副主编必须由高级专业技术职务的人员担任，对编辑人员的素滞名额都有定的要求，正式期刊有独立的办刊方针。非正式期刊是指通行政部门审核领取“内部报刊准印证”作为行列内部交流的期刊（一般只限行业内交流不公开发行），但也是合法期刊的一种，一般正式期刊都经历过非正式期刊过程。非法期刊系没有通国家新闻出版署和国家科委批准也没有注册为”内部刊物”的非法出版物，以营利为首要目的，收取高额的版面费，在技术上和政治上不负责任，不能在国内公开发行或内部发行，它们通常是在国外花300元购买一个ISSN刊号来欺骗教师。 2、期刊刊号问题 凡通过新闻出版署和国家科委审批的正式期刊均编入了“国内统一刊号”，正式期刊的刊号是由国际标准刊号（ISSN）和国内统一刊号（CN）两部分组成，“CN”是中国国别代码，缺少“国内统一刊号”或“内部报刊准印证”都可认为是中国国内的非法期刊，国家不认可，也不准在中国国内发行的。 3、识别公开发行的正式期刊方法 国内公开发的期刊允许在国内外发行，有国内统一刊号，其刊号结构式为：CN报刊登记号/分类号，只有ISSN国际刊号而无国内统一刊号不允许在国内公开发行，有的虽印有CN （HK）或CNXXX（HK）/R这不是合法的国内统一刊号需注意，正式期刊一般有国内主管单位，并有详细的通信地址和印刷出版地都在国内，除自办发行外大多通过邮局征订和发行，故常常有邮发代码。而非法出版物一般没有国内统一刊号，即使“内部报刊准印证”也没有，没有国内明确的主管单位，通信地址不祥，常常以XXX信箱收稿，印刷出版地都在大陆以外。以便逃避查处，当然不可能有邮发代码了。 综上所述，除在国外正式公开发行的有国别识别码和公众认可有一定影响力的外国期刊杂志发表论文外，论文应选择在国内合法期刊上发表，而非法期刊基本上是“来稿就登”根本没有严格的审稿程序和审稿专家更谈不上学术水平，这类交了版面费就“照登”，发表速度十分惊人的“期刊”对职称评定应该说意义不大，至于如何抵制这些“来稿就登”的“期
CN刊号和ISSN刊号代表的意思及意义
CN刊号和ISSN刊号代表的意思及意义 中国标准刊号(CSSN)由一个以“ISSN”为标识的国际标准刊号(Internationnal standard serial numbering-ISSN)和一个以中国国别代码“CN”为标识的国内统一刊号两部分组成，其一般格式如下： ISSN××××-×××× CN××-××××/YY 例如：ISSN1000-0097 CN-11-1340/G4 国际标准刊号(ISSN) 国际标准刊号等效采用国际标准ISO3297《文献工作—国际标准连续出版物号(ISSN)》。 按国际标准ISO3297规定，一个国际标准刊号由以“ISSN”为前缀的8位数字(两段4位数字，中间以一连字符“-”相接)组成。如：ISSN1234-5679，其中前7位为单纯的数字序号，无任何特殊含义，最后一位为计算机校验位，其数值根据前7位数字依次以8～2加权之和、以11为模数按附录B所示的方法计算得到。在前缀ISSN与数字之间应空一个字距。 国内统一刊号 国内统一刊号以GB2659所规定的中国国别代码“CN”为识别标志，由报刊登记号和分类号两部分组成，前者为国内统一刊号的主体，后者为补充成分，其间以斜线“/”隔开，结构形式为：CN报刊登记号/分类号 报刊登记号 一个报刊登记号为定长的6位数字，由地区号(2位数字)和序号(4位数字)两部分组成，其间以连字符“-”相接，亦即：报刊登记号＝地区号＋序号。 地区号按GB2260所规定的省、自治区、直辖市地区代号给出。 序号由报刊登记所在的省、自治区、直辖市新闻出版管理部门分配，各地区的刊号范围一律从0001～9999，其中0001～0999统一作为报纸的序号，1000～4999统一作为期刊的序号，5000～9999暂不使用。 分类号 分类号作为国内统一刊号的补充成分用以说明报刊的主要学科范畴，以便于分类统计、订阅、陈列和检索。一种报刊只能给定一个分类号。 期刊按《中国图书馆图书分类法》的基本大类给出，其中文化教育(G类)、自然科学(O 类)和工业技术(T类)的期刊按该分类法的二级类目给出。