rfc5594.Report from the IETF Workshop on Peer-to-Peer (P2P) Infrastructure, May 28, 2008
Network Working Group J. Peterson Request for Comments: 5594 NeuStar Category: Informational A. Cooper Center for Democracy & Technology July 2009 Report from the IETF Workshop on Peer-to-Peer (P2P) Infrastructure,
May 28, 2008
Abstract
This document reports the outcome of a workshop organized by the
Real-time Applications and Infrastructure Area Directors of the IETF to discuss network delay and congestion issues resulting from
increased Peer-to-Peer (P2P) traffic volumes. The workshop was held on May 28, 2008 at MIT in Cambridge, MA, USA. The goals of the
workshop were twofold: to understand the technical problems that ISPs and end users are experiencing as a result of high volumes of P2P
traffic, and to begin to understand how the IETF may be helpful in
addressing these problems. Gaining an understanding of where in the IETF this work might be pursued and how to extract feasible work
items were highlighted as important tasks in pursuit of the latter
goal. The workshop was very well attended and produced several work items that have since been taken up by members of the IETF community. Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (https://www.wendangku.net/doc/2913277251.html,/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
Peterson & Cooper Informational [Page 1]
Table of Contents
1. Introduction (3)
2. Scoping of the Problem and Solution Spaces (4)
3. Service Provider Perspective (4)
3.1. DOCSIS Architecture and Upstream Contention (4)
3.2. TCP Flow Fairness and Service Flows (5)
3.3. Service Provider Responses (6)
4. Application Provider Perspective (7)
5. Potential Solution Areas (7)
5.1. Improving Peer Selection: Information Sharing,
Localization, and Caches (8)
5.1.1. Leveraging AS Numbers (9)
5.1.2. P4P: Provider Portal for P2P Applications (9)
5.1.3. Multi-Layer, Tracker-Based Architecture (10)
5.1.4. ISP-Aided Neighbor Selection (11)
5.1.5. Caches (12)
5.1.6. Potential IETF Work (12)
5.2. New Approaches to Congestion Control (14)
5.2.1. End-to-End Congestion Control (15)
5.2.2. Weighted Congestion Control (15)
5.3. Quality of Service (16)
6. Applications Opening Multiple TCP Connections (17)
7. Costs and Congestion (18)
8. Next Steps (18)
8.1. Transport Issues (19)
8.2. Improved Peer Selection (19)
9. Security Considerations (19)
10. Acknowledgements (19)
11. Informative References (20)
Appendix A. Program Committee (21)
Appendix B. Workshop Participants (21)
Appendix C. Workshop Agenda (24)
Appendix D. Slides and Position Papers (25)
Peterson & Cooper Informational [Page 2]
1. Introduction
Increasingly, large ISPs are encountering issues with P2P traffic.
The transfer of static, delay-tolerant data between nodes on the
Internet is a well-understood problem, but traditional management of fairness at the transport level is under strain from applications
designed to achieve the best end-user transfer rates. At peak times, this results in networks running near absolute capacity, causing all traffic to incur delays; the applications that bear the brunt of this additional latency are real-time applications like Voice over IP
(VoIP) and Internet gaming. To explore how IETF standards work could be useful in addressing these issues, the Real-time Applications and Infrastructure area directors organized a "P2P Infrastructure"
workshop and invited contributions from subject matter experts in the problem and solution spaces.
The goals of the workshop were twofold: to understand the technical
problems that ISPs and end users are experiencing as a result of high volumes of P2P traffic, and to begin to understand how the IETF may
be helpful in addressing these problems. Gaining an understanding of where in the IETF this work might be pursued and how to extract
feasible work items were highlighted as important tasks in pursuit of the latter goal. The workshop’s focus was on engineering solutions
that promise some imminent benefit to the Internet as a whole, as
opposed to longer-term research or closed proprietary solutions.
While public policy must inform work in this space, crafting or
debating public policy was outside the scope of the workshop.
Position papers were solicited in the weeks prior to the workshop,
and a limited number of speakers were invited to present their views at the workshop based on these submissions. This report is a summary of all participants’ contributions. The program committee and
participant list are attached in Appendices A and B, respectively.
The agenda of the workshop can be found in Appendix C. A link to the presentations given at the workshop and the position papers submitted prior to the workshop is in Appendix D.
The workshop showcased the IETF community’s recognition of the impact of P2P and other high-volume applications on the Internet as a whole. Participants welcomed the opportunity to discuss potential
standardization work that network operators, applications providers, and end users would all find mutually beneficial. Two transport-
related work items gained significant traction: designing a protocol for very deferential end-to-end congestion control for delay-tolerant applications, and producing an informational document about the
reasoning behind and effects of applications opening multiple
transport connections at once. A separate area of interest that
emerged at the workshop focused on improving peer selection by having Peterson & Cooper Informational [Page 3]
networks make more information available to applications. Finally,
presenters also covered traditional approaches to multiple service-
tier queuing such as Diffserv.
2. Scoping of the Problem and Solution Spaces
The genesis for the Peer-to-Peer Infrastructure (P2PI) workshop grew in large part out of specific pain points that ISPs are experiencing as a result of high volumes of P2P traffic. However, several
workshop participants felt that the IETF should approach a more
general space of problems, of which P2P-related congestion may be
merely one instance.
For example, high-volume applications besides P2P, whether they
already exist or have yet to be developed, could cause congestion
issues similar to those caused by P2P. The general class of
congestion problems attributable to always-on, high-volume
applications require the development of solutions that are reasonable for operators, applications, and subscribers. And while much
attention has been paid to congestion on access links, increased
traffic volumes could impact other parts of the network. Although
the workshop focused primarily on the specific causes and effects of current P2P traffic volumes, it will likely be useful in the future
for the IETF to consider how to pursue solutions to these larger
problems.
Obtaining more data about Internet congestion may also be a helpful
step before the IETF pursues solutions. This data collection could
focus on where in the network congestion is occurring, its duration
and frequency, its effects, and its root causes. Although individual service providers expressed interest in sharing congestion data,
strategies for reliably and regularly obtaining and disseminating
such data on a broad scale remain elusive.
3. Service Provider Perspective
To help participants gain a fuller understanding of one specific
network operator’s view of P2P-induced congestion, Jason Livingood
and Rich Woundy provided an overview of Comcast’s network and
approach to management of P2P traffic.
3.1. DOCSIS Architecture and Upstream Contention
In the Data Over Cable Service Interface Specification (DOCSIS)
architecture [DOCSIS] that is used for many cable systems, there may be a single Cable Modem Termination System (CMTS) serving hundreds or thousands of residential cable customers. Each CMTS has multiple Peterson & Cooper Informational [Page 4]
DOCSIS domains, each of which typically has a single downstream link and a number of upstream links. Each CMTS is connected through a
hybrid fiber-coaxial (HFC) network to subscribers’ cable modems.
The limiting resource in this architecture is usually bandwidth, so
bandwidth is typically the measure used for capacity planning. As
with all networks, congestion manifests itself when instantaneous
load exceeds available capacity.
In the upstream direction, any cable modem connected to a CMTS can
make a request to the CMTS to transmit, and requests are randomized
to minimize collisions. With many cable modems issuing requests at
once, the requests may collide, resulting in delays. DOCSIS does not specify a size for cable modem buffers, but buffer delays of one to
four seconds have been observed with various cable modems from
different vendors.
Once the CMTS has granted a cable modem the ability to transmit its
data PDU, the modem can piggyback its next request on top of that
data PDU. In situations with a lot of upstream traffic, piggybacking happens more often, which sends heavy upstream users to the front of the CMTS queue, ahead of interactive but less-upstream-intensive
applications. For example, if the CMTS is granting requests
approximately every one to three milliseconds, then a cable modem
transmitting data for a service like VoIP with a packetization delay of 20-30 milliseconds may get into contention with another modem on
the same CMTS that is constantly transmitting upstream and
piggybacking each new request. This may explain how heavy upstream
users ultimately dominate the pipe over more interactive
applications. Consequentially, it is imperative that assessments of the problem space and potential solutions are mindful of the
influence that specific layer-2 networks may exert on the behavior of Internet traffic, especially when considering the alleviation of
congestion in an access network.
3.2. TCP Flow Fairness and Service Flows
How TCP flow fairness applies to upstream requests to the CMTS is an open question. A CMTS sees many service flows, each of which could
be a single TCP flow or many TCP flows (or UDP). The CMTS is not
aware of the source or destination IP address of a packet until it
has already been transmitted upstream, so those cannot be used to
impose flow fairness.
A particular cable modem can have multiple service flows defined.
For example, a modem that is also a VoIP endpoint can provision a
service flow for VoIP that would allow VoIP traffic to avoid the
upstream request process to the CMTS (and thereby avoid contention Peterson & Cooper Informational [Page 5]
with other modems). The service flow would have upstream capacity
provisioned for it. The modem would have a separate service flow for best efforts traffic. Some ISPs provision such a flow for their own VoIP offerings; others allow subscribers to pay extra to have
particular traffic assigned to a provisioned service flow.
It may also be possible for an ISP to provision such a flow on the
fly when it recognizes the need for it. Diffserv [RFC2475] bits set by the customer premises equipment could be used to classify flows,
for example.
3.3. Service Provider Responses
In 2005, ISP customers began increasingly complaining about the
performance of delay-sensitive traffic (VoIP and gaming), due in part to the issues arising out of the DOCSIS architecture as described
above. At the same time, ISPs were seeing heavy growth in P2P
traffic and an increasing correlation between high levels of P2P
activity and packet loss.
In responding to this situation, cable ISPs have several avenues to
pursue. The newest generation of the DOCSIS specification, DOCSIS
3.0, enables faster transfer rates than most cable systems currently support. While the rollout of DOCSIS 3.0 will provide additional
capacity, it will likely not obviate the need for congestion
management in an environment where client software is designed to
maximize bandwidth consumption regardless of available capacity.
Congestion management can take many forms; Jason and Rich explained
the new protocol-agnostic approach that Comcast is currently
trialing. Prior to these trials, all traffic was marked as "best
efforts". During the trials, all traffic is re-classified as
"priority". When a CMTS is approaching peak congestion on a
particular upstream or downstream port (the "Near Congestion State"), some subscribers will have traffic re-classified as "best efforts".
Both the threshold for determining when a CMTS port is in Near
Congestion State and the number of minutes it remains in this state
are parameters being explored during the trials. To re-classify
upstream traffic, a new default DOCSIS service flow is used that has the same provisioned bandwidth as the "priority" stream but that is
treated with lower priority.
The subscribers whose traffic is re-marked will be selected by
determining whether they have temporarily entered a "Long Duration
Bulk Consumption State". This state is achieved by consuming a
certain amount of bandwidth over a certain period of minutes (both
are tweakable parameters being explored during the trials). These
thresholds will depend on the subscriber’s service tier --
Peterson & Cooper Informational [Page 6]
subscribers who pay for more bandwidth will have higher thresholds.
The re-marking will not distinguish between multiple users of the
same subscriber connection, so one family member’s P2P usage could
cause another family member’s Web browsing traffic to be lowered in
priority. There is no current mechanism for users to determine that their traffic has been re-marked.
By temporarily reducing the traffic priority of subscribers who have been consuming bandwidth in bulk for lengthy periods, this congestion management technique aims to preserve a good user experience for
subscribers with burstier traffic patterns, including those using
real-time applications. As compared to an approach that reduces
particular subscribers’ bandwidth during periods of congestion, this technique eliminates the ability for applications to set their own
priority levels, but it also avoids the negative connotations that
some users may associate with bandwidth reductions.
This approach involves many tweakable parameters. A large part of
the trial process is aimed at determining the best settings for these parameters, but there may also be opportunities to work with the
research community to identify the best way to adjust the thresholds necessary to optimize the performance of the management technique.
4. Application Provider Perspective
Stanislav Shalunov provided an overview of BitTorrent’s view of the
impact of increased P2P traffic volumes and potential mitigations.
The impact is described here; his proposed solutions (comprising the bulk of his talk) are addressed in the appropriate subsections of
Section 5.
As uptake in P2P usage has grown, so has end-user latency. For
example, a user whose uplink capacity is 250-500 Kbps and whose modem buffer has a capacity of 32-64 Kbps may easily fill the buffer
(unless the modem uses Adaptive Queue Management (AQM), which is
uncommon). This can result in delay on the order of seconds, with
disastrous effects on application performance. On a cable system
with shared capacity between neighbors, one neighbor could saturate
the buffer and affect the latency of another neighbor’s traffic.
Even users with dedicated bandwidth can experience delays as their
own P2P traffic saturates the link and dominates their own more
latency-sensitive traffic.
5. Potential Solution Areas
The submissions received in advance of the workshop covered a broad
array of work addressing specific aspects of P2P traffic volume and
other related issues. Solution suggestions generally fell into one Peterson & Cooper Informational [Page 7]
or more of three topic areas: improving peer selection, new
approaches to congestion control, and quality-of-service mechanisms. The workshop discussions and outcomes in each area are described
below.
5.1. Improving Peer Selection: Information Sharing, Localization, and
Caches
Peer selection is an integral factor in determining the efficiency of P2P networks from both the ISP and the P2P client points of view.
How peers are selected will determine both network load and client
performance.
The way that P2P clients select peers today varies from protocol to
protocol and client to client but, in general, peers are largely
oblivious to routing-level and network-topology information. This
results in P2P topologies that are agnostic of underlay topologies
and constraints.
Approaches to closing this gap generally involve an entity that has
knowledge of network topology, costs, or constraints (e.g., an ISP)
making some of this information available to P2P clients or trackers. This information may be used to localize traffic based on some metric of locality or to otherwise alter peer-selection decisions based on
the provided network information (hereafter referred to simply as
"localization"). One special case of this kind of approach would
help peers find caches containing the content they seek.
Any alteration to current peer-selection algorithms will have
engineering trade-offs. BitTorrent, for example, used randomized
peer selection by design. Choosing peers randomly out of a large
selection helps to average out problems among peers and allows for
connections to good peers that may be far away. Randomized peer
selection also supports "rarest first" piece selection, which allows swarms to continue even when the original seed disappears and which
distributes pieces so that more peers are likely to have pieces of
interest to other peers. Any move away from randomized selection
would have to take these factors into account.
Although localization has the potential to improve peer selection,
the incentives for both parties to the information exchange are
complex. ISPs may want to move traffic off of their own networks,
which could motivate them to provide information to peers that has
the opposite effect of what the peers would expect. Likewise, peers will want the use of the information they receive to result in
performance improvements; otherwise, they have no incentive to
consult with the network before selecting peers. Even when both
parties find the information sharing to be beneficial, user
Peterson & Cooper Informational [Page 8]
experiences will not necessarily be uniform depending on the scope of the information provided and the peer’s location. Localization
information could form one component of a peer-selection decision,
but it will likely need to be balanced against other factors.
Workshop participants discussed both current research efforts in this area and how IETF standards work may be useful in furthering the
general concept of improved peer selection. Those discussions are
summarized below.
5.1.1. Leveraging AS Numbers
One simple way to potentially make peer selection more efficient
would be for a peer to prefer peers within its own Autonomous System (AS). Transfers between peers within the same AS may be faster on
some networks, although more data is needed to determine the extent
of the potential improvement. On mobile networks, for example, the
utility of AS numbers is limited since they do not correlate to
geographic location. Peers may also see improvements by connecting
to other peers within a specific set of ASes or IP prefixes provided by their ISPs. Some ISPs may have an incentive to expose this
granularity of information because it will potentially reduce their
transit costs.
A case study was conducted with the four most popular BitTorrent
torrents to determine what the effect of localizing to an AS might
be. The swarm sizes for the torrents were 9984, 3944, 2561, and
2023, with the size distributions appearing to be polynomial. With
more than 20 peers in a single AS, peers within an AS could trade
only with each other, avoiding interdomain traffic. More than half
(57%) of peers in the four swarms were in ASes like this. Thus, in
these cases connecting to peers within an AS could reduce transit
traffic by at least 57%. If the ASes have asymmetric upload and
download links, however, the resulting user experience may
deteriorate since each peer’s download speed would be limited by
slower upload speeds.
With the largest swarm size at 9984, the probability of two peers
being in the same neighborhood is too low to make localization to the neighborhood level worthwhile. Attempting a simple localization
scheme, such as the AS localization described above, and determining its effectiveness likely makes more sense as a first step.
5.1.2. P4P: Provider Portal for P2P Applications
The Provider Portal for P2P Applications (P4P) project [P4P] aims to design a framework to enable cooperation between providers and
applications (including P2P), where "providers" may be ISPs, content Peterson & Cooper Informational [Page 9]
distribution networks, or caching services. In this architecture,
each provider can communicate information to P2P clients through a
portal known as an iTracker. An iTracker could be identified through a DNS SRV record (perhaps with its own new record type), a whois
look-up, or a trusted third party.
An iTracker has different interfaces for different types of
information that the provider may want to share. The core interface allows the provider to express the "virtual cost" of its intradomain or interdomain links. Virtual cost may reflect any kind of provider preferences and may be based on the provider’s choice of metrics,
including utilization, transit costs, or geography. It is up to the provider to decide how dynamic it wants to be in updating its virtual cost determinations.
In tests of this framework, two parallel swarms were created with
approximately the same number of clients and similar geographical and network distributions, both sharing the same file. One of the swarms used the P4P framework, with the ISP’s network topology map as input to its iTracker, and the other swarm used traditional peer selection. The swarm without P4P saw 98% of traffic to and from peers external
to the ISP, whereas with P4P that number was 50%. Download
completion times for the P4P-enabled swarm improved approximately 20% on average.
5.1.3. Multi-Layer, Tracker-Based Architecture
The multi-layer, tracker-based P2P scheme described at the workshop
is a generic example of an architecture that demonstrates how
localization may be useful in principle.
In a traditional, tracker-based P2P system, trackers provide clients with information about seeds and peers where clients can find the
content they seek. A multi-layered tracker architecture incorporates additional "local" trackers that provide the same information, but
only for content located within their own local network scope.
Client queries are re-directed from the global tracker to the
appropriate local trackers. Local trackers may also exist on
multiple levels, in which case queries would be further re-directed. This sort of architecture could also serve hybrid P2P/content
delivery networks, where the global tracker functions as both a
tracker and a content server, and local trackers track locally
provisioned caches in addition to seeds and peers.
Peterson & Cooper Informational [Page 10]
One challenge in this architecture is determining what "local" means for trackers, seeds, and peers. Locality could be dependent on
traffic conditions, load balancing, static topology, policy, or some other metric. These same considerations would also be crucial for
determining appropriate cache placement in a hybrid network.
This architecture presents in the abstract the problem of re-
directing from a global entity to a local entity. Client queries
need to find their way to the appropriate local tracker. This can be accomplished through an off-path, explicit mechanism where local
trackers register with the global tracker in advance, or through an
on-path approach where the network proxies P2P requests. The off-
path tracker format approach is preferable for performance and
reliability reasons.
Inasmuch as the multi-layer scheme might require ISPs to aid peers in finding optimal paths to unauthorized copies of copyrighted content, ISPs may be concerned about the legal liability of participating.
5.1.4. ISP-Aided Neighbor Selection
ISPs have a lot of knowledge about their networks: everything from
the bandwidth, geography, and service class of particular nodes to
overarching routing policies, OSPF and BGP metrics, and distances to peering points. The ISP-aided neighbor selection service described
below seeks to leverage this knowledge without requiring ISPs to
reveal any information that could not already be discerned through
reverse-engineering by client applications.
The service consists of an "oracle" hosted by an ISP. The oracle
receives a list of IP addresses from a network node, sorts the list
according to its own confidential criteria, and returns the sorted
list to the node. The peer ranking provided by the oracle could be
viewed as a special case of the virtual cost interface described in
the previous section.
This service could be used by P2P clients or trackers, or by any
other application that would benefit from learning its ISP’s
connection preferences. The oracle could be run as a web server or
UDP service at a known location (perhaps similar to BIND).
For interdomain ranking, an ISP could rank its own peers first, or it could base its ranking on the AS number of the IPs in the provided
list. Another option would be for multiple ISPs to work together to have their oracles exchange lists with each other.
Peterson & Cooper Informational [Page 11]
The main challenge in implementing the oracle service is scalability. If peers need to communicate to the oracle the IP address of every
peer they know, the size of oracle requests may be inordinately
large. Additionally, today’s largest swarms approach 10000 peers,
and with every peer requesting a sorted list, the oracle request
volume will swell. With the growth of business models dependent upon P2P for distribution of content, swarms in the future may be far
larger, further exacerbating the problem. Potential mitigations
include having trackers, instead of peers, issue oracle requests, and using other peers’ sorted lists as input, rather than always using an unsorted list.
On the other hand, this approach is advantageous from a legal
liability perspective, because it does not require ISPs to have any
knowledge of where particular content might be located or to have any role in directing peers to particular content.
5.1.5. Caches
Deploying caches as peers in P2P networks was suggested as a
component of multiple proposals put forth at the workshop. Caches
may help to ease network load by reducing the need for peers to
upload to each other and by localizing traffic.
The two main concerns about P2P caches relate to network capacity and legal liability. For caches to be useful, they will likely need to
be large (one suggestion was that a 1 TB cache could service 30% of
requests within a single AS, and a 100 TB cache could service 80% of requests). Large caches will require sizable bandwidth in order to
avoid contention among peers. Caches would not be usefully placed
within an HFC network on a cable system, for example.
The legal liability attached to hosting a P2P cache likely reduces
the incentives to do so. Even under legal regimes where liability
for caching may be unclear, ISPs and others may view hosting a cache as too great of a legal risk to be worthwhile.
5.1.
6. Potential IETF Work
Much of the localization work discussed at the workshop is still in
its initial stages, and many questions remain about the value that
localization provides for varying network and overlay architectures. More data is needed to evaluate the effects on both traffic load and client performance. Understanding swarm distributions is important; swarms with long tails may not particularly benefit from
localization.
Peterson & Cooper Informational [Page 12]
Against this backdrop, the key task for the IETF (as identified at
the workshop) is to pinpoint incrementally beneficial work items in
the spaces discussed above. In the future, it may be possible to
standardize entire P2P mechanisms but, as a starting point, it makes more sense to single out core manageable components for
standardization. The focus should be on items that are not so
specific to one ISP or P2P network that standardization is rendered
useless. Ideally, any mechanisms resulting from this work might
apply to future applications that exhibit the same bandwidth-
intensive properties as today’s P2P file-sharing.
In considering any of these items, it will be necessary to ensure
that the information exchanged by networks and applications does not harm any of the parties involved. Not every piece of information
exchanged will be beneficial or verifiable, and this fact must be
recognized and accounted for. Solutions that leave applications or
networks worse off than they already are today will not gain any
traction.
It should also not be assumed that a particular party will be best
suited to provide a particular kind of information. For example, an ISP may not know what the connection costs are in other ISPs’
networks, whereas an overlay network that receives cost information
from several ISPs may have a better handle on this kind of data.
Standardization of information sharing should not assume the identity of particular parties doing the sharing.
The list of potential work items discussed at the workshop is
provided below. Workshop participants showed particular interest in pursuing the first three items further.
5.1.
6.1. AS Numbers
P2P clients are currently reliant on IP-to-AS mapping tables when
they want to determine AS numbers. Providing a standard, easier way for clients to obtain this information may help to make peer
selection more efficient on certain networks.
5.1.
6.2. Querying for Preferred Peers
In situations where a peer or tracker can make requests in real time to a service that expresses its ISP’s peering preferences,
standardizing a format for requests and responses may be useful. The focus would be on the communication of the information, not on the
criteria used to decide preferences. The information provided to
peers would have to be crafted to ensure that it protects the privacy of other peers and safeguards proprietary network information. Peterson & Cooper Informational [Page 13]
5.1.
6.3. Local Tracker, iTracker, Oracle, or Cache Discovery
With the deployment of trackers, iTrackers, oracles, or other
mechanisms that provide some information specific to a node’s
locality, nodes will need a way to find these resources. One task
for the IETF could be to explore a way to do discovery, potentially
by leveraging an existing discovery protocol (DNS, DHCP, anycast,
etc.). Depending on the resource to be discovered, discovery may
require only a simple look-up, or it may require a more complex
determination of which resource is "closest" to the node issuing the request.
5.1.
6.4. ISP Account Usage Information
Where ISP subscribers are bound by network usage policies or volume- based quotas, it may be useful to have a standard way of
communicating the subscriber’s current usage status. This would be
similar to information about how many minutes of cell phone airtime
are left in a subscriber’s billing cycle. Applications could use
this information to make decisions about when and how to transfer
data. One challenge in implementing such a standard would be support for potentially limitless different ISP business models. The level
of granularity that an ISP is able to provide may also be constrained depending on the pricing model and how dynamic the information is
expected to be.
5.1.
6.5. Tracker Formats
A multi-layered tracker approach could potentially be aided by a
standard tracker format for re-directing from a global tracker to a
local tracker. While the extent to which existing trackers will be
willing to consult with other trackers is unclear, the re-direction
format may have an analog in another context -- many HTTP servers
build their own indexes of mirror information for a similar purpose, though these are not standardized. If the two problem spaces prove
to be similar enough, there may be room to standardize a format
across both.
5.2. New Approaches to Congestion Control
One recent informal survey presented at the workshop found that ISPs perceive traffic volumes from heavy users to be a problem, but no
single congestion management tool has been put to wide use. Within
developer and research communities, congestion issues raised by
increased P2P traffic volumes have spurred new thinking about
congestion-control mechanisms at both the transport layer and the
application layer. The subsections below explore some of these new
ideas and highlight areas where IETF work may be appropriate.
Peterson & Cooper Informational [Page 14]
5.2.1. End-to-End Congestion Control
As noted previously, uptake in P2P usage can result in perceptible
end-user latency on the order of seconds for interactive
applications. One approach to resolving this "round-trip time (RTT) in seconds" problem would be for P2P clients to implement better
congestion control that keeps the bottleneck full while yielding to
keep the delay of competing traffic low. Such an algorithm has been implemented in BitTorrent’s client by continuously sampling one-way
delay (separating propagation from queuing delay) and targeting a
small queuing delay value. This essentially approximates a scavenger service class in an end-to-end congestion-control mechanism by
forcing bulk, elastic traffic to yield to competitors under
congestion.
In a similar vein, the P4P framework supports a component that allows applications to mark traffic as "bulk data" (not time sensitive).
Applications adjust their behavior according to the feedback they
receive from such markings.
Experimenting with the standardization of these kinds of techniques
or any congestion-control framework with design goals that differ
from those of TCP may be helpful work for the IETF to pursue.
5.2.2. Weighted Congestion Control
Congestion control has typically been implemented at a protocol level as an optional, cooperative effort between endpoints experiencing
congestion, but in looking for a long-term approach to congestion
control, we may need a more rigorous way for available bandwidth to
be allocated by and between the hosts using a network. The idea
behind weighted congestion control is to allow hosts to give more
weight to interactive applications during times of congestion.
Comparing such an approach with Diffserv showcases its strengths and weaknesses. Unlike Diffserv, weighted congestion control could be
implemented on hosts with a simple extension to socket APIs (although consensus among OSes would be necessary for portability). Through
weighted congestion control, control resides with the host, whereas
even when Diffserv APIs are available, it is difficult for a host to know that the network is complying with its classifications. With
weighted congestion control, hosts need some disincentive to setting their weights at maximum levels, whereas Diffserv was not designed
for individual users to employ. Both approaches must rely on traffic senders to set policies, meaning that the congestion issues stemming from P2P use on the receiver side are not aided by either mechanism. Peterson & Cooper Informational [Page 15]
With Diffserv, a light user may waste his or her priority connecting to a heavy user on another network, which is not a problem with host- controlled weighting.
Weighted congestion control is just one example of a generalized set of features that characterize useful approaches to congestion
control. These characteristics include full user control of
priorities within a user’s own scope and no possibility of
interpreting ISP behavior as discriminatory. The former means that
ISPs should not override user decisions arbitrarily (though this does not preclude an ISP from offering prioritization as an option). The latter means that the metric for decision-making needs to obviate
suspicion of ISP motivations.
One metric that meets these criteria is a harm (cost) metric, where
cost is equal to the amount of data that was not served to its
destination. Using this metric, cost is greatest when traffic peaks are greatest. It allows for a policy of not sending too much data
during times of congestion, without specifying exactly how much is
too much. The cost metric could be used either for a Diffserv
approach or for weighted congestion control.
One important limitation on ISPs from a congestion-control
perspective is that they do not have a window into congestion on
other ISPs’ networks. Solving this problem requires a separate
mechanism to express congestion across domains.
One potential avenue for the IETF or IRTF to pursue would be to
establish a long-term design team to assess congestion problems in
general and the long-term effects of any proposed quick fixes. These issues are not necessarily confined to P2P and should be viewed in
the broader context of massive increases in bandwidth use.
5.3. Quality of Service
Although ISPs have implemented a wide variety of short-term
approaches to dealing with congestion, several of these may not be
viable in the long term. For example, some ISPs have found that
using deep packet inspection to change the delivery characteristics
of certain traffic at times of congestion is more cost effective than adding additional bandwidth. Over time, this approach could lead to a cat-and-mouse game where applications providers continually adapt
to avoid being correctly classified by Deep Packet Inspection (DPI)
equipment. Similarly, ISPs implementing traffic analysis to identify P2P traffic may find that, in the long run, the overhead required of an effective classification scheme will be excessive.
Peterson & Cooper Informational [Page 16]
Quality of service (QoS) arrangements may be more suitable in the
long term. One approach that distinguishes certain classes of
traffic during times of congestion was described in Section 3.3. A
standardized mechanism that may be useful for implementing QoS is
Differentiated Services Code Points (DSCP) [RFC2474].
With DSCP, devices at the edge of the network mark packets with the
service level they should receive. Nodes within the network do not
need to remember anything about service flows, and applications do
not need to request a particular service level. Users effectively
avoid self-interference through service classification.
Although DSCP may have many uses, perhaps the most relevant to the
P2P congestion issue is its ability to facilitate usage-based
charging. User pricing agreements that charge a premium for real-
time traffic and best-effort traffic could potentially shape user
behavior, resulting in reduced congestion (although ISPs would need a mechanism to mitigate the risk of charging subscribers for things
like unintentional malware downloads or DoS attacks). DSCP could
also be used to limit a user’s supply of high-priority bandwidth,
resulting in a similar effect.
Equipment to support DSCP is already available. Although there has
been some concern about a perceived lack of DSCP deployment, it is
widely used by enterprise customers, and growth has been strong due
to uptake in VoIP at the enterprise level.
However, DSCP still faces deployment hurdles on many networks.
Perhaps the largest barrier of all to wide deployment is the lack of uniform code points to be used across networks. For example, the
latest Windows Vista API marks voice traffic as CS7, above the
priority reserve for router traffic. To properly take advantage of
this change, every switch will need to re-mark all traffic. In
addition, disparate ISPs are currently without a means of verifying
each others’ markings and thus may be unwilling to trust the markings they receive.
6. Applications Opening Multiple TCP Connections
The workshop discussions about P2P congestion spurred a related
discussion about applications (P2P or otherwise) that open multiple
TCP connections. With multiple users sharing one link, TCP flow
fairness gives users with multiple open connections a larger
proportion of bandwidth. Since some P2P protocols use multiple open connections for a single file transfer and users often pursue
multiple transfers at once, this can cause a P2P user to have many
more open connections at once than other users on the same link. The same is true for users of other applications that open multiple Peterson & Cooper Informational [Page 17]
connections. A single user with multiple open connections is not
necessarily a problem on its face, but the fact that fairness is
determined per flow rather than per user leaves that impression.
Workshop participants thought it may be useful for the IETF to
provide some information about such situations.
7. Costs and Congestion
Workshop participants expressed diverging opinions about how much the cost of transferring data -- as experienced by ISPs and, by
extension, their subscribers -- should factor into IETF thinking on
P2P traffic issues.
On one hand, bandwidth costs may be significant, even when viewed in isolation from congestion issues. Some estimates put the total cost of shipping 1 GB between $0.10 and $2. The cost of transit bandwidth in markets where subscribers are charged flat rates appears to have
leveled off and may no longer be getting cheaper. Thus, it may be
reasonable to expect more service providers to move to volume-based
pricing (where they have not already done so) as a means to control
congestion and increase revenues. This is only feasible if bandwidth consumption is visible to end users, which argues for some mechanism of exposing quotas and usage to applications. However, expressing
cost information may be outside of the technical purview of the IETF. On the other hand, congestion can be viewed merely as a manifestation of cost. An ISP that invests in capacity could be considered to be
paying to relieve congestion. Or, if subscribers are charged for
congesting the network, then cost and congestion could be viewed as
one and the same. The distinction between them may thus be
artificial.
Workshop participants felt that the issues highlighted here may be
useful fodder for IRTF work.
8. Next Steps
The IETF community recognizes the significance of both increasing P2P traffic volumes and network load at large. The importance of
addressing the impact of high-volume, delay-tolerant data transfer on end-user experiences was highly apparent at the workshop.
At the conclusion of the workshop and in the days following, it
became clear that the largest areas of interest fell into two
categories: transport-related issues and improved peer selection. Peterson & Cooper Informational [Page 18]
8.1. Transport Issues
Two main transport-related work items evolved out of the workshop.
The first was the creation of a standardized, delay-based, end-to-end congestion-control mechanism that applications such as P2P clients
could use to reduce their own impact on interactive applications in
use on shared links (as described in Section 5.2.1). The second was an informational document that describes the current practice of P2P applications opening multiple transport connections and that makes
recommendations about the best practices for doing so (as discussed
in Section 6).
8.2. Improved Peer Selection
Participants expressed strong interest in further pursuing the range of concepts described in Section 5.1 that support mechanisms for
information sharing between networks and applications to help improve peer selection. Adding to the appeal of this topic is its potential utility for applications other than P2P that may also benefit from
information about the network. Because the scope of potential
solutions discussed at the workshop was broad, extracting out the
most feasible pieces to pursue is the necessary first step.
9. Security Considerations
The workshop discussions covered a range of potential engineering
activities, each with its own security considerations. For example, if networks are to provide preference or topology information to
applications, the applications may desire some means of verifying the authenticity of the information. As the IETF community begins to
pursue specific avenues arising out of this workshop, addressing
relevant security requirements will be crucial.
10. Acknowledgements
The IETF would like to thank MIT, which hosted the workshop, and all those people at MIT and elsewhere who assisted with the organization and logistics of the workshop.
The IETF is grateful to the program committee (listed in Appendix A) for their time and energy in organizing the workshop, reviewing the
position papers, and crafting an event of value for all participants. The IETF would also like to thank the scribes, Spencer Dawkins and
Alissa Cooper, who diligently recorded the proceedings during the
workshop.
Peterson & Cooper Informational [Page 19]
A special thanks to all the participants in the workshop (listed in
Appendix B) who took the time, came to the workshop to participate in the discussions, and put in the effort to make this workshop a
success. The IETF especially appreciates the effort of those that
prepared and made presentations at the workshop.
11. Informative References
[DOCSIS] CableLabs, "DOCSIS Specifications - DOCSIS 2.0 Interface", 2008, specifications20.html>. [P4P] Xie, H., Yang, Y., Krishnamurthy, A., and A. Silberschatz, "P4P: Provider Portal for Applications", August 2008, rc_parentID43281_thisID43282.pdf>. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. Peterson & Cooper Informational [Page 20] 控制软件说明书 PC端软件FTM 安装及应用 系统运行环境： 操作系统中英文Windows 98/2000/ NT/XP/WIN7/ Vista， 最低配置 CPU：奔腾133Mhz 内存：128MB 显示卡：标准VGA，256色显示模式以上 硬盘：典型安装 10M 串行通讯口：标准RS232通讯接口或其兼容型号。 其它设备：鼠标器 开始系统 系统运行前，确保下列连线正常： 1：运行本软件的计算机的RS232线已正确连接至控制器。 2：相关控制器的信号线，电源线已连接正确； 系统运行步骤： 1：打开控制器电源，控制电源指示灯将亮起。 绿色，代表处于开机运行状态；橙色代表待机状态。 2. 运行本软件 找到控制软件文件夹，点击FWM.exe运行。出现程序操作界面： 根据安装软件版本不同，上图示例中的界面及其内容可能会存在某些差别，可咨询我们的相关的售后服务人员。 上图中用红色字体标出操作界面的各部分的功能说明： 1. 菜单区：一些相关的菜单功能选择执行区。 2. 操作区：每一个方格单元代表对应的控制屏幕，可以通过鼠标或键盘的点选，拖拉的方式选择相应控制单元。 3.功能区：包含常用的功能按钮。 4.用户标题区：用户可根据本身要求，更改界面上的标题显示 5.用户图片区：用户可根据本身要求，更改界面上的图片显示，比如公司或工程相关LOGO图片。 6.附加功能区：根据版本不同有不同的附加项目。 7.状态区：显示通讯口状态，操作权限状态，和当前的本机时间，日期等。 如何开始使用 1. 通讯设置 单击主菜单中“系统配置”――》“通讯配置” 选择正确的通讯端口号，系统才能正常工作。 可以设置打开程序时自动打开串口。 2.系统配置 用友T6管理软件操作手册总账日常业务处理 日常业务流程 1、进入用友企业应用平台。 T6 双击桌面上的 如设置有密码，输入密码。没有密码就直接确定。 2、填制凭证进入系统之后打开总账菜单下面的填制凭证。如下图 丄总账［演示版】国B设畫 -二疑证 i :卜0 直接双击填制凭证，然后在弹出凭证框里点增 制单日期可以根据业务情况直接修改，输入附单据数数（可以不输），凭证摘要（在后面的匝可以选择常用摘要），选择科目直接选择（不知道可以选按F2或点击后面的一）, 输入借贷方金额，凭证完后如需继续作按增加自动保存，按保存也可，再按增加 3．修改凭证 填制凭证 证 证 证 总 ￡ ■ 凭 汇 汇 流 没有审核的凭证直接在填制凭证上面直接修改，改完之后按保存。（审核、记帐了凭 证不可以修改，如需修改必须先取消记帐、取消审核）。 4．作废删除凭证只有没有审核、记帐的凭证才可以删除。在“填制凭证”第二个菜单“制单” 下面有 一个“作废恢复”，先作废，然后再到“制单”下面“整理凭证”，这样这张凭证才被彻底删除。 5．审核凭证 双击凭证里的审核凭证菜单，需用具有审核权限而且不是制单人进入审核凭证才能审核（制单单人不能审核自己做的凭证） 选择月份，确定。 再确定。 直接点击“审核”或在第二个“审核”菜单下的“成批审核” 6．取消审核 如上所述，在“成批审核”下面有一个“成批取消审核”，只有没有记帐的凭证才可 以取消审核 7．凭证记账 所有审核过的凭证才可以记帐，未审核的凭证不能记账，在“总帐——凭证——记账” 然后按照提示一步一步往下按，最后提示记帐完成。 8．取消记帐 在“总帐”—“期末”—“对帐”菜单按“ Ctrl+H ” 系统会提示“恢复记帐前状态已被激活”。然后按“总帐”——“凭证”——“恢复 记帐前状态”。最后选“月初状态”，按确定，有密码则输入密码，再确定。 10、月末结转收支 当本月所有的业务凭证全部做完，并且记账后，我们就要进行当月的期间损益结转。 点击：月末转账并选择期间损益结转。 选择要结转的月份，然后单击“全选”。点击确定后 智能窗户控制系统软件V1.0设计说明 目录 前言 (1) 第一章软件总体设计 (1) 1.1. 软件需求概括 (1) 1.2. 定义 (1) 1.3. 功能概述 (1) 1.4. 总体结构和模块接口设计 (2) 第二章控制系统的总体设计 (3) 2.1. 功能设计 (3) 第三章软件控制系统的设计与实现 (5) 3.1. RF解码过程程序设计介绍 (5) 3.2. RF对码过程设计 (6) 3.3. 通信程序设计 (8) 3.4. IIC程序设计介绍 (9) 3.5. 接近开关程序设计 (12) 3.6. 震动开关检测程序设计 (13) 3.7. 墙面按键程序设计 (15) 第四章智能窗户控制系统的设计 (17) 第五章实测与结果说明 (18) 第六章结论 (18) 前言 目的 编写详细设计说明书是软件开发过程必不可少的部分，其目的是为了使开发人员在完成概要设计说明书的基础上完成概要设计规定的各项模块的具体实现的设计工作。 第一章软件总体设计 1.1.软件需求概括 本软件采用传统的软件开发生命周期的方法，采用自顶向下，逐步细化，模块化编程的软件设计方法。 本软件主要有以下几方面的功能 (1)RF遥控解码 (2)键盘扫描 (3)通信 (4)安全检测 (5)电机驱动 1.2.定义 本项目定义为智能遥控窗户系统软件。它将实现人机互动的无缝对接，实现智能关窗，遥控开关窗户，防雨报警等功能。 1.3.功能概述 1.墙体面板按键控制窗户的开/关 2.RF遥控器控制窗户的开/关 3.具有限位，童锁等检测功能 4.实时检测大气中的温湿度，下雨关窗 5.具有防盗，防夹手等安全性能的检测 组织部简介及职能 Company number：【WTUT-WT88Y-W8BBGB-BWYTT-19998】 设计与艺术学院团总支学生会组织部简介及职能 简介：组织部是学院党团共建工作的助手，也是学院团总支学生会工作的重要组成部门，具体负责全院团支部的思想建设和组织建设，不断加强对各班团员青年的思想政治教育工作，及时解决各班团支部建设中存在的问题，从而有效组织和指导各团支部开展学校团委和学院团工委的各项活动。组织部在长期的工作过程中逐渐形成了严谨、高效、规范、创新的工作作风。 职能：日常工作和特色活动。 日常工作 1、做好团员发展工作，按时收缴团费，做好团员证的注册、补办以及团组织关系转入（出）。 2、召开团支书例会，及时下达学习文件及有关指示精神，引导和监督各年级团支部认真开展团组织活动。 3、了解团员的思想、工作情况，及时做好反馈工作并对团员进行思想教育和纪律教育，并编写学期初的思想动态。 4、负责对各班的团干部进行考察和培训，提高其素质和工作能力，做到权责分明，指导他们认真、切实地开展团支部活动，以及协助党代表开展本班团支部的党建工作。 5、优秀团员、团干部、团支部以及优秀党员、党代表的评选表彰:每学期都要对各团支部以及党代表的工作予以考核评比,对于表现突出的组织和个人给予表彰。 特色活动 1.优秀学生座谈会，旨在让各位同学在新学期伊始，大家就回家的所见，所闻，所感，所想进行交流。以促进同学之间的相互了解，和同学之间的友谊。为大家进行思想碰撞提供绝佳的机会。 2.团日活动，及时了解各位同学在生活，学习中遇到问题。以便尽快解决。我们还会就一些热点问题展开讨论。给大家交流提供机会。 除了以上几项基本工作以外，组织部始终坚持为广大同学服务，贡献的坚定信念，尽我所能与其他各部门鼎力合作，共同完成团总支学生会的工作。总之，组织部的行动中贯穿着哪个地方需要“组织”就去哪里的“方针”，颇有管家的风范。 NC系统培训手册 编制单位：用友软件股份有限公司 中央大客户事业部 目录 一、NC系统登陆 .................................... 二、消息中心管理................................... 三、NC系统会计科目设置 ............................ 四、权限管理....................................... 五、打印模板设置................................... 六、打印模板分配................................... 七、财务制单....................................... 八、NC系统账簿查询 ................................ 九、辅助余额表查询................................. 十、辅助明细账查询................................. 十一、固定资产基础信息设置......................... 十二、卡片管理..................................... 十三、固定资产增加................................. 十四、固定资产变动................................. 十五、折旧计提..................................... 十六、折旧计算明细表............................... 门禁考勤管理软件 使 用 说 明 书 软件使用基本步骤 一．系统介绍―――――――――――――――――――――――――――――2二．软件的安装――――――――――――――――――――――――――――2 三．基本信息设置―――――――――――――――――――――――――――2 １）部门班组设置―――――――――――――――――――――――――3 ２）人员资料管理―――――――――――――――――――――――――3 ３）数据库维护――――――――――――――――――――――――――3 ４）用户管理―――――――――――――――――――――――――――3 四．门禁管理―――――――――――――――――――――――――――――4 １）通迅端口设置―――――――――――――――――――――――――4２）控制器管理――――――――――――――――――――――――――4３）控制器设置――――――――――――――――――――――――――6４）卡片资料管理―――――――――――――――――――――――――11 ５）卡片领用注册―――――――――――――――――――――――――12６）实时监控―――――――――――――――――――――――――――13 五．数据采集与事件查询――――――――――――――――――――――――13 六．考勤管理―――――――――――――――――――――――――――――14 1）班次信息设置――――――――――――――――――――――――――14 2）考勤参数设置――――――――――――――――――――――――――15 3）考勤排班――――――――――――――――――――――――――――15 4）节假日登记―――――――――――――――――――――――――――16 5）调休日期登记――――――――――――――――――――――――――16 6）请假/待料登记―――――――――――――――――――――――――17 7）原始数据修改――――――――――――――――――――――――――17 8）考勤数据处理分析――――――――――――――――――――――――17 9）考勤数据汇总―――――――—――――――――――――――――――18 10）考勤明细表—―――――――――――――――――――――――――18 11）考勤汇总表――――――――――――――――――――――――――18 12）日打卡查询――――――――――――――――――――――――――18 13）补卡记录查询—――――――――――――――――――――――――19 组织部工作职责范文 干部工作岗位职责 第一条、负责贯彻执行和结合实际研究制定选拔任用干部的标准、程序，做好区管科级干部的推荐、考核、任免、调配等工作的准备、材料收集、材料归档； 第二条、负责科级后备干部的选拔、培养、管理工作，拟定选拔培养科级后备干部规划，建立后备 __和档案，做好科级后备干部的选拔、考核、调整、补充、审批、呈报工作，及时提出后备干部工作的建议和意见，切实抓好后备干部队伍建设； 第三条、负责处级后备干部信息的选拔、培养、管理工作，并做好有关工作；及时将后备干部登记表，考察材料、民主推荐情况、民主评议情况、考核情况、培养和奖惩情况等，按照干部管理权限，对后备干部材料实行统一管理。实现管理工作的规范化、科学化。 第四条、负责抓好领导班子和领导干部的思想作风建设，以加强和改进思想工作作风为重点，以增强各级领导班子的创造力、凝聚力、战斗力为目标，加强思想教育，推进制度建设，解决突出问题，营造良好环境，努力塑造领导班子和干部队伍新形象，总结推广加强领导班子建设的典型经验； 第五条、负责领导班子宏观管理工作，贯彻党的干部工作方针政策，并按要求研究制定干部工作方面的办法和规定； 第六条、负责领导班子民主生活会以及质量测评工作，认真做好准备，广泛征求基层干部群众和社会各界对领导班子及成员的意见和建议，对征求到的意见要进行认真梳理和反馈，确保区级领导班子民主生活会质量； 第七条、负责科级干部选拔任免向市委组织部备案工作，按照市部要求，保证上报表格和材料达到完整、准确、及时、全面的要求； 第八条、负责干部挂职锻炼工作，根据干部培养和工作的实际需要，拓宽干部挂职锻炼选派渠道，丰富挂职锻炼的形式和内容，积极探索干部挂职锻炼的长效机制，促进干部挂职锻炼选派管理工作的制度化、规范化； 第九条、负责抓好干部人事制度改革工作，干部工作的宣传报道以及干部信息、资料收集、综合、上报和反馈工作，承担部领导交办的文稿草拟和其他工作。 第十条、完成部领导交办的其他工作。 开票端操作说明 双击桌面“博思开票”图标，单击“确定”，进入开票界面： 一、开票： 日常业务——开票——选择票据类型——增加——核对票号无误后——单击“请核对票据号”——输入“缴款人或缴款单位”——选择”收费项目”、“收入标准”——单击“收费金额”。 （如需增加收费项目，可单击“增一行”） （如需加入备注栏（仅限于收款收据）），则在右侧“备注”栏内输入即可） 确认无误后，单击“打印”——“打印” 二、代收缴款书： 日常业务——代收缴款书——生成——生成缴款书——关闭——缴款——输入“专用票据号”——保存——缴款书左上角出现“已缴款”三个红字即可。 三、上报核销： 日常业务——上报核销——选择或输入核销日期的截止日期——刷新——核销。 （注意：“欠缴金额”处无论为正或为负均不可核销，解决方法见后“常见问题”） 常见问题 一、如何作废“代收缴款书” 日常业务——代收缴款书——缴款——删除“专用票据号”和“缴款日期”——保存——作废。 二、上报核销时出现欠缴金额，无法完成核销，或提示多缴。 1、首先检查有没有选择好截止日期，选择好后有没有点击“刷新”。 2、其次检查有没有做代收缴款书。注意：最后一张缴款书的日期不得晚于选择上报核 销日期。 3、若上述方法仍无效，则可能是由于以前作废过票据而未作废缴款书。解决方法： 首先作废若干张缴款书（直到不能作废为止），然后重新做一张新的缴款书。再核销。 三、打开“博思开票”时，出现“windows socket error：由于目标机器积极拒绝，无法连接。 （10061），on API’connect’” 单击“确定”，将最下面一行的连接类型“SOCKET”更换为“DCOM”，再点“连接” 即可。 四、如何设置密码 双击桌面“博思开票”，单击登录界面的右下方“改口令”输入用户编号、新密码和确认密码，单击“确认”即可。 五、更换开票人名称或增加开票人 进入开票系统——系统维护——权限管理 1、更换开票人名称：单击“用户编码”——删除“用户名”——输入新的开票人名称 ——单击“保存用户”即可。 2、增加开票人：单击“新增用户”——输入“用户编码”和“用户名”——单击“保 存用户”——单击新增的用户编码——将右边的“权限列表如下”下面的“所有”前的小方框勾上——单击右侧“保存用户权限”。 六、重装电脑系统 1、由于博思开票软件安装在D盘，所以重装电脑系统前无需做任何备份。 2、重装系统后，打开我的电脑—D盘，将“博思软件”文件夹复制到桌面上（或U盘）。 3、将安装时预留的安装光盘放入主机，打开后找到“票据核销及管理_开票端(江西欠 缴不能上报版)”（或者进入D盘----开票软件备份目录勿删文件夹里也可找到）。双 击，按提示点击“下一步”，直到“完成”。 4、双击桌面任务栏右下角“博思开票服务器”，将其关闭（或右键点击“博思开票服 务器”——“关闭服务器”）。 （这一步若找不到“博思开票服务器”，也可以用重启电脑来代替） 5、将刚才复制到桌面（或U盘）的“博思软件”再复制粘贴回D盘，若提示“此文 件夹已包含名为博思软件的文件夹”，点击下面的“全部”。 6、双击桌面“博思开票”——输入用户编码(001)——确定。 7、确认原来的票据数据没有丢失后，将桌面（或U盘）的“博思软件”文件夹删除。 控制系统使用说明 系统针对轴流风机而设计的控制系统, 系统分为上位监视及下位控制两部分 本操作为上位监控软件的使用说明: 1: 启动计算机: 按下计算机电源开关约2秒, 计算机启动指示灯点亮, 稍过大约20秒钟屏幕出现操作系统选择菜单, 通过键盘的“↑↓”键选择“windows NT 4.0”菜单，这时系统进入WINDOWS NT 4.0操作系统，进入系统的操作画面。 2：系统操作 系统共分：开机画面、停机画面、趋势画面、报警画面、主机流程画面、轴系监测画面、润滑油站画面、动力油站画面、运行工况画面、运行记录画面等十幅画面，下面就十幅画面的作用及操作进行说明 A、开机画面： 开机： 当风机开始运转前，需对各项条件进行检查，在本画面中主要对如下指标进行检查，红色为有效： 1、静叶关闭：静叶角度在14度 2、放空阀全开：放空阀指示为0% 3、润滑油压正常 4、润滑油温正常 5、动力油压正常 6、逆止阀全关 7、存储器复位：按下存储器复位按钮，即可复位，若复位不成 需查看停机画面。 8、试验开关复位：按下试验开关按钮即可，试验开关按钮在风 机启动后，将自动消失，同时试验开关也自动复位。 当以上条件达到时，按下“允许机组启动”按钮，这时机组允许启动指示变为红色，PLC机柜里的“1KA”继电器将导通。机组允许启动信号传到高压柜，等待电机启动。开始进行高压合闸操作，主电机运转，主电机运转稳定后，屏幕上主电机运行指示变红。这时静叶释放按钮变红，按下静叶释放按钮后，静叶从14度开到22度，静叶释放成功指示变红。 应继续观察风机已平稳运行后，按下自动操作按钮，启机过程结束。 B、停机画面： 停机是指极有可能对风机产生巨大危害的下列条件成立时，PLC 会让电机停止运转： 1、风机轴位移过大 大学生组织部1分钟自我介绍 大学生组织部1分钟自我介绍篇一 尊敬的同学们： 大家好！能站在这里参加学生会的竞选，我很高兴也很激动，更要感谢大家对我的支持和信任，谢谢大家。我首先作一下自我介绍，我叫陈然，来自大一（1）班，是（1）班班长、体育委员及治安部大一负责人之一。 泰戈尔有句话：“天空中没有鸟的痕迹，但我已飞过。”而我想说：“天空中没有鸟的痕迹，但我正在飞翔”。我想成为学生会组织部的一员，希望在同学们的协助下，我相信我可以把学生会的工作做得更好、更出色。我是一个十分有上进心人的，任何事不做则已，做则一定做好。俗话说：“海阔凭鱼跃，天高任鸟飞”。 作为我自己，我需要一个更广阔的空间来展示自己的能力。“欲穷千里目，更上一层楼”，只有站得更高才会看得更远，我希望这次加入学生会组织部是我进步的台阶，我更希望贡献自己微薄的力量，协助学生会组织部搞好各项工作。 相信我，相信您的眼光。我愿意为学生会尽我所能。最重要的，我喜欢这里！ 谢谢！ 大学生组织部1分钟自我介绍篇二 尊敬的学院领导，你们好！ 我自愿申请加入学校学生会组织部，这对于我来说是一次鞭策与提高，也是对我的一次锻炼和考验，我申请加入这个组织，并力争为学校教学管理做出自己的一份贡献。 我认为学院纪检工作责任很大，它是学院的重要管理组织，不仅担任学院学生会其他工作的开展监督检查督促等职能，更能以自己的表率作用促进学校的管理工作上新台阶，更能激发学生的学习热情，使他们养成良好的习惯，使学生的精神面貌发生新的变化。 因此，它对于促进学院学生的管理工作有着重要的意义。可以说学院纪检工作是学院管理工作的重中之中，是管理之基，是服务之本，因此我申请加入这个组织。 如果我加入这个组织，我将感到无上光荣，我将严格要求自己，模范遵守学院各项纪律和规定，对照标准找差距，使自己的自身素质的提高，端正学习的态度，树立远大的理想，树立正确的人生观，价值观，珍惜时间，刻苦学习，做遵守纪律的榜样，做认真学习的榜样，为学院实现更大的发展，为学院创造新的辉煌做出自己的贡献，我将从现在起向这一目标奋进，请学院领导批准我的请求。 用 友 T+ 软 件 系 统 操 作 手 册版本号：v1.0 目录 一、系统登录 (3) 1.1、下载T+浏览器 (3) 1.2、软件登陆 (3) 二、基础档案设置 (5) 2.1、部门、人员档案设置 (5) 2.2、往来单位设置 (6) 2.3、会计科目及结算方式设置 (6) 三、软件操作 (9) 3.1、凭证处理 (9) 3.1.1、凭证填制 (9) 3.1.2、凭证修改 (10) 3.1.3、凭证审核 (11) 3.1.4、凭证记账 (12) 3.2、月末结转 (13) 四、日常帐表查询与统计 (14) 4.1、余额表 (14) 4.2、明细账 (15) 4.3、辅助账 (16) 五、月末结账、出报表处理 (17) 5.1、总账结账 (17) 5.2、财务报表 (20) 一、系统登录 1.1、下载T+浏览器 首次登陆需要用浏览器打开软件地址，即：127.0.0.1:8000(一般服务器默认设置，具体登陆地址请参考实际配置)，第一次登陆会提示下载T+浏览器，按照提示下载安装T+浏览器，然后打开T+浏览器，输入软件登陆地址。 ，T+浏览器， 1.2、软件登陆 按键盘上的“回车键（enter）”打开软件登陆页面，如下： 选择选择“普通用户”，输入软件工程师分配的用户名和密码，选择对应的账套，以下以demo 为例，如下图： 点击登陆，进入软件， 二、基础档案设置 2.1、部门、人员档案设置 新增的部门或者人员在系统中可按照如下方法进行维护， 2.2、往来单位设置 供应商客户档案的添加方法如下： 添加往来单位分类： 2.3、会计科目及结算方式设置会计科目： LED-ECS编辑控制系统V5.2 用 户 手 册 目录 第一章概述 (3) 1.1LED-ECS编辑控制系统介绍 (3) 1.2运行环境 (3) 第二章安装卸载 (3) 2.1安装 (3) 2.2卸载 (5) 第三章软件介绍 (5) 3.1界面介绍 (5) 3.2操作流程介绍 (13) 3.3基本概念介绍 (21) 第四章其他功能 (25) 4.1区域对齐工具栏 (25) 4.2节目对象复制、粘贴 (26) 4.3亮度调整 (26) 第五章发送 (27) 5.1发送数据 (27) 第六章常见问题解决 (28) 6.1计算机和控制卡通讯不上 (28) 6.2显示屏区域反色或亮度不够 (29) 6.3显示屏出现拖尾现象，显示屏的后面出现闪烁不稳定 (29) 6.4注意事项 (31) 6.5显示屏花屏 (31) 6.6错列现象 (32) 6.7杂点现象 (32) 第一章概述 1.1LED-ECS编辑控制系统介绍 LED-ECS编辑控制系统，是一款专门用于LED图文控制卡的配套软件。其具有功能齐全，界面直观，操作简单、方便等优点。自发布以来，受到了广大用户的一致好评。 1.2运行环境 ?操作系统 中英文Windows/2000/NT/XP ?硬件配置 CPU:奔腾600MHz以上 内存:128M 第二章安装卸载 2.1LED-ECS编辑控制系统》软件安装很简单，操作如下：双击“LED-ECS编辑控制系统”安装程序，即可弹出安装界面，如图2-1开始安装。如图所示 图2-1 单击“下一步”进入选择安装路径界面，如图2-2，如果对此不了解使用默认安装路径即可 图2-2 图2-3 单击“完成”，完成安装过程。 2.2软件卸载如图2-2 《LED-ECS编辑控制系统V5.2》提供了自动卸载功能，使您可以方便的删除《LED-ECS编辑控制系统V5.2》的所有文件、程序组件和快捷方式。用户可以在“LED-ECS编辑控制系统V5.2”组中选择“卸载LED-ECS编辑控制系统V5.2”卸载程序。也可以在“控制面板”中选择“添加/删除程序”快速卸载。卸载程序界面如图2-4，此时选择自动选项即可卸载所有文件、程序组和快捷方式。 图2-4 第三章、软件介绍 设计与艺术学院团总支学生会组织部简介及职能 简介：组织部是学院党团共建工作的助手，也是学院团总支学生会工作的重要组成部门，具体负责全院团支部的思想建设和组织建设，不断加强对各班团员青年的思想政治教育工作，及时解决各班团支部建设中存在的问题，从而有效组织和指导各团支部开展学校团委和学院团工委的各项活动。组织部在长期的工作过程中逐渐形成了严谨、高效、规范、创新的工作作风。 职能：日常工作和特色活动。 日常工作 1、做好团员发展工作，按时收缴团费，做好团员证的注册、补办以及团组织关系转入（出）。 2、召开团支书例会，及时下达学习文件及有关指示精神，引导和监督各年级团支部认真开展团组织活动。 3、了解团员的思想、工作情况，及时做好反馈工作并对团员进行思想教育和纪律教育，并编写学期初的思想动态。 4、负责对各班的团干部进行考察和培训，提高其素质和工作能力，做到权责分明，指导他们认真、切实地开展团支部活动，以及协助党代表开展本班团支部的党建工作。 5、优秀团员、团干部、团支部以及优秀党员、党代表的评选表彰:每学期都要对各团支部以及党代表的工作予以考核评比,对于表现突出的组织和个人给予表彰。 特色活动 1.优秀学生座谈会，旨在让各位同学在新学期伊始，大家就回家的所见，所闻，所感，所想进行交流。以促进同学之间的相互了解，和同学之间的友谊。为大家进行思想碰撞提供绝佳的机会。 2.团日活动，及时了解各位同学在生活，学习中遇到问题。以便尽快解决。我们还会就一些热点问题展开讨论。给大家交流提供机会。 除了以上几项基本工作以外，组织部始终坚持为广大同学服务，贡献的坚定信念，尽我所能与其他各部门鼎力合作，共同完成团总支学生会的工作。总之，组织部的行动中贯穿着哪个地方需要“组织”就去哪里的“方针”，颇有管家的风范。 财政票据(网络版)电子化系统 开票端 操 作 说 明 福建博思软件股份有限公司 目录 1.概述 业务流程 流程说明： 1.单位到财政部门申请电子票据，由财政把单位的基本信息设置好并审核完后，财政部门给用票单位发放票据，单位进行领票确认并入库。 2.在规定时间内，单位要把开据的发票带到财政核销，然后由财政进行审核。 系统登录 登入系统界面如图： 登录日期：自动读取主服务器的日期。 所属区划：选择单位所属区划编码。【00安徽省非税收入征收管理局】 所属单位：输入单位编码。 用户编码：登录单位的用户编码【002】 用户密码：默认单位密码为【123456】 验证码：当输入错误时，会自动换一张验证码图片； 记录用户编码：勾选系统自动把用户编码保存在本地，第二次登录不需要重新输入。 填写完正确信息，点【确定】即可登入系统。 进入系统 进入系统界面如图： 当单位端票据出现变动的时候，如财政或上级直管下发票据时，才会出现此界面: 出现此界面后点击最下方的确认按钮，入库完成。 当单位端票据无变动时，直接进入界面： 2.基本编码人员管理 功能说明：对单位开票人员维护，修改开票人名称。 密码管理 修改开票人员密码，重置等操作。 收发信息 查看财政部门相关通知等。 3.日常业务 电脑开票 功能说明：是用于开票据类型为电子化的票据。 在电脑开票操作界面，点击工具栏中的【增加】按钮，系统会弹出核对票号提示框，如图： 注意：必须核对放入打印机中的票据类型、号码是否和电脑中显示的一致，如果不一致打印出来的票据为无效票据，核对完后，输入缴款人或缴款单位和收费项目等信息，全部输入完后，点【增加】按钮进行保存当前票据信息或点【打印】按钮进行保存当前票据信息并把当前的票据信息打印出来；点电脑开票操作界面工具栏中的【退出】则不保存。 在票据类型下拉单框中选择所要开票的票据类型，再点【增加】进行开票。 用友T软件系统操作手 册 Pleasure Group Office【T985AB-B866SYT-B182C-BS682T-STT18】 用 友 T+ 软 件 系 统 操 作 手 册 版本号：目录 一、系统登录 、下载T+浏览器 首次登陆需要用浏览器打开软件地址，即：(一般服务器默认设置，具体登陆地址请参考实际配置)，第一次登陆会提示下载T+浏览器，按照提示下载安装T+浏览器，然后打开T+浏览器，输入软件登陆地址。 ，T+浏览器， 、软件登陆 按键盘上的“回车键（enter）”打开软件登陆页面，如下： 选择选择“普通用户”，输入软件工程师分配的用户名和密码，选择对应的账套，以下以demo为例，如下图： 点击登陆，进入软件， 二、基础档案设置 、部门、人员档案设置 新增的部门或者人员在系统中可按照如下方法进行维护， 、往来单位设置 供应商客户档案的添加方法如下： 添加往来单位分类： 、会计科目及结算方式设置 会计科目： 系统预置170个《2013小企业会计准则》科目，如下： 结算方式，如下： 三、软件操作 、凭证处理 填制 进入总账填制凭证菜单，增加凭证，填制摘要和科目，注意有辅助核算的会计科目， 以下为点开总账的处理流程图： 如若现金流量系统指定错误，可按照以下步骤修改： 凭证在没有审核时，可以直接在当前凭证上修改，然后点击“保存”完成修改； 凭证审核 进入总审核凭证菜单下，如下图： 选择审核凭证的会计期间： 、凭证记账 进入凭证菜单下的记账菜单， 、月末结转 期间损益结转 四、日常帐表查询与统计 、余额表 用于查询统计各级科目的本期发生额、累计发生额和余额等。传统的总账，是以总账科目分页设账，而余额表则可输出某月或某几个月的所有总账科目或明细科目的期初余额、本期发生额、累计发生额、期末余额，在实行计算机记账后，我们建议用户用余额表代替总账。 创维液晶拼接控制系统 软件操作指南 【LCD-CONTROLLER12】 请在使用本产品前仔细阅读该用户指导书 温馨提示:: 温馨提示 ◆为了您和设备的安全，请您在使用设备前务必仔细阅读产品说明书。 ◆如果在使用过程中遇到疑问,请首先阅读本说明书。 正文中有设备操作的详细描述,请按书中介绍规范操作。 如仍有疑问,请联系我们,我们尽快给您满意的答复。 ◆本说明书如有版本变动,恕不另行通知,敬请见谅！ 一、功能特点 二、技术参数 三、控制系统连接示意图 四、基本操作 五、故障排除 六、安全注意事项 一、功能特点创维创维--液晶液晶拼接拼接拼接控制器特点控制器特点 ★采用创维第四代V12数字阵列高速图像处理技术 视频带宽高达500MHZ，应用先进的数字高速图像处理算实时分割放大输入图像信号，在多倍分割放大处理的单屏画面上，彻底解决模/数之间转换带来的锯齿及马赛克现象，拼接画面清晰流畅，色彩鲜艳逼真。 ★具有开窗具有开窗、、漫游漫游、、叠加等功能 以屏为单元单位的前提下，真正实现图像的跨屏、开窗、画中画、缩放、叠加、漫游等个性化功能。 ★采用基于LVDS 差分传送技术差分传送技术，，增强抗干扰能力 采用并行高速总线连接技术，上位控制端发出命令后，系统能快速切换信号到命令指定的通道，实现快速响应。 采用基于LVDS 差分传送技术，提高系统抗干扰能力，外部干扰对信号的影响降到了最低，并且，抗干扰能力随频率提高而提升。★最新高速数字阵列矩阵通道切换技术 输入信号小于64路时，用户不需要再另外增加矩阵，便可以实现通道之间的任意换及显示。 ★断电前状态记忆功能 通过控制软件的提前设置，能在现场断电的情况下，重启系统后，能自动记忆设备关机前的工作模式状态。 ★全面支持全高清信号 处理器采用先进的去隔行和运动补偿算法，使得隔行信号在大屏幕拼接墙上显示更加清晰细腻，最大限度的消除了大屏幕显示的锯齿现象，图像实现了完全真正高清实时处理。纯硬件架构的视频处理模块设计，使得高清视频和高分辨率计算机信号能得到实时采样，确保了高清信号的最高视频质量，使客户看到的是高质量的完美画质。 （一）办公室（信访办公室） １、协助部领导综合协调、处理本部政务和日常事务，做好内部科室协调、对外联系和接待工作，负责部内的保卫、内务管理、后勤服务等工作； 2、负责会议组织、秘书事务、文电处理、文书档案管理和机要保密工作； 3、负责本部信访工作，负责财务的综合管理和协调工作，搞好本部办公用品的购买和固定资产的登记管理，以及协调车辆管理调度等工作； 4、负责印章的保管和使用； 5、负责修订部内管理的有关规章制度并组织实施； 6、承办本部机构编制、干部人事、老干部服务和党群工作，完成部领导交办的其他工作。 电话: 传真： （二）研究室 1、负责全县组织系统调研工作，负责有关干部管理和党建工作的理论探讨、政策研究工作，及时调查了解党的基层组织建设、干部工作和人才工作情况，为部领导决策提供建议和方案； 2、承担或参与综合性报告、总结、重要文件和领导讲话稿的起草工作； 3、负责全县组工信息的编发和上报工作； 4、制定研讨课题，指导各乡镇党委的调研工作。 电话: 传真： （三）组织科 1、负责全县基层组织建设的宏观指导和管理； 2、指导各镇党的组织的领导班子建设和换届选举； 3、指导乡镇（社区）和县直单位领导班子召开民主生活会； 4、负责党员教育、管理与发展工作的宏观指导； 5、承办党员组织的关系转移手续和党费的管理； 6、负责全县党组织、党员统计和分析工作； 7、负责全县党员教育和发展新党员工作的宏观管理的指导。 电话: 传真： （四）干部科（公务员管理科） 1、按照干部管理权限、负责对股级以上领导干部的考察、考核、任免、调配工作及办理退休、工资和职级待遇的审批手续，负责股级干部的备案审查和审批等工作； 2、负责全县各级后备干部的培养、考察工作； 3、指导全县各级领导班子的思想政治作风建设。 （五）干部监督科（举报中心） 1、负责县管干部的监督审查工作； 工会经费收入专用收据(1) 福州博思软件开发有限公司 2010年6月 目录 第一部分初始安 装 ....................................................... (1) 1.1系统 安装 (1) 1.2系统登录 ............................................................ (4) 第二部分组成模块介 绍 ................................................... (4) 2.1模块组 成 (4) 2.1.1票据资料 .......................................................... (5) 2.1.2用户管 理 .......................................................... (5) 2.1.3 票据领用 (6) 2.1.4电脑开票 .......................................................... (6) 2.1.5手工开 票 .......................................................... (7) 2.1.6 手工批开票 (7) 2.1.7票据查询 .......................................................... (8) 第三部分软件操 作 ....................................................... (9) 3.2用户 管理 (10) 欧洲标准E N简介 WTD standardization office【WTD 5AB- WTDK 08- WTD 2C】 欧洲标准E N简介 1.欧洲标准化委员会CEN（European Committee for Stadardization）简介 为了适应欧洲共同市场采用统一标准的需要，1951年欧洲炼钢联盟ECSC（European Coal and Steel Community）成立，两年之后钢铁产品术语协调委员会COCOR （Coordinating Commission for the Nomenclature of Iron and Steel Products）产生。 在随后30年过程中COCOR率其工作组（其成员由ECSC成员国的标准委员代表组成，具体负责钢分类和产品工作）编制了涉及面很广的钢铁标准手册，它不但有术语标准，还有关于钢产品的尺寸、质量和试验方法的协调统一标准，称为欧洲煤钢联标准 ——EURONORM S ，然而ECSC成员国并没有义务一定要采用EURONORM S 。多数情况下，各 成员国在本国范围里仍采用各自的标准。60年代初由欧洲经济联盟EES（European Economic Community）和欧洲自由贸易联盟EFTA（European Free Trade Association）的成员国国家标准团体成立了欧洲标准化委员会CEN和欧洲电工标准化委员会CENLEC（European Committee for Electrotechnical Standardization）其分工恰似国际标准化组织ISO和国际电工标准化组织IEC，他们既要协调成员国之间的标准和制订区域性标准，又要在国际场合下维护本地区的利益。其与ECSC不同的是，它的成员国必须无条件采用这两个组织颁布的欧洲标准Ens(European Standards)作为本国标准。 二、CEN的组织机构 大屏幕控制系统软件详解说明 一软件安装 安装注意事项： 非专业人事安装：安装前请先关闭防火墙（如360安全卫士，瑞星，诺盾等），等安装完并且成功启动本软件后可重新开启防火墙； 专业人事安装：先把防火墙拦截自动处理功能改为询问后处理，第一次打开本软件时会提示一个拦截信息； 安装前请校对系统时间,安装后不能在错误的系统时间下运行/启动软件,否则会使软件注册失效，这种情况下需要重新注册； Windows 7,注意以下设置 0.1)打开控制面板 0.2) 选择系统和安全 0.3) 选择操作中心 0.4) 选择更换用户帐户控制设置 0.5)级别设置，选择成从不通知 １．软件解压后，请选择双击，进入安装界面如图１，图２ 图1 图2 ２．选择键，进入下一界面如图3 图３ 3.选中项，再按键，进入下一界面如图４ 图4 4.选择键，进入下一界面如图５ 图５ ５.选中项，再选择键，进入下一界面如图６ 图６ ６.选择键，进入下一界面如图７ 图８ ７.选择键，软件安装完成 二软件操作 选择WINDOWS 下开始按钮，选择程序，选择Wall Control项， 点击Wall Control软件进入大屏幕控制系统软件主界面如图9所示,整个软件分为3个区，标题区，设置区，功能区 图9 1.1标题区 大屏幕控制系统软件(只有管理员才可设置此项目) 1.2设置区 1.2.1系统 高级功能：管理员登录。 产品选型：选择拼接盒型号。 定时系统：设置定时时间。 幕墙开机：开机 幕墙关机：关机 退出：退出软件系统。 1.2.2设置 串口设置：设置使用的串口参数。 矩阵设置：设置矩阵的相关参数。 幕墙设置：幕墙设置参数。 幕墙颜色：幕墙颜色设置。 标志设置：更改幕墙名称。 系统设置：控制软件系统设置。 1.2.3工具 虚拟键盘：虚拟键盘设置。 硬件注册：可以通过时钟IC注册处理器的使用权限。 1.2.4语言 中文选择:选择软件语言类型为中文。 Ｅnglish:选择软件语言类型为英语。 目录 1，系统概述--------------------------------------------------------------------------------------------------1 1.1 系统简介---------------------------------------------------------------------------------------------2 1.2 系统主要组成---------------------------------------------------------------------------------------2 1.3 系统硬件简要连接图------------------------------------------------------------------------------3 1.4 实际连线图------------------------------------------------------------------------------------------3 2,系统软件使用软件简要说明-----------------------------------------------------------------------------5 2.1 介绍---------------------------------------------------------------------------------------------------5 2.2 操作步骤---------------------------------------------------------------------------------------------5 2.3 取景窗口---------------------------------------------------------------------------------------------7 2.4 flash/cel文件的播放--------------------------------------------------------------------------------7 注1:连接网络的相关设置修改--------------------------------------------------------------9 注2:本机IP的查询----------------------------------------------------------------------------9 注3:本机IP的修改----------------------------------------------------------------------------10 注4:控制器IP的修改-------------------------------------------------------------------------11 3,对应表制作与选择-----------------------------------------------------------------------------------------12 3.1 介绍---------------------------------------------------------------------------------------------------12 3.2 操作步骤---------------------------------------------------------------------------------------------12 4,说明-----------------------------------------------------------------------------------------------------------14 4.1 ONC1A------------------------------------------------------------------------------------------------14 4.2 ONC1B------------------------------------------------------------------------------------------------14 4.3 ONC1C------------------------------------------------------------------------------------------------15 4.4 ONC1D------------------------------------------------------------------------------------------------15 4.5 ONC1E------------------------------------------------------------------------------------------------16 4.6 ONC1F------------------------------------------------------------------------------------------------17 4.7 ONC1G------------------------------------------------------------------------------------------------17 4.8 ONC1F------------------------------------------------------------------------------------------------17 5,附件-----------------------------------------------------------------------------------------------------------19 5.1 数码按钮控制板说明--------------------------------------------------------------------------------19 5.2 象素点排列说明--------------------------------------------------------------------------------------19控制软件说明书
用友T软件软件操作手册
智能窗户控制系统软件说明
组织部简介及职能
用友NC财务信息系统操作手册全
软件操作说明书
组织部工作职责范文
博思软件操作步骤
控制系统使用说明
大学生组织部1分钟自我介绍
用友T+软件系统操作手册范本
威利普LEDESC控制系统操作说明书
组织部简介及职能
财政票据 网络版 电子化系统开票端操作手册
用友T软件系统操作手册
控制软件操作说明书
组织部各科室职责
工会经费收入专用收据(1)
欧洲标准EN简介
大屏幕控制系统软件详解说明V6.(完整)
控制系统说明书 V1.0