Internet Engineering Task Force (IETF) A. Niemi Request for Comments: 5839 Nokia Category: Standards Track D. Willis, Ed. ISSN: 2070-1721 Softarmor Systems May 2010 An Extension to Session Initiation Protocol (SIP) Events
for Conditional Event Notification
Abstract
The Session Initiation Protocol (SIP) events framework enables
receiving asynchronous notification of various events from other SIP user agents. This framework defines the procedures for creating,
refreshing, and terminating subscriptions, as well as fetching and
periodic polling of resource state. These procedures provide no
tools to avoid replaying event notifications that have already been
received by a user agent. This memo defines an extension to SIP
events that allows the subscriber to condition the subscription
request to whether the state has changed since the previous
notification was received. When such a condition is true, either the body of a resulting event notification or the entire notification
message is suppressed.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.doczj.com/doc/2a9755577.html,/info/rfc5839.
Niemi & Willis Standards Track [Page 1]
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust’s Legal
Provisions Relating to IETF Documents
(https://www.doczj.com/doc/2a9755577.html,/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other than English.
Niemi & Willis Standards Track [Page 2]
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Document Conventions . . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Motivations and Background . . . . . . . . . . . . . . . . . . 5 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Problem Description . . . . . . . . . . . . . . . . . . . 5
2.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7
4. Resource Model for Entity-Tags . . . . . . . . . . . . . . . . 10
5. Subscriber Behavior . . . . . . . . . . . . . . . . . . . . . 12 5.1. Detecting Support for Conditional Notification . . . . . . 13 5.2. Generating SUBSCRIBE Requests . . . . . . . . . . . . . . 13 5.3. Receiving NOTIFY Requests . . . . . . . . . . . . . . . . 14 5.4. Polling or Fetching Resource State . . . . . . . . . . . . 15 5.5. Resuming a Subscription . . . . . . . . . . . . . . . . . 17 5.
6. Refreshing a Subscription . . . . . . . . . . . . . . . . 18 5.
7. Terminating a Subscription . . . . . . . . . . . . . . . . 18
5.8. Handling Transient Errors . . . . . . . . . . . . . . . . 19
6. Notifier Behavior . . . . . . . . . . . . . . . . . . . . . . 20 6.1. Generating Entity-tags . . . . . . . . . . . . . . . . . . 20 6.2. Suppressing NOTIFY Bodies . . . . . . . . . . . . . . . . 20 6.3. Suppressing NOTIFY Requests . . . . . . . . . . . . . . . 21 6.4. State Differentials . . . . . . . . . . . . . . . . . . . 21
6.5. List Subscriptions . . . . . . . . . . . . . . . . . . . . 22
7. Protocol Element Definitions . . . . . . . . . . . . . . . . . 22 7.1. 204 (No Notification) Response Code . . . . . . . . . . . 22 7.2. Suppress-If-Match Header Field . . . . . . . . . . . . . . 22
7.3. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 8.1. 204 (No Notification) Response Code . . . . . . . . . . . 23
8.2. Suppress-If-Match Header Field . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 11.1. Normative References . . . . . . . . . . . . . . . . . . . 24 11.2. Informative References . . . . . . . . . . . . . . . . . . 24 Niemi & Willis Standards Track [Page 3]
1. Introduction
The Session Initiation Protocol (SIP) events framework provides an
extensible facility for requesting notification of certain events
from other SIP user agents. This framework includes procedures for
creating, refreshing, and terminating subscriptions, as well as the
possibility to fetch or periodically poll the event resource.
Several instantiations of this framework, called event packages have been defined, e.g., for presence [RFC3856], message waiting
indications [RFC3842], and registrations [RFC3680].
By default, every SUBSCRIBE request generates a NOTIFY request
containing the latest event state. Typically, a SUBSCRIBE request is issued by the subscriber whenever it needs a subscription to be
installed, periodically refreshed, or terminated. Once the
subscription has been installed, the majority of the NOTIFYs
generated by the subscription refreshes are superfluous; the
subscriber usually is in possession of the event state already,
except in the unlikely case where a state change exactly coincides
with the periodic subscription refresh. In most cases, the final
event state generated upon terminating the subscription similarly
contains resource state that the subscriber already has.
Fetching or polling of resource state behaves in a similarly
suboptimal way in cases where the state has not changed since the
previous poll occurred. In general, the problem lies with the
inability to persist state across a SUBSCRIBE request.
This memo defines an extension to optimize the SIP events framework. This extension allows a notifier to tag notifications (called entity- tags hereafter) and the subscriber to condition its subsequent
SUBSCRIBE requests for actual changes since a notification carrying
that entity-tag was issued. The solution is similar to conditional
requests defined in the Hypertext Transfer Protocol (HTTP) [RFC2616], and follows the mechanism already defined for the PUBLISH [RFC3903]
method for issuing conditional event publications.
This memo is structured as follows. Section 2 explains the
background, motivations, and requirements for the work; Section 3
gives a general overview of the mechanism; Section 4 explains the
underlying model for resources and entities as they apply to
conditional notification; Section 5 defines the subscriber behavior; Section 6 defines the notifier behavior; Section 7 includes the
protocol element definitions; Section 8 includes the IANA
considerations; and Section 9 includes the security considerations. Niemi & Willis Standards Track [Page 4]
1.1. Document Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119] and indicate requirement levels for compliant
implementations.
1.2. Terminology
In addition to the terminology introduced in [RFC3261], [RFC3265],
and [RFC3903], this specification uses these additional terms to
describe the objects of conditional notification:
resource
An object identified by a URI whose resource state can be accessed using the SIP Event Notification framework. There is a single
authoritative notifier responsible for communicating the resource state.
entity
The representation of resource state. An entity consists of the
state data carried in the body of a NOTIFY message, as well as
related meta-data in the message header. There may be many
versions of an entity, one current and the others stale. Each
version of an entity is identified by an entity-tag, which is
guaranteed to be unique across all versions of all entities for a resource and event package.
2. Motivations and Background
2.1. Overview
A SUBSCRIBE request creates a subscription with a finite lifetime.
This lifetime is negotiated using the Expires header field, and
unless the subscription is refreshed by the subscriber before the
expiration is met, the subscription is terminated. The frequency of these subscription refreshes depends on the event package, and
typically ranges from minutes to hours.
2.2. Problem Description
The SIP events framework does not include different protocol methods for initiating and terminating of subscriptions, subscription
refreshes, and fetches inside and outside of the SIP dialog. The
SUBSCRIBE method is overloaded to perform all of these functions.
The difference between a fetch that does not create a (lasting)
subscription and a SUBSCRIBE that creates one is in the Expires
Niemi & Willis Standards Track [Page 5]
header field value of the SUBSCRIBE; a zero-expiry SUBSCRIBE only
generates a single NOTIFY, after which the subscription immediately
terminates. Lasting subscriptions typically have relatively short
expiry periods, requiring periodic sending of new SUBSCRIBE requests in order to refresh the subscription.
Each new SUBSCRIBE request generates a NOTIFY request containing the latest resource state. Even if the state has not changed, it is sent again in response to each poll or subscription refresh. This is very similar to the HTTP [RFC2616] problem of repeated GET operations on a resource. HTTP solves the problem using conditional requests. The
server versions each entity with an entity-tag that identifies a
specific instance of that entity. Clients making GET requests can
then include the entity-tag for the version of the entity that they
believe to be current in an "If-None-Match" header field. The server can compare this entity-tag to the entity it believes to be current
and suppress resending the entity in the response if the server
believes the client’s version matches. In other words, the server
doesn’t resend information that the client has already received.
The SIP PUBLISH [RFC3903] method uses a similar mechanism, where a
refresh of a publication is done by reference to its assigned entity- tag, instead of retransmitting the event state each time the
publication expiration is extended.
2.3. Requirements
As a summary, here is the required functionality to solve the
presented issues:
REQ1: It must be possible to suppress the NOTIFY request (or at a
minimum, the event body therein) if the subscriber is already in possession of (or has previously received and discarded)
the latest event state of the resource.
REQ2: This mechanism must apply to initial subscriptions in which
the subscriber is attempting to resume an earlier
subscription that has been paused.
REQ3: This mechanism must apply to refreshing a subscription.
REQ4: This mechanism must apply to terminating a subscription
(i.e., an unsubscribe).
REQ5: This mechanism must apply to fetching or polling of resource state.
Niemi & Willis Standards Track [Page 6]
3. Overview of Operation
Whenever a subscriber initiates a subscription, it issues a SUBSCRIBE request. The SUBSCRIBE request is sent, routed, and processed by the notifier normally, i.e., according to the Session Initiation Protocol [RFC3261] and SIP-Specific Event Notification [RFC3265].
If the notifier receiving the SUBSCRIBE request supports conditional subscriptions, it generates an entity-tag for the current entity, and includes it in a SIP-ETag header field of the NOTIFY request. The
entity-tag is unique across all versions of all entities for a
resource and event package. See Section 4 for more on this.
Entity-tags are independent of subscriptions. This allows
notifications generated to a fetch or a poll to have valid entity-
tags even across subsequent fetches or polls.
The subscriber will store the entity-tag received in the notification along with the resource state. It can then later use this entity-tag to make a SUBSCRIBE contain a condition in the form of a "Suppress-
If-Match" header field. Unlike the "If-Match" condition in a PUBLISH [RFC3903] request, which applies to whether the PUBLISH succeeds or
returns an error, this condition applies to the stream of
notifications that are sent after the SUBSCRIBE request has been
processed.
The Suppress-If-Match header field contains the last entity-tag seen by the subscriber. This condition, if true, instructs the notifier
to suppress either the body of a subsequent notification, or the
entire notification.
The condition is evaluated by matching the value of the header field against the entity-tag of the entity that would normally be sent in
the associated NOTIFY message. There is also a wildcard entity-tag
with a special value of "*" that always matches.
Niemi & Willis Standards Track [Page 7]
Subscriber Notifier
---------- --------
(1) SUBSCRIBE -------->
Expires: 3600
<-------- (2) 200 (or 202)
<-------- (3) NOTIFY
Subscription-State: active SIP-ETag: ffee2
(4) 200 -------->
... time passes ...
(5) SUBSCRIBE --------> \ if "ffee2"
Suppress-If-Match: ffee2 | matches
Expires: 3600 | local
| entity-tag
|
<-------- (6) 204 / then
... time passes and resource state (entity) changes...
<-------- (7) NOTIFY
Subscription-State: active SIP-ETag: ca89a
(8) 200 -------->
... time passes ...
(9) SUBSCRIBE --------> \ if "ca89"
Suppress-If-Match: ca89a | matches
Expires: 0 | local
| entity-tag
|
<-------- (10) 204 / then
Figure 1: Example Message Flow
Figure 1 describes a typical message flow for conditional
notification:
(1) The subscriber initiates a subscription by sending a SUBSCRIBE request for a resource.
Niemi & Willis Standards Track [Page 8]
(2) After proper authentication and authorization, the notifier
accepts the subscription.
(3) The notifier then immediately sends the initial event
notification, including a unique entity-tag in a SIP-ETag
header field.
(4) The subscriber accepts the notification and stores the entity- tag value along with the resource state.
(5) Later, the subscriber refreshes the subscription, and includes an entity-tag in a Suppress-If-Match header field.
(6) The notifier evaluates the condition by matching its local
entity-tag value for the resource against the value of the
Suppress-If-Match header field. If the condition evaluates to true, the notifier informs the subscriber that the notification will not be sent.
(7) At some point, the state of the resource changes, e.g., the
presence status of a user changes from online to busy. This
triggers an event notification with a new value in the SIP-ETag header field.
(8) The subscriber accepts the notification and stores the new
entity-tag along with the resource state.
(9) After a while, the subscriber decides to terminate the
subscription. It adds a condition for Suppress-If-Match, and
includes the entity-tag it received in the previous NOTIFY.
(10) The notifier evaluates the condition by matching its entity-tag for the resource against the value of the Suppress-If-Match
header field. If the condition evaluates to true, the notifier informs the subscriber that no notification will be sent. This concludes the subscription.
The benefit of using conditional notification in this example is in
the reduction of the number of NOTIFY requests the subscriber can
expect to receive. Each event notification that the subscriber has
already seen is suppressed by the notifier. This example illustrates only one use case for the mechanism; the same principles can be used to optimize the flow of messages related to other event notification use cases.
Niemi & Willis Standards Track [Page 9]
4. Resource Model for Entity-Tags
The key to understanding how conditional notification works is
understanding the underlying resource model of event notification.
In general, this model is similar to the resource model of HTTP with some key differences. This section explains in detail the model as
it applies to SIP events. Figure 2 illustrates the model.
+-----+
............ | |
. . | URI |
. Represen . | |
. tation . +-----+
. . |*
............ |
. |
. V
. +----------+ +---------+
composition | |* | Event |
+------<>| Resource |----------->| Package |<----.
| | | | | |
| +----------+ +----.----+ |
| /_\ |
|* | classification
+--------+ | |
| | .----------------.------’ |
| Entity | | | |
| | | | |*
+--------+ +----------+ +------------+ +----------+
^ | | | | | |
| | Presence | | Conference | | Template |
| | | | | | |
|1..* +----------+ +------------+ +----.-----+
+---------+ /_\
| | |
| Version | |
| | +---------+
+---------+ | Watcher |
|1 | Info |
| | |
V +---------+
+---------+
| Entity- |
| Tag |
| |
+---------+
Figure 2: Resource Model Diagram
Niemi & Willis Standards Track [Page 10]
For a given event package, there is a single authoritative agent
responsible for zero or more resources. That is, even for a
distributed agent, the resource state is uniform across all
instances. The resource itself can be a list of resources [RFC4662]. Conditional notification for list subscriptions is addressed in
Section 6.5.
A resource is identified by zero or more URIs, which can be SIP URIs, pres URIs [RFC3859], or similar. Subscribers use this URI to
subscribe to the resource for certain types of events, identified by the event package.
With a successful subscription, a subscriber receives event
notifications that communicate the resource state and the changes
thereto. Each event notification carries a representation of the
current resource state. This representation is influenced by many
factors, e.g., authorization and filtering rules, and the event
composition rules of the notifier.
This representation is realized in an "entity". Each resource may be associated with zero or more entities. For example, there may be
multiple subscribers to the presence information of a single user (a resource), and each subscriber may have a different filtered view of that resource, producing one entity per subscriber. However, each
entity is associated with one and only one resource; there is no
"compositing" of resources at the entity level. Resources may
themselves be made up of information from other resources (be
"composite resources"), but this does not change the one-resource-
per-entity rule.
An entity consists of the data carried in the body of a NOTIFY
message and related meta-data in the message header. Whenever the
data in the body or any of the meta-data changes, the notifier MUST
produce a new entity-tag. This meta-data MUST include, but is not
limited to the following SIP header fields defined in the Session
Initiation Protocol [RFC3261] and SIP Specific Event Notification
[RFC3265]:
1. Content-Disposition
2. Content-Encoding
3. Content-Language
4. Content-Length
5. Content-Type
Niemi & Willis Standards Track [Page 11]
6. Event
Note that the Subscription-State is explicitly not part of the
entity. In the future, event packages may define additional fields
that implementations need to consider as part of the entity.
An entity has one or more versions of which only one is current and
all others stale. Each version has an entity-tag, which uniquely
identifies it across all versions of all entities pertaining to a
single resource and event package.
Note that two entity-tags for different resources being equal does
not indicate identical entities. In other words, if an entity-tag
received for a subscription to a first resource matches an entity-tag received for a subscription to a second resource, the subscriber
cannot assume that the two entity values are equal.
With partial event notification, the NOTIFY message only carries the delta state, or the set of changes to the previous version of the
entity. In that case, implementations MUST consider the full event
state as the version of the entity to which the entity-tag in the
NOTIFY message applies.
The conditional notification mechanism is independent of the way in
which subscriptions are installed. In other words, the mechanism
supports implicit subscriptions, such as those associated with the
REFER method [RFC3515].
It is possible that the same resource is in some shape or form
accessible through another mechanism in addition to SIP Event
Notification, e.g., HTTP or the SIP PUBLISH method. In general,
implementations MUST NOT expect the entity-tags to be shared between the mechanisms, unless event packages or specific applications of SIP events explicitly define such dependencies.
5. Subscriber Behavior
This section augments the subscriber behavior defined in RFC 3265
[RFC3265]. It first discusses general issues related to indicating
support for the mechanism (Section 5.1) and creating conditions in
SUBSCRIBE requests (Section 5.2). Next, it describes subscriber
behavior for receiving NOTIFY requests (Section 5.3), and specific
client workflows for polling resource state (Section 5.4), resuming a subscription (Section 5.5), refreshing a subscription (Section 5.6), and terminating a subscription (Section 5.7). Finally, handling of
transient errors is discussed (Section 5.8).
Niemi & Willis Standards Track [Page 12]
5.1. Detecting Support for Conditional Notification
The mechanism defined in this memo is backwards compatible with SIP
events [RFC3265] in that a notifier supporting this mechanism will
insert a SIP entity-tag in its NOTIFY requests, and a subscriber that understands this mechanism will know how to use it in creating a
conditional request.
Unaware subscribers will simply ignore the entity-tag, make requests without conditions, and receive the default treatment from the
notifier. Unaware notifiers will simply ignore the conditional
header fields and continue normal operation.
5.2. Generating SUBSCRIBE Requests
When creating a conditional SUBSCRIBE request, the subscriber MUST
include a single conditional header field including an entity-tag in the request. The condition is evaluated by comparing the entity-tag of the subscribed resource with the entity-tag carried in the
conditional header field. If they match, the condition evaluates to true.
Unlike the condition introduced for the SIP PUBLISH [RFC3903] method, these conditions do not apply to the SUBSCRIBE request itself, but to the resulting NOTIFY requests. When true, the condition drives the
notifier to change its behavior with regard to sending the
notifications after the SUBSCRIBE.
This specification defines a new header field called Suppress-If-
Match. This header field introduces a condition to the SUBSCRIBE
request. If true, it instructs the notifier either to omit the body of the resulting NOTIFY message (if the SUBSCRIBE is not sent within an existing dialog) or to suppress (i.e., block) the NOTIFY request
that would otherwise be triggered by the SUBSCRIBE (for an
established dialog). In the latter case, the SUBSCRIBE message will be answered with a 204 (No Notification) response. As long as the
condition remains true, it also instructs the notifier either to
suppress any subsequent NOTIFY request or, if there are reportable
changes in the NOTIFY header, e.g., the Subscription-State has
changed, to suppress the body of any subsequent NOTIFY request.
If the condition is false, the notifier follows its default behavior. If the subscriber receives a 204 (No Notification) response to an in- dialog SUBSCRIBE, the subscriber MUST consider the event state and
the subscription state unchanged.
Niemi & Willis Standards Track [Page 13]
The value of the Suppress-If-Match header field is an entity-tag,
which is an opaque token that the subscriber simply copies (byte-
wise) from a previously received NOTIFY request. Inclusion of an
entity-tag in a Suppress-If-Match header field of a SUBSCRIBE request indicates that the client has a copy of, or is capable of recreating a copy of, the entity associated with that entity-tag.
Example:
Suppress-If-Match: b4cf7
The header field can also be wildcarded using the special "*" entity- tag value. Such a condition always evaluates to true regardless of
the value of the current entity-tag for the resource.
Example:
Suppress-If-Match: *
Such a wildcard condition effectively quenches a subscription; the
only notifications received are those reporting changes to the
subscription state and those in response to a SUBSCRIBE message sent outside of an existing dialog. In both cases, the notifications will not contain a body.
A subscription with a wildcard Suppress-If-Match condition is
useful in scenarios where the subscriber wants to temporarily put a subscription in dormant mode. For example, a host may want to
conserve bandwidth and power when it detects from screen or input device inactivity that the user isn’t actively monitoring the
presence statuses of contacts.
5.3. Receiving NOTIFY Requests
When a subscriber receives a NOTIFY request that contains a SIP-ETag header field, it MUST store the entity-tag if it wishes to make use
of the conditional notification mechanism. The subscriber MUST be
prepared to receive a NOTIFY with any entity-tag value, including a
value that matches any previous value that the subscriber might have seen.
The subscriber MUST NOT infer any meaning from the value of an
entity-tag; specifically, the subscriber MUST NOT assume identical
entities (i.e., event state) for NOTIFYs with identical entity-tag
values when those NOTIFYs result from subscription to different
resources.
Niemi & Willis Standards Track [Page 14]
Note that there are valid cases for which identical entity-tag
values on different resources may occur. For example, it is
possible to generate entity-tag values using a one-way hash
function, resulting in the possibility that two different
resources having the same entity-value will also have the same
entity-tag. Clients however MUST NOT assume that this is the
case, as the algorithm for the generation of entity-tags is
notifier-dependent and not negotiated with the subscriber.
Consequently, the subscriber cannot differentiate between two
entity-tags that have the same value because they are similar
hashes of identical entities, or because two notifiers happen to
have used the same sequential number as an entity-tag. Entity
tags are only required to be unique for a given resource, not
globally unique.
5.4. Polling or Fetching Resource State
Polling with conditional notification allows a user agent to
efficiently poll resource state. This is accomplished using the
Suppress-If-Match condition:
Niemi & Willis Standards Track [Page 15]
Subscriber Notifier
---------- --------
(1) SUBSCRIBE -------->
Expires: 0
<-------- (2) 202
<-------- (3) NOTIFY
Subscription-State: terminated SIP-ETag: f2e45
Content-Length: 17539
(4) 200 -------->
... poll interval elapses ...
(5) SUBSCRIBE -------->
Suppress-If-Match: f2e45
Expires: 0
<-------- (6) 202
<-------- (7) NOTIFY
Subscription-State: terminated SIP-ETag: f2e45
Content-Length: 0
(8) 200 -------->
Figure 3: Polling Resource State
(1) The subscriber polls for resource state by sending a SUBSCRIBE
with zero expiry (expires immediately).
(2) The notifier accepts the SUBSCRIBE with a 202 (Accepted)
response.
(3) The notifier then immediately sends a first (and last) NOTIFY
request with the current resource state and the current entity- tag in the SIP-ETag header field.
(4) The subscriber accepts the notification with a 200 (OK)
response.
(5) After some arbitrary poll interval, the subscriber sends another SUBSCRIBE with a Suppress-If-Match header field that includes
the entity-tag received in the previous NOTIFY.
Niemi & Willis Standards Track [Page 16]
(6) The notifier accepts the SUBSCRIBE with a 202 (Accepted)
response. (202 would be used to indicate that the subscription request was understood without also indicating that it was
authorized, as per Section 3.1.6.1 of SIP-Specific Event
Notification [RFC3265].)
(7) Since the resource state has not changed since the previous poll occurred, the notifier sends a NOTIFY message with no body. It also mirrors the current entity-tag of the resource in the SIP- ETag header field.
(8) The subscriber accepts the notification with a 200 (OK)
response.
5.5. Resuming a Subscription
Resuming a subscription means the ability to continue an earlier
subscription that either closed abruptly or was explicitly
terminated. When resuming, the subscription is established without
transmitting the resource state. This is accomplished with
conditional notification and the Suppress-If-Match header field:
Subscriber Notifier
---------- --------
(1) SUBSCRIBE -------->
Suppress-If-Match: ega23
Expires: 3600
<-------- (2) 202
<-------- (3) NOTIFY
Subscription-State: active SIP-ETag: ega23
Content-Length: 0
(4) 200 -------->
Figure 4: Resuming a Subscription
(1) The subscriber attempts to resume an earlier subscription by
including a Suppress-If-Match header field with the entity-tag
it last received.
(2) The notifier accepts the subscription after proper
authentication and authorization, by sending a 202 (Accepted)
response.
Niemi & Willis Standards Track [Page 17]
(3) Since the condition is true, the notifier then immediately sends an initial NOTIFY request that has no body. It also mirrors the current entity-tag of the resource in the SIP-ETag header field.
(4) The subscriber accepts the NOTIFY and sends a 200 (OK) response. Had the entity-tag not been valid any longer, the condition would
have evaluated to false, and the NOTIFY would have had a body
containing the latest resource state.
5.6. Refreshing a Subscription
To refresh a subscription using conditional notification, the
subscriber creates a subscription refresh before the subscription
expires, and uses the Suppress-If-Match header field:
Subscriber Notifier
---------- --------
(1) SUBSCRIBE -------->
Suppress-If-Match: aba91
Expires: 3600
<-------- (2) 204
Expires: 3600
Figure 5: Refreshing a Subscription
(1) Before the subscription expires, the subscriber sends a
SUBSCRIBE request that includes the Suppress-If-Match header
field with the latest entity-tag it has seen.
(2) If the condition evaluates to true, the notifier sends a 204 (No Notification) response and sends no NOTIFY request. The Expires header field of the 204 (No Notification) response indicates the new expiry time.
5.7. Terminating a Subscription
To terminate a subscription using conditional notification, the
subscriber creates a SUBSCRIBE request with a Suppress-If-Match
condition:
Niemi & Willis Standards Track [Page 18]
Subscriber Notifier
---------- --------
(1) SUBSCRIBE -------->
Suppress-If-Match: ega23
Expires: 0
<-------- (2) 204
Figure 6: Terminating a Subscription
(1) The subscriber decides to terminate the subscription and sends a SUBSCRIBE request with the Suppress-If-Match condition with the entity-tag it has last seen.
(2) If the condition evaluates to true, the notifier sends a 204 (No Notification) response, which concludes the subscription, and
the subscriber can clear all state related to the subscription.
5.8. Handling Transient Errors
This section is non-normative.
In some deployments, there may be Back-to-Back User Agent (B2BUA)
devices that track SIP dialogs such as subscription dialogs. These
devices may be unaware of the conditional notification mechanism.
It is possible that some B2BUA devices may treat a NOTIFY with
suppressed body as an error, or may expect all SUBSCRIBE messages to have an associated NOTIFY message.
In general, there is very little that an endpoint can do to recover
from such transient errors. The most that can be done is to try to
detect such errors, and define a fallback behavior.
If subscribers encounter transient errors in conditional
notification, they should disable the feature and fall back to normal subscription behavior.
Niemi & Willis Standards Track [Page 19]
6. Notifier Behavior
This section augments the notifier behavior as specified in RFC 3265 [RFC3265].
6.1. Generating Entity-tags
An entity-tag is a token carried in the SIP-ETag header field, and it is opaque to the client. The notifier is free to decide on any means for generating the entity-tag. It can have any value, except for
"*". For example, one possible method is to implement the entity-tag as a simple counter, incrementing it by one for each generated
notification per resource.
A notifier MUST generate entity-tags for event notifications of all
resources for which it is responsible. The entity-tag MUST be unique across all versions of all entities for each state of a resource as
reported by a given event package. Otherwise said, for any
subscription or sequence of subscriptions to a specific resource
using a singular event package, each entity-tag produced MUST map to one and only one presentation of resource state (entity). Two
identical entities for a specific resource might or might not have
identical entity-tags; this decision is left to the notifier.
An entity-tag is considered valid for as long as the entity exists.
An entity becomes stale when its version is no longer the current
one. The notifier MUST remember (or be able to recalculate) the
entity-tag of an entity as long as the version of the entity is
current. The notifier MAY remember the entity-tag longer than this, e.g., for implementing journaled state differentials (Section 6.4).
The entity-tag values used in publications are not necessarily shared with the entity-tag values used in subscriptions. This is because
there may not always be a one-to-one mapping between a publication
and a notification of state change; there may be several sources to
the event composition process, and a publication into a resource may not affect the resulting entity.
6.2. Suppressing NOTIFY Bodies
When a condition in a SUBSCRIBE request for suppressing notifications is true (i.e., the local entity-tag for the resource state and the
entity-tag in a Suppress-If-Match header field are byte-wise
identical) but there are reportable changes in the NOTIFY header
(e.g., the Subscription-State has changed), the notifier MUST
suppress the body of the NOTIFY request. That is, the resulting
NOTIFY contains no Content-Type header field, the Content-Length is
set to zero, and no payload is attached to the message.
Niemi & Willis Standards Track [Page 20]
管理学原理 管理学是一门综合性的交叉学科，是系统研究管理活动的基本规律和一般方法的科学。管理学是适应现代社会化大生产的需要产生的，它的目的是:研究在现有的条件下，如何通过合理的组织和配置人、财、物等因素，提高生产力的水平。 管理是指在特定的环境下，管理者通过执行计划、组织、领导、控制等职能，整合组织的各项资源，实现组织既定目标的活动过程。 它有三层含义: (1) 管理是一种有意识，有目的的活动，它服务并服从于组织目标。 (2)管理是一个连续进行的活动过程，实现组织目标的过程，就是管理者执行计划组织领导控制等职能的过程。由于这一系列职能之间是相互关联的，从而使得管理过程体现为一个连续进行的活动过程。 (3)管理活动是在一定的环境中进行的，在开放的条件下，任何组织都处于千变万化的环境之中，复杂的环境成为决定组织生存与发展的重要因素。 折叠相关书籍 目前还没有一套普遍公认的完整的管理学原理体系。不同版本的管理学教科书和辞书，各有一套不同的管理学原理体系。 折叠《现代管理科学词库》
朱新民、李永春、周吉主编《现代管理科学词库》（上海交通大学出版社1986年9月） 中提出了下列管理原理体系：《现代管理科学词库》 ⑴系统原理：为了达到最佳管理，必须进行系统分析，抓住系统的三个环节：目的性、全局性、层次性。 ⑵整分合原理：现代高效率的管理，必须在整体规划下明确分工，在分工基础上有效地综合。 ⑶反馈原理：面对不断变化的客观实际，必须做到灵敏、准确、有力的反馈。 ⑷封闭原理：任一系统内的管理手段必须构成一个连续封闭的回路。 ⑸能级原理：将不同的个人，根据其能力大小，分别安排在适当层次的组织机构中，做到人尽其才，能者多劳。 ⑹弹性原理：管理必须保持充分的弹性，以适应各种可能的变化，实现动态管理。 ⑺动力原理：管理必须有强大的动力，包括物质动力、精神动力，信息动力，才能持续有效地进行。 折叠《管理学》 张正河、陆娟主编《管理学》的原理体系为： ⑴人本原理：以人（员工）为中心，以人为本。
周三多版《管理学》 周三多版《管理学》是教育部“面向世纪教学内容和课程体系改革计划”以及高等教育出版社“高等教育百门精品课程教材建设计划”的研究成果, 是国内最受欢迎的标准管理学教材之一，并被全国余所高等院校广泛采用并作为管理学教学及研究生入学考试、博士生入学考试的典范教材。 周三多版《管理学》章节目录编排包括按照管理职能划分的总论、决策与计划、组织、领导、控制、创新等六个内容部分，分为十八章。文都网校考研《管理学》在授课过程中，教师会依次深入剖析专业课核心知识点对应的复习资料、基础知识框架梳理及其解析内容等。目的是帮助学生发现题目设置和解答的规律性，掌握题目对应的知识点和熟悉解题的金钥匙。从而降低考研专业课的复习难度，迅速提高专业课知识水平，为下一阶段的学习做好储备与铺垫。 考试重点难点早知道: 一、德尔菲法的特点；法约尔的跳板原则；切斯特.巴纳德对组织理论的贡献；管理的理念和方法对管理过程和结果的影响；管理的效率和效果的区别；社会人假设；管理科学理论。 二、终极性价值观与工具性价值观；管理者的责任；管理伦理；：跨文化管理；组织外部环境。 三、组织中的信息管理工作；信息系统；与Ⅱ；；虚拟团队；非确定性决策；群体决策；程序和非程序决策。 四、计划；计划与决策的关系；“计划跟不上变化，所以制定计划没有意义”如何理解这句话；在企业中怎样进行计划管理。 五、战略计划；分析法；企业战略；计划审评技术；企业目标与企业的宗旨和使命的关系；目标管理利弊；有效推行目标管理的条件。 六、委员会;有机式组织;直线人员与参谋人员;矩阵组织结构;虚拟组织;组织扁平化;授权;组织“横向化”;非正式组织;管理幅度与管理层次。 七、素质模型;弹性福利计划;组织氛围;雇员援助计划;纯基薪计划;评价中心;周边绩效;薪酬水平;劳动关系;团队管理;人力资源管理与人事管理;人本管理;薪酬管理的外部公平、内部公平与员工公平;培训效果评估;员工福利;培训需求分析;工作分析。 八、建设性冲突;组织层面变革;减少破坏冲突的方法;对建设有中国特色的组织文化的看法;企业文化。 九、变革型领导;概念技能;领导与管理;领导应该具备的技能;权力在行使领导职能的作用。
Nginx 设置rewrite规则 Windows下环境为wamp ，在wamp 环境下，设置rewite规则时，很是简单，只需要打开Apache配置中的rewrite规则，项目中使用rewrite规则时只需创建.htaccess文件，在文件中编写规则，Apache会自动进行解析，但是在linux下则有些不一样。 Linux下环境若是lamp，则和wamp下是相同的，但当环境为lnmp时，需要注意进行如下配置方法： 根据所安装的环境情况，如果环境是lnmp集成环境，在配置rewrite规则时，因为集成环境，在安装完毕后，在安装的目录/usr/local/nginx/conf下，会生成一个文件“wordparss”，这个文件中是专门用于写rewrite规则所用，你可以在这个文件中书写rewrite规则，nginx 的rewrite规则与Apache的规则基本是相同的，只是在文件中书写的方法不同，wordpaess 问件中默认是有一个规则的，如： 利用location加载访问路径，“/”，指代由访问路径的根目录开始， 用if对加载的路径$request_filename 进行验证： 1 、-f 和！-f 用来判断文件是否存在 2、-d 和！-d 用来判断目录是否存在 3 、-e 和！-e 用来判断文件或目录是否存在 4、-x 和！-x 用来判断文件是否可执行 Flag标记： 1、last 相当于Apache里的[L]标记，表示完成rewrite 2、break 终止匹配, 不再匹配后面的规则 3、redirect 返回302临时重定向地址栏会显示跳转后的地址 4、permanent 返回301永久重定向地址栏会显示跳转后的地址 因为在lnmp集成环境下要配置虚拟域名是可以进行自动生成的，生成后会在/usr/local/nginx/conf/vhost 下生成一个以虚拟域名的名字的文件，如：lin_hp.its.conf,而所对应的rewrite规则最好在与域名相对应的配置文件中进行配置，这样不会说，如果有多个域名时，他们所对应的rewrite规则不同，在公共的wordpress文件中配置引起冲突，所配置的方法与在wprdpress文件中是相同的，如：
管理学原理（第二版）2012年4月考试考前练习题 一、单选题 1．在现实中我们经常能够看到这样一种现象：一所高校的校长往往是在某学科造诣很高的学术专家，一所医院的院医学专家。但是，有些学术专家家却未能成为称理者。针对上述象，正确的评价是（D ）。 A．就管理层次而言，技能重要B．搞技术的人往往不善于与弱，难以担当管理之职C．对高层管理者来念技不重要D．就管理层次而言，越往上概念技能越重要，越往下技术技能越重要 2．对组织内外部条件各方面内容进行综合和概括，进而分析和威胁的环境分析方法是指（ A ）。 A．SWOT分析B．PEST分析C．行业竞争结构分析D．波士顿矩阵分析 3．某公司总经理除了直接指挥几个地区分公司经理之外，他还设立了人事助理、财务顾问、公共关系顾问等职，并配备了相应的人顾问授予了直权限。这个过程反映了哪两种职权之间的转换？（D ） A．从职能职权到直线职权B．从职能职权到参谋职权C．从参谋职权到直线职权 D．从参谋职权到职能职权 4．某企业有较强的产品研究开发和市场营销能力，能够在产品设计、工艺技术和营销上不断发挥创造性；在产品质量、技术以及营销和服务等方面有着良好声誉。该企业适宜采用的竞争战略是（B ）。 A．低成本战略B．差异化战略C．重点化战略D．集中化战略5．车间主任老王最近发现，质检员小林一有空就与机关的小刘、设计室老张和门卫老杨等一起谈足球，个个眉飞色舞，而参加例会却经常没精打采。对此，车间主任老王最好采取什么措施？（C ） A．批评小林，并对他提出要求，以后不许在厂里和他人谈足球B．严格执行车间工作制度，对擅自违反规定者加以严厉惩罚C．在强调必须遵守工作制度的同时，在车间搞一个球迷协会，并亲自参加协会活动D．对上述情况不闻不问，任其自由发展 6．在组织绩效管理中，核心环节是（ C ）。 A．绩效设计B．绩效改进C．绩效评估D．绩效反馈 7．某公司为了扭转销售不力的局面，提升销售能手张先生出任销售部经理。到了年末，销售部业绩虽然较上一年略有下降，但张经理一人完成的订单占部门完成任务总量的53%。在如何评价张经理的工作一致。下述哪种评价最恰当？（ D ） A．"能抓住耗子的猫就是好猫"。张经理个人能予大力表彰 B．产品的销售客观上依赖张经理的努力他特别奖励 C．对张经理的奖惩应该依据部门部门目标，所以必须对张经理予以严惩D．张先生是一个优秀的销售人员，但不是一个合格的经理人员。公司需要尽可能在不影响其积极性的基础上重新调整其工作 8．《孙子兵法》是一部不朽的军事著作，时至今日，对企业经营战略仍有重要指导作用。孙子认为：作战的势态的。他指出“故兵无常势，水，谓之神”。从管理角度看，这一描述更符合（ C ）。 A．权责对等原则B．系统理论原则C．权变理论原则D．统一指挥原则 9．某公司随着经营规模的扩大，由王副总经理直管的营销队伍人数也从3人增加到近100人。最近，公司发现营，但又找不到确切的原因。从管理的角度看，出现这种情况的主要原因是（C ）。 A．营销人员太多，产生了鱼龙混杂的情况 B．副总经理投入管理的时间不够，致使营销人员产生了看法 C．副总经理的管理幅度太宽，以至于无法对营销队伍实行有效的管理 D．营销队伍的管理层次太多，使得副总经理无法与营销人员实现有效的沟通10．风险型决策与不确定型决策的区别主要在于（ D ）。 A．风险型决策承担的风险相对于不确定型决策来说要小 B．风险型决策面临的是多种可能的自然状态，而非确定型决策面临的是无法预知的自然状态 C．二者的区别不明显 D．风险型决策可以预测未来自然状态出现的概率，而非确定型决策不能预测概率 11．目标管理的基本过程为（B ）。 A．奖励和开始新的目标循环—建立目标体系—检查和评价—组织实施 B．建立目标体系—组织实施—检查和评价—奖励和开始新的目标循环 C．检查和评价—奖励和开始新的目标—建立目标体系—组织实施 D．奖励和开始新的目标循环—建立目标体系—组织实施—检查和评价12．在以下几项管理业务中，哪一项该由公司总经理亲自处理和拍板？（C ）A．关于公司各部门办公电脑的分配方案B．对一位客户投诉的例行处理C．对一家主要竞争对手突然大幅降价做出反应D．对一位公司违纪员工按规章进行处理 13．在管理决策中，许多管理人员认为只要选取满意的方案即可，而无须刻意追求最优的方案。对于这种观点，以下哪种解释最有说服力？（ D ）A．现实中不存在所谓的最优方案，所以选中的都只是满意方案 B．现实管理决策中常常由于时间太紧而来不及寻找最优方案 C．由于管理者对什么是最优决策无法达成共识，只有退而求其次 D．刻意追求最优方案，常常会由于代价太高而最终得不偿失 14．刚进公司的几个大学生很自然地形成了一个团队，大家兄弟相待，一起解决各自遇到的难题，包括各自负责的经营工作。几年下来，这个团队的凝聚力很强，每个人都非常珍视这个团队。又过了几年，这个团队的成员普遍得到较好的发展，但地位、收入等方面并没有形成多大的差距，然而大家却都感到团队的凝聚力没有以前那么强大了。造成这个团队松散的原因是什么？（B ）A．团队成员的能力增强了，独立性提高了B．没有更高层次的目标推动C．团队成员之间因工作繁忙而沟通太少D．没有及时吸收新的团队成员 15．曹雪芹虽食不果腹，仍然坚持《红楼梦》的创作，是出于其（C ）。 A．自尊需要B．情感需要C．自我实现的需要D．以上都不是 二、多选题 1．组织结构的内容主要包括（BCDE）。 A．计划结构B．职能结构C．层次结构D．部门结构 E．职权结构 2．法约尔首先对企业管理职能做了科学的概括，他认为企业管理职能包括（ABCDE）。 A．计划B．组织C．指挥D．协调 E．控制 3．组织常用的控制手段有（ABCD ）。 A．计划控制B．时间控制C．数量控制D．质量控制 E．政策控制 4．学习型组织强调的修炼内容有（ABCE）。 A．不断地追求自我超越B．善于改善心智模式C．善于为组织建立共同愿景 D．彻底改造流程E．善于学会系统思考 5．常见的部门划分方法有（ABCDE）。 A．职能部门化B．产品部门化C．地区部门化D．服务对象部门化E．工艺过程部门化 6．团队精神包含的内容有（ABC ）。 A．团队凝聚力B．团队合作意识C．团队士气D．团队组织E．团队领导 三、判断题 1．利用波士顿矩阵分析方法，当产品的市场增长上应投入必要的资金，力求提高自己的市场份额。错 2．从赫兹伯格的双因素理论看，组织的政策员之报酬、工作环境等因素属于激励因素。错 3．信息沟通必须具备的要素有三个：发送者、接收者、所传递的内容。错 4．体现了“集中政策，分散经营”原则的组织结构形式是事业部制组织。对 5．平衡计分卡法最突出的特点是：将组织的远景、使命和发展战略与组织的绩效评价系统联系起来，它把组织的使命和战略转变展战略有明确认识，以实现战略和绩效的有机结合。对 6．管理者应具备的技能被划分为三类：技术技能、人际技能和概念技能。就管理层次而言，越往上人际技能越重要，越往下概念技能越重要。错 7．非程序性决策，是指对经常出现的重复性问题,并生产作本控制、对员工奖惩的实施等。错 8．横向一体化战略是指从产品的供、产、销等一系列相关业现有经营业务和规模的发展战略。错 9．组织的一般环境因素是指对组织目标的实现有直接影响的外部环境因素，一般包括资源供应者、竞争者、服务对象、政府管理部门及社会上的各种利益代表组织。错 10．企业的社会责任就是使利润最大化。错 11．马克斯·韦伯对管理理论的突出贡献是：从理论上把管理科学提到一个新的高度。错 12．有的观点认为组织应该鼓励冲突，认为冲突不突对于组织有效运作是绝对必要的。对
Nginx安装手册 1nginx安装环境 nginx是C语言开发，建议在linux上运行，本教程使用Centos6.5作为安装环境。 ?gcc 安装nginx需要先将官网下载的源码进行编译，编译依赖gcc环境，如果没有gcc环境，需要安装gcc：yum install gcc-c++ ?PCRE PCRE(Perl Compatible Regular Expressions)是一个Perl库，包括perl 兼容的正则表达式库。nginx的http模块使用pcre来解析正则表达式，所以需要在linux上安装pcre库。yum install -y pcre pcre-devel 注：pcre-devel是使用pcre开发的一个二次开发库。nginx也需要此库。 ?zlib zlib库提供了很多种压缩和解压缩的方式，nginx使用zlib对http包的内容进行gzip，所以需要在linux上安装zlib库。 yum install -y zlib zlib-devel ?openssl OpenSSL 是一个强大的安全套接字层密码库，囊括主要的密码算法、常用的密钥和证书封装管理功能及SSL协议，并提供丰富的应用程序供测试或其它目的使用。 nginx不仅支持http协议，还支持https（即在ssl协议上传输http），所以需要在linux 安装openssl库。 yum install -y openssl openssl-devel 2编译安装 将nginx-1.8.0.tar.gz拷贝至linux服务器。 解压： tar -zxvf nginx-1.8.0.tar.gz cd nginx-1.8.0 1、configure ./configure --help查询详细参数（参考本教程附录部分：nginx编译参数） 参数设置如下： ./configure \
经济与管理学院 《管理学原理》实习报告 系别 专业班级 学生姓名 学号 实习报告题目参观海马汽车有限公司报告 实习课程名称管理学原理 课程实习形式参观学习 课程实习时间2009年12月31日 课程实习地点海马汽车有限公司 指导教师 二ΟΟ九年一月三日
实习目的：了解现代先进生产技术，开拓视野，领略现代企业管理模式，体会《管理学原理》所授课程的实践内涵 实习内容： 1、海马汽车公司整体简介，了解汽车企业文化 2、参观汽车总装车间，通晓汽车生产装配流程 3、观看跑道试车，体验汽车质量和风采 单位调查： 一汽海南汽车有限公司(FHC)位于海南省海口市，是以1988年购进的美国福特汽车公司菲律宾冲压厂和装配厂的全套设备为基础，引进美国、英国、日本的自动焊装及涂装等工艺生产线，建设而成的国有大型企业。经过十余年的发展，已拥有技术先进的冲压、焊装、涂装、总装汽车工艺生产线，机械加工、动力、理化试验、全自动综合立体仓库等辅助生产设施，和计算机管理系统，计算机辅助设计、制造系统，成为国家轻型客车与轿车的整车定点生产基地。年设计生产能力为整车5万辆。1992年，公司与日本马自达汽车公司(MC)合资成立海南马自达汽车冲压有限公司，引进开发323轿车、海马旅行车、面包车和MPV 系列车型，树立起高品质的海南马自达品牌。集团化发展是增强企业竞争力、实现产业结构调整的必经之路，公司于1998年1月18日进入一汽集团，轿车、MPV等产品纳入了集团和国家汽车产业统一规划。 海南马自达销售有限公司成立于1996年，注册资本1000万元。总经销海南马自达系列产品。公司在北京、上海、广州和成都设立了4个区域办事机构和一个车辆中转储运中心，在全国几十座大中城市都建立起集整车销售、配件供应、售后服务、信息反馈四位一体的海南马自达销售服务店，形成了全国性销售服务网络。公司率先推出“保姆式”服务方案，以顾客和产品为核心，梳理从市场调研、产品定位、运输保养、现场销售到售后服务全过程，创新人性化、制度化、精细化的市场销售与服务方式。 参观实习过程：
管理学课程简介（一） 1 管理学研究的四大职能不包括（）。 A、计划 B、组织 C、控制 D、反馈 正确答案：D 2 德鲁克的管理学思想是以（）为导向的。 A、目标 B、过程 C、控制 D、综合 正确答案：A 3 应用型管理学的内容有管理学历史、管理学流派、管理学前沿。（）正确答案：× 管理学课程简介（二） 1 管理学所要培养的四个能力不包括（）。 A、科研能力 B、应用能力 C、阅读能力 D、沟通能力
正确答案：C 2 问题导向的课堂中以（）为主体。 A、教师 B、教材 C、教具 D、学生 正确答案：D 3 下面哪一项不是导向性课程的课程要求（）。 A、个人意见 B、课前预习 C、课堂参与 D、多项沟通 正确答案：A 4 问题导向的课堂讨论重点在于逻辑分析。（） 正确答案：√ 5 普华永道变革整合小组编著的《管理悖论》是管理学的入门教材。（）正确答案：× 管理学课程简介（三） 1 （）是我们组织的基本的社会单元。 A、政府 B、家庭 C、学校
D、军队 正确答案：B 2 下面不属于读书报告内容的是（）。 A、著作基本信息 B、作者主要观点 C、问题描述 D、个人心得 正确答案：C 3 政府、企业、慈善机构和学校都是组织。（）正确答案：√ 4 成员目标是共同目标的实现基础。（） 正确答案：× 组织及其机理（一） 1 创建组织的根本目的是（）。 A、达成共同目标 B、单纯盈利 C、对抗其他组织 D、行使行政职能 正确答案：A 2 组织低效、混乱的表现不包括（）。 A、资源浪费 B、内部消耗
C、精诚合作 D、争权夺利 正确答案：C 3 研究归纳推理的逻辑被称为归纳逻辑。（） 正确答案：√ 4 组织的形成完全依赖于外部环境。（） 正确答案：× 组织及其机理（二） 1 影响公司创业的关键因素不包括（）。 A、销售渠道 B、共同目标 C、创业团队 D、组织规范 正确答案：A 2 最先开创组织管理理论研究的美国著名管理学家是（）。 A、法约尔 B、巴纳德 C、泰罗 D、德鲁克 正确答案：B 3一个组织形成的外围促成因素不包括（）。 A、领导人
nginx配置解析详解(一) 现在针对nginx源码分析的blog和文章已经很多了，之前我也看过不少，大家的分析都很不错。太多重复的内容就不写了，主要想针对在我分析代码和查阅blog的过程中，发现的一些比较晦涩或者某些细节有待展开讨论的地方，给出我的自己理解和看法，希望跟大家交流和学习。 使用的nginx版本是nginx-1.0.6，我最开始看的代码是0.7.62，新的版本在功能和稳定性上做了很多的工作。在分析的时候，我尽量简单明了，不太重要的地方一带而过，具体地大家可以去读代码。相对复杂或者晦涩的地方，将详细展开。 首先我们从配置文件开始，下面的分析是建立在网友对nginx的配置文件结构有大概熟悉为前提，这样才可以很好的理解代码。这里有必要提醒一点：原始代码目录中 ngx_modules这个结构，是找不到它的定义和初始化，要看到它，你必须执行configure，make，在原来的代码目录下会出现一个objs文件夹，里面的3个文件ngx_auto_config.h，ngx_auto_headers.h，ngx_modules.c，需要在建source insight工程时也包含进去，这样有利于我们把握整个代码结构。有意思的是，nginx的configure文件是作者手工写的，里面有许多管理代码工程的方法，有时间的话，也是值得学习下的。 1.ngx_cycle_t *ngx_init_cycle(ngx_cycle_t *old_cycle); 配置文件的解析相关的处理主要在ngx_init_cycle函数中被调用。既然如此，我们就先说说ngx_init_cycle函数吧。 它需要一个参数类型为ngx_cycle_t *，返回值也是一个ngx_cycle_t*，与此同时我们注意到参数名为old_cycle，那么这个函数的作用是啥呢？很明显是由old得到一个new。其中ngx_cycle_t的结构保存一些全局的配置和信息。 这个函数具体作用将在reconfig(重读配置文件)的时候得到体现，可以理解为old_cycle 是当前正在使用的配置信息，当配置文件做了某些修改之后，ngx_init_cycle通过old_cycle 中的一些数据，对new_cycle进行一些设置，在经过进一步的配置解析之后，就可以得到一个new cycle。 2.char *ngx_conf_parse(ngx_conf_t *cf, ngx_str_t *filename) 当我们使用sourceinsight查看这个函数的调用情况时，会发现调用它的地方很多。其实，入口点就在ngx_init_cycle中对ngx_conf_parse调用，后面的所有的调用可以看作是在此之后的递归调用。为什么会是这个样子呢？原因在于nginx是一边读取配置信息，一边解析执行相关的处理，具体一点讲，就是“读一行，执行一行”，一行的定义在这里是指以分号或者是“{”和“}”等结尾的一行，例如：我们解析到http {}，我们就调用针对httpblock的处理，在处理的时候我们又会碰到server {}，自然就会调用server block的处理。。。以此类推！。
管理学专业介绍 管理学是系统研究管理活动的基本规律和一般方法的科学，学科分类上属一级学科。管理学是适应现代社会化大生产的需要产生的，它的目的是：研究在现有的条件下，如何通过合理的组织和配置人、财、物等因素，提高生产力的水平。管理学是一门综合性的交叉学科，更是现目前研究生报考的一大热点，更是跨专业报考的热点，每年都有相当数量的同学报考管理学。 管理学下设的二级学科有：企业管理，工商管理，会计学，，运筹与管理，旅游与酒店管理，公共事业管理，人力资源管理、市场营销等。 就业情况 适应在大中型企业特别是合资类与外向型企业、金融机构、政府机关、其它社会经济单位的信息管理部门、综合管理部门、计算中心等相关部门从事信息管理与信息系统的建设、运营等管理工作。 工商管理类 企业管理：各类工商企业、银行、证券公司等金融机构，会计师事务所等中介机构，以及政府经济管理部门。从事管理以及教学、科研方面的工作。 市场营销：到企业、科研院所、高等院校等从事管理决策、营销管理、销售、公关、品牌传播、理论研究与教学，或者是实际操作与管理性工作。 会计学：主要到企事业单位及政府部门从事会计实务以及教学、科研方面的工作。 财务管理：在高等院校和科研机构从事学术研究，在工商企业、金融机构、政府与事业单位、中介机构从事财务管理、咨询服务及其他相关经济管理工作。 人力资源管理：到企业、事业单位及政府部门从事人力资源管理以及教学、科研方面工作。 旅游管理：主要到各级旅游行政管理部门、旅游企事业单位从事旅游管理、经营或研究工作。 就业前景观察
管理学中部分二级学科近几年就业情况比较理想，比如工商管理里面的市场营销、会计学、企业管理、财务管理、人力资源管理等专业就业情况一直不错。公共管理类专业的研究生早些年就业非常一般，大部分到高校任教或者从事理论研究，但在未来几年估计公务员及协会等事业单位的就业会成为一个亮点。 具体来讲，在未来几年内，其就业前景主要包括： (1)传统管理职位，有很大一部分职业经理人的成长最开始来自基层锻炼经验。虽然说很多企业(一部分外资企业除外)目前开出的待遇水平让人难以接受，但从长远来看，对我们的发展还是非常有帮助的。特别是那些有心又有条件上MBA的同学来说——研究生就业环境恶化，但是具有一定年限工作经验的MBA毕业生在人力市场还是很受欢迎，如质量管理、专业项目管理等； (2)人力资源管理职位，以前的大学是没有专门开设人力资源管理专业的，它只是工商管理专业的一门专业课。近几年来，人力资源管理人员的地位一直是水涨船高，在公司的人员配置、战略决策、发展规划等关键问题上都处于智囊团位置，比如人力资源总监、薪酬经理、招聘经理、培训经理等； (3)市场营销职位，从历年人才市场统计数据来看，市场营销职位的需求经久不衰。销售职位的供需两旺一直是职场的一道风景线，即使在不同行业，市场营销类职位也总是招聘的热门，比如营销总监、营销主管、管理培训生、销售培训生等。 (4)物流管理职位，北京奥运会和上海世博会推动了中国物流业的进一步发展，招贤绣球四处高挂。而且，国内企业对物流行业成本压缩的诉求也刺激了物流人才的需求。目前，市场对物流人才的需求量超过600余万，被列为我国12类紧缺人才之一。可以说，中国的物流业正处在蓄势待发的阶段，极具市场潜力，前景十分广阔。大家可以报考报关员考试，或者是跟单员资格认证等。 (5)公共管理职位，这主要是公务员以及协会、学校等事业单位提供的就业机会，这也是管理学专业研究生的一个去向。尤其是目前一些机构推动改革，实现工作人员的知识化、年轻化，相信这部分就业会很快成为一大亮点。 (6)咨询类职位，这部分涉及到人力资源、市场营销、企业管理、物流管理等多个层面，除MBA、EMBA外，硕士研究生到咨询公司就业的也是比较多的。中国本土的咨询业还处于一个初步发展时期，文都教育认为，在未来五年内，大多数大中型企业都会需要外脑的帮助，咨询人员的需求会进一步扩大，更多管理学专业方面的高级人才会进入这个就业领域。
Nginx文件服务器和虚拟主机的配置 https://www.doczj.com/doc/2a9755577.html,的配置文件: 1.游戏服务器： server { listen 80; server_name https://www.doczj.com/doc/2a9755577.html,; index index.html index.htm index.php; root /data/web/fc/game3w/releases1/public; location ~ .*\.php$ { include fcgi.conf; fastcgi_pass 127.0.0.1:10080; fastcgi_index index.php; expires off; } access_log /data/logs/https://www.doczj.com/doc/2a9755577.html,.log access; } 2.客户端的配置： server { listen 80; server_name https://www.doczj.com/doc/2a9755577.html,; index index.html index.htm index.php; root /data/web/fc/resource; charset utf-8; #expires 2h; location ~* .svn$ { return 404; } location ~ .*\.swf$ { expires 365d; } location ~ .*\.css$ { expires 365d; } location ~ .*\.xml$ { expires 365d;
} location ~ .*\.js$ { expires 365d; } location ~ .*\.jpg$ { expires 365d; } location ~ .*\.gif$ { expires 365d; } location ~ .*\.png$ { expires 365d; } location ~ .*\.mp3$ { expires 365d; } location ~ .*\.game$ { expires 365d; } location ~ .*\.lib$ { expires 365d; } access_log off; } 3.文件服务器的配置： server { listen 9000; server_name 192.168.26.8; location / { autoindex on; autoindex_exact_size off; autoindex_localtime on; index index.html index.htm index.php; root /data/server/trunk/bin/logs/; allow all; } }
管理的定义： 1泰勒的定义：管理是一门怎样建立目标,然后用最好的方法经过他人的努力来达到的艺术。2法约尔的定义：管理就是计划,组织,控制,指挥,协调。3西蒙的定义：管理就是决策。4马克斯韦伯定义：管理就是协调活动。5美国管理协会的定义：管理是通过他人的努力来达到目标6本课程的定义：管理，就是通过计划、组织、领导和控制，协调以人为中心的组织资源与职能活动，以有效实现目标的社会活动。对管理定义的归纳 1强调作业过程：管理是计划、组织、领导、控制的过程；2强调管理的核心环节：管理就是决策；3强调对人的管理：管理就是通过其他人把事办好；4强调管理者个人作用：管理就是领导；5强调管理的本质：管理就是协调。 管理的属性 1管理二重性原理：管理既有自然属性，又有社会属性。2自然属性：同生产力相联系的管理的普遍性，是由生产力决定的。3社会属性：同生产关系相联系的管理的特殊性，是由生产关系决定的4管理的科学性：强调其客观规律性；5管理的艺术性：强调其灵活性与创造性。 管理者的定义 1关于管理者的传统观点：强调职位、职权、下属。2关于管理者的现代观点：强调对组织富有贡献的责任。3管理者的定义：管理者是指履行管理职能，对实现组织目标负有贡献责任的人。 管理者的分类
（1）按管理层次划分：高层管理者：决策层负责制定企业的现行政策，并计划未来的发展方向中层管理者：执行层执行企业组织政策，指挥一线管理人员或操作人员工作基层管理者：作业层一般只限于督导操作人员的工作，不会指挥其他管理人员 （2）按管理工作的性质与领域划分综合管理者；职能管理者。（3）按职权关系的性质划分直线管理人员；参谋人员。 管理者的素质：是指管理者的与管理相关的内在基本属性与质量。管理者的素质主要表现为品德、知识、能力与身心条件（管理者的技能，管理者的基本素质详情看书） 管理的环境：是指存在于社会组织内部与外部的影响管理实施和管理功效的各种力量、条件和因素的总和。2管理环境的分类：经济环境；技术环境；政治环境；社会与心理环境。一般环境与任务环境内部环境与外部环境管理与环境的关系：对应，交换，影响 管理的机制：是指管理系统的结构及其运行机理。2管理机制的特征：(1)客观性(2)自动性(3)可调性3管理机制的重要性：管理机制是决定管理功效的核心问题4管理机制以客观规律为依据。5管理机制以管理结构为基础和载体。一个组织的管理结构主要包括以下方面：(1)组织功能与目标；(2)组织的基本构成方式；(3)组织结构；(4)环境结构。分析内容：1有什么样的管理结构，就有什么样的管理机制。2有什么样的管理机制，就有什么样的管理行为，就有什么样的管理效果 1管理机制本质上是管理系统的内在联系、功能及运行原理。2类型：主要包括运行机制、动力机制和约束机制三个子机制。3运行机制的涵义。
1、管理过程之父法约尔法国1841-1925 西方古典管理理论在法国的最杰出代表亨利·法约尔（Henry Fayol）法国科学管理专家。管理学先驱之一 法约尔的管理功能理论认为管理功能包括计划、组织、命令、协调和控制。管理企业的六项基本活动是：技术、商业、财务、安全、会计和管理（核心）。管理不是专家或经理独有的特权和责任，而是企业全体成员（包括工人）的共同职责，只是职位越高，管理责任越大。他在实践基础上总结出14条管理原则，即分工、职权与职责、纪律、统一指挥、统一领导、公益高于私利、个人报酬、集中化、等级链、秩序、公正、保持人员的稳定、首创精神、集体精神。其主要内容包括：任何一个下属组织只应该接受一个上级的命令，这是组织统一行动，协调力量和一致努力的必要条件；从最高权力层直至低层管理人员应组成类似金字塔式的组织，使发出命令、解决争端和传递信息都经过法定的渠道；一个管理者能有效地直接领导、指挥和监督的下属人数的极限一般为12个；组织应自上而下地管理，最终的管理责任在上层，而不是将管理责任分散，甚至消失在下层；管理的权力和责任共存，责任是权力的自然结果和必不可少的对等物，责任下放了，权力也必须下放。法约尔的管理功能理论在欧洲有深远的影响，也曾为美国传统行政学派所接受。 2、彼得·德鲁克(Peter F．Drucker) （1909.11.19~2005.11.11)一生共著书39本，在《哈佛商业评论》发表文章30余篇，被誉为“现代管理学之父” 1954年，德鲁克提出了一个具有划时代意义的概念——目标管理(Management By Objectives，简称为MBO)，它是德鲁克所发明的最重要、最有影响的概念，并已成为当代管理学的重要组成部分。 目标管理的最大优点也许是它使得一位经理人能控制自己的成就。自我控制意味着更强的激励：一种要做得最好而不是敷衍了事的愿望。它意味着更高的成就目标和更广阔的眼界。目标管理的主要贡献之一就是它使得我们能用自我控制的管理来代替由别人统治的管理。 3、赫伯特·西蒙(Herbert·A·Simon，1916～?)美国管理学家和社会科学家 为决策贯彻管理的全过程，管理就是决策，组织就是决策，组织是由作为决策者的个人所组成的系统。综观其著作，除上述观点为组织方面的外，其余主要是发展了决策的科学方法体系。 4.哈罗德·孔茨（H．Koontz）；美国管理学家，管理过程学派的主要代表人物之一 孔茨利用这些管理职能对管理理论进行分析、研究和阐述，最终得以建立起管理过程学派。孔茨是管理过程学派的集大成者，他继承了法约尔的理论，并把法约尔的理论更加系统化、条理化，使管理过程学派成为管理各学派中最具有影响力的学派。 管理过程学派的主要特点是将管理理论同管理人员所执行的管理职能，也就是管理人员所从事的工作联系起来。他们认为，无论组织的性质多么不同(如经济组织、政府组织、宗教组织和军事组织等)，组织所处的环境有多么不同，但管理人员所从事的管理职能却是相同的，管理活动的过程就是管理的职能逐步展开和实现的过程。因此，管理过程学派把管理的职能作为研究的对象，他们先把管理的工作划分为若干职能，然后对这些职能进行研究，阐明每项职能的性质、特点和重要性，论述实现这些职能的原则和方法。管理过程学派认为，应用这种方法就可以把管理工作的主要方面加以理论概括并有助于建立起系统的管理理论，用以指导管理的实践。 5、亚当·斯密（1723～1790）是经济学的主要创立者。 6、泰罗（Frederick Winslow Taylor）（1856-1915）是美国古典管理学家，科学管理理论的主要倡导者，被后人尊称为“科学管理之父”。科学管理原理》是他的代表作，较为全
Nginx系列 一信号与配置 一、Nginx与信号 Nginx支持平滑重启，相比于Apache，修改了配置文件后可以不需要先停止程序，再重新启动。 1、启动 nginx –c nginx.conf 其中，-c nginx.conf可以省略不写。如果省略，则默认加载安装目录下的conf子目录中的nginx.conf。 2、停止 停止的方式有很多种，kill时传入不同的信号来结束或者平滑重启。Nginx的进程号记录在Pid文件中，Pid文件的位置可以在conf/nginx.conf中找到。如下图： 当然，也可以根据 ps –ef | grep nginx 来查找Nginx的进程号。我们可以通过kill命令来结束Nginx。 从容停止Nginx： kill –QUIT Nginx进程ID 或 kill – QUIT /usr/local/nginx/logs/nginx.pid 快速停止Nginx： kill –TERM Nginx进程ID 或
kill – TERM /usr/local/nginx/logs/nginx.pid 或 kill –INT Nginx进程ID 或 kill – INT /usr/local/nginx/logs/nginx.pid 强制停止Nginx： kill –9 Nginx进程ID 或 kill -9 /usr/local/nginx/logs/nginx.pid 或 pkill -9 nginx 3、重启 如果修改了Nginx的配置文件，想要重启Nginx。同样可以使用kill命令来传递信号。不过，在此之前，我强烈建议先检查并测试配置文件是否正确。 测试配置文件： nginx –t –c conf/nginx.conf 若提示unknow directive *** in conf/nginx.conf:55. Configuration file conf/nginx.conf test failed，则证明在第55行的***是非法的，需要修改。 若提示the configuration file conf/nginx.conf syntax is ok. Configuration file conf/nginx.conf test is successful，则证明配置文件测试通过，可以重启Nginx了。 平滑重启Nginx： kill –HUP Nginx进程ID 或
【管理学原理】 计划、组织、领导、控制 2、4、6、8章是重点，尤其第4章，要花本科80％时间复习，1、 3、5、7章非重点 第一章管理的历史发展 ?古典管理理论，近代管理的发展★ ?巴纳德的一般组织管理原理 1、组 织论的管理论 理论结构：个人假设-〉协作行为和协作系统理论-〉组织理论-〉管理理论 2、正 式组织与非正式组织 正式组织：两个或两个以上个人的有意识协调的行为或力的系统，包含三要素。 正式组织三要素：协作意愿、共同目标、信息沟通
组织是正式组织和非正式组织的统一。 3、组 织平衡： 是组织与管理之间的联结环节，包括： ①组织内部个人和整体的平衡，②组织与环境之间的平衡③组织动态平衡（第十章） 4、管 理人员的职能 ①建立和维持一个信息联系的系统；②从组织成员那里获得必要的努力； ③规定组织的共同目标；④领会组织整体把握管理艺术。 ?当代管理理论主要流派 ①管理过程流派，②管理科学流派③组织管理流派 ④行为科学流派⑤经验管理流派⑥其他学说和流派 ?组织管理流派 ?行为科学流派、经验管理流派可能出选择题 ?管理学发展的显著线索 A.科学化理性化线索 B.人道主义线索 C.管理过程线索 D.实证分析线索 第二章组织管理原理★ ?个体行为的假设★（多选） A.经济人假设 B.社会人假设 C.管理人假设 D.复杂人 ?组织生活中个体的两个最基本的特征 A.行为：决策决定方向，心理力量决定强度；
目标、知识、思维方式制约决策，情感影响心理力量； B.学习 ?『心理能量』★ 或心理力量是促使人意识到自己的需求和主体性，驱使人采取适当行为的心理力量。 ?学习和心理能量的相互作用★（简答或论述） 心理能量定义； 学习和心理能令是一种相互促进的关系，二者有较强的相关性。一方面心理能量对学习 的促进作用要适度，另一方面不同的学习需要不同的心理能量。 组织中学习与心理能量的相互作用有两条： 1、个 体层次轨迹：学习-情报蓄集-成功-能量改变 2、集 体层面：学习-情报共有-相互激励-能量集团 ?『正式组织』 是两个或两个以上个人的有意识地加以协调的行为或力的系统。 ?正式组织三个基本要素★ A.协作意愿 B.共同目标 C.信息沟通 ?『非正式组织』 是两个或两个以上个人的无意识地体系化、类型化了的多种心理因素的系统 ?非正式组织的特征（多选） 1、无明确结构 2、本质在于人与人间的协调 3、侧重于相互接触的心理因素、非理性因素 4、通行的是无形的潜移默化的影响，个人品格往往是导向因素。 ?非正式组织与正式组织的关系★（论述）
#user nobody; worker_processes auto; #error_log logs/error.log; error_log logs/error.log notice; #error_log logs/error.log info; #pid logs/nginx.pid; worker_rlimit_nofile 100000; events { use epoll; worker_connections 204800; } http { ## 用户的IP 地址$binary_remote_addr 作为Key，每个IP 地址最多有50 个并发连接 ## 你想开几千个连接刷死我？超过50 个连接，直接返回503 错误给你，根本不处理你的请求了 limit_conn_zone $binary_remote_addr zone=TotalConnLimitZone:10m ; #limit_conn TotalConnLimitZone 50; limit_conn TotalConnLimitZone 500; limit_conn_log_level notice; ## 用户的IP 地址$binary_remote_addr 作为Key，每个IP 地址每分钟处理50 个请求## 你想用程序每秒几百次的刷我，没戏，再快了就不处理了，直接返回503 错误给你 #limit_req_zone $binary_remote_addr zone=ConnLimitZone:10m rate=200r/m; limit_req_zone $binary_remote_addr zone=ConnLimitZone:10m rate=2000r/m; limit_req_log_level notice; #include mime.types; #default_type application/octet-stream; #access_log logs/access.log main; #server_tokens off; #sendfile on; #tcp_nopush on; #keepalive_timeout 0; #keepalive_timeout 65; server_tokens off; include mime.types; default_type application/octet-stream; log_format main '$remote_addr - $remote_user [$time_local] $request ' '"$status" $body_bytes_sent "$http_referer" '