an invalid parameter has been given to a service

本文记录了一次XP系统安装过程中遇到的lsass.exe错误问题及其解决过程。文章指出,在全新安装系统后仍出现该错误,但可通过特定方式解决,如使用正确密码解锁海尔电脑的系统安装限制。

重装系统,格盘,复制文件,重起,出现xp滚动界面,接着lsass。exe遇到问题

 

an invalid parameter has been given to a service or a function

发送无效的参数给服务或功能

 

奇怪的地方在于:

1。已经格盘,重装,应该排除了软件的问题

2。虽然重装后不能从硬盘进入系统,但能用光盘进windows pe系统,似乎可以排除硬件问题

所以就不知道是哪儿的问题了

 

网上查了查,说法各异。

 

上次给人装电脑,主板电容突然爆了,这次又遇到了疑难杂症。

 

======================

后来问题得到解决,海尔的电脑需要输入某个密码解锁,才能顺利重装系统,否则会报上面的错误。

顺便说一下,这个密码很值钱啊,重装一次150多块。

/** * A parameter for the function line_search_morethuente only. * This parameter determines which curvature condition to use. * The default value is 1, implying a strong Wolfe condition. * If the value is 0, then a weak Wolfe condition is used. */ int abs_curv_cond; /** * A parameter for the function line_search_morethuente only. * This parameter determines the interval shrink strategy in line search. * The default value is 0, guaranteeing at least 2^(-m/2) decreasing of * uncertainty as trial number m grows. It is used by More and Thuente. * If the value is 1, then at least 2^(-m) decreasing of uncertainty is * guaranteed. It is used by Hager and Zhang in TOMS851. The former suits * well-conditioned functions while the latter suits stiff functions. */ int shrink_type; }; /** * Default L-BFGS parameters. */ static const lbfgs_parameter_t _default_param = { 8, 1.0e-5, 0, 1.0e-5, 0, 60, 1.0e-20, 1.0e+20, 1.0e-4, 0.9, 1.0e-16, 1, 1, 0, }; /** * Return values of lbfgs_optimize(). * Roughly speaking, a negative value indicates an error. */ enum { /** L-BFGS reaches convergence. */ LBFGS_CONVERGENCE = 0, /** L-BFGS satisfies stopping criteria. */ LBFGS_STOP, /** The initial variables already minimize the objective function. */ LBFGS_ALREADY_MINIMIZED, /** Unknown error. */ LBFGSERR_UNKNOWNERROR = -1024, /** Logic error. */ LBFGSERR_LOGICERROR, /** The minimization process has been canceled. */ LBFGSERR_CANCELED, /** Invalid number of variables specified. */ LBFGSERR_INVALID_N, /** Invalid parameter lbfgs_parameter_t::mem_size specified. */ LBFGSERR_INVALID_MEMSIZE, /** Invalid parameter lbfgs_parameter_t::g_epsilon specified. */ LBFGSERR_INVALID_GEPSILON, /** Invalid parameter lbfgs_parameter_t::past specified. */ LBFGSERR_INVALID_TESTPERIOD, /** Invalid parameter lbfgs_parameter_t::delta specified. */ LBFGSERR_INVALID_DELTA, /** Invalid parameter lbfgs_parameter_t::min_step specified. */ LBFGSERR_INVALID_MINSTEP, /** Invalid parameter lbfgs_parameter_t::max_step specified. */ LBFGSERR_INVALID_MAXSTEP, /** Invalid parameter lbfgs_parameter_t::f_dec_coeff specified. */ LBFGSERR_INVALID_FDECCOEFF, /** Invalid parameter lbfgs_parameter_t::s_curv_coeff specified. */ LBFGSERR_INVALID_SCURVCOEFF, /** Invalid parameter lbfgs_parameter_t::xtol specified. */ LBFGSERR_INVALID_XTOL, /** Invalid parameter lbfgs_parameter_t::max_linesearch specified. */ LBFGSERR_INVALID_MAXLINESEARCH, /** The line-search step went out of the interval of uncertainty. */ LBFGSERR_OUTOFINTERVAL, /** A logic error occurred; alternatively, the interval of uncertainty became too small. */ LBFGSERR_INCORRECT_TMINMAX, // -1009 /** The function value became NaN or Inf. */ LBFGSERR_INVALID_FUNCVAL, /** A rounding error occurred; alternatively, no line-search step satisfies the sufficient decrease and curvature conditions. */ LBFGSERR_ROUNDING_ERROR, /** The line-search step became smaller than lbfgs_parameter_t::min_step. */ LBFGSERR_MINIMUMSTEP, /** The line-search step became larger than lbfgs_parameter_t::max_step. */ LBFGSERR_MAXIMUMSTEP, /** The line-search routine reaches the maximum number of evaluations. */ LBFGSERR_MAXIMUMLINESEARCH, // -1004 /** The algorithm routine reaches the maximum number of iterations. */ LBFGSERR_MAXIMUMITERATION, /** Relative width of the interval of uncertainty is at most lbfgs_parameter_t::xtol. */ LBFGSERR_WIDTHTOOSMALL, /** A logic error (negative line-search step) occurred. */ LBFGSERR_INVALIDPARAMETERS, /** The current search direction increases the objective function value. */ LBFGSERR_INCREASEGRADIENT, }; /** * Callback interface to provide objective function and gradient evaluations. * * The lbfgs_optimize() function call this function to obtain the values of objective * function and its gradients when needed. A client program must implement * this function to evaluate the values of the objective function and its * gradients, given current values of variables. * * @param instance The user data sent for lbfgs_optimize() function by the client. * @param x The current values of variables. * @param g The gradient vector. The callback function must compute * the gradient values for the current variables. * @param n The number of variables. * @retval double The value of the objective function for the current * variables. */ typedef double (*lbfgs_evaluate_t)(void *instance, const double *x, double *g, const int n); /** * Callback interface to provide an upper bound at the beginning of current linear search. * * The lbfgs_optimize() function call this function to obtain the values of the * upperbound of the stepsize to search in, provided with the beginning values of * variables before the linear search, and the current step vector (can be descent direction). * A client program can implement this function for more efficient linesearch. Any step * larger than this bound should not be considered. For example, it has a very large or even * inf function value. Note that the function value at the provided bound should be FINITE! * If it is not used, just set it NULL or nullptr. * * @param instance The user data sent for lbfgs_optimize() function by the client. * @param xp The values of variables before current line search. * @param d The step vector. It can be the descent direction. * @param n The number of variables. * @retval double The upperboud of the step in current line search routine, * such that stpbound*d is the maximum reasonable step. */ typedef double (*lbfgs_stepbound_t)(void *instance, const double *xp, const double *d, const int n); /** * Callback interface to receive the progress of the optimization process. * * The lbfgs_optimize() function call this function for each iteration. Implementing * this function, a client program can store or display the current progress * of the optimization process. If it is not used, just set it NULL or nullptr. * * @param instance The user data sent for lbfgs_optimize() function by the client. * @param x The current values of variables. * @param g The current gradient values of variables. * @param fx The current value of the objective function. * @param xnorm The Euclidean norm of the variables. * @param gnorm The Euclidean norm of the gradients. * @param step The line-search step used for this iteration. * @param n The number of variables. * @param k The iteration count. * @param ls The number of evaluations called for this iteration. * @retval int Zero to continue the optimization process. Returning a * non-zero value will cancel the optimization process. */ typedef int (*lbfgs_progress_t)(void *instance, const double *x, const double *g, const double fx, const double xnorm, const double gnorm, const double step, int n, int k, int ls); /** * Callback data struct */ struct callback_data_t { int n; void *instance; lbfgs_evaluate_t proc_evaluate; lbfgs_stepbound_t proc_stepbound; lbfgs_progress_t proc_progress; }; /** * Iteration data struct */ struct iteration_data_t { double alpha; double *s; /* [n] */ double *y; /* [n] */ double ys; /* vecdot(y, s) */ }; 继续注释
09-20
/** * Return values of lbfgs_optimize(). * Roughly speaking, a negative value indicates an error. */ enum { /** L-BFGS reaches convergence. */ LBFGS_CONVERGENCE = 0, /** L-BFGS satisfies stopping criteria. */ LBFGS_STOP, /** The iteration has been canceled by the monitor callback. */ LBFGS_CANCELED, /** Unknown error. */ LBFGSERR_UNKNOWNERROR = -1024, /** Invalid number of variables specified. */ LBFGSERR_INVALID_N, /** Invalid parameter lbfgs_parameter_t::mem_size specified. */ LBFGSERR_INVALID_MEMSIZE, /** Invalid parameter lbfgs_parameter_t::g_epsilon specified. */ LBFGSERR_INVALID_GEPSILON, /** Invalid parameter lbfgs_parameter_t::past specified. */ LBFGSERR_INVALID_TESTPERIOD, /** Invalid parameter lbfgs_parameter_t::delta specified. */ LBFGSERR_INVALID_DELTA, /** Invalid parameter lbfgs_parameter_t::min_step specified. */ LBFGSERR_INVALID_MINSTEP, /** Invalid parameter lbfgs_parameter_t::max_step specified. */ LBFGSERR_INVALID_MAXSTEP, /** Invalid parameter lbfgs_parameter_t::f_dec_coeff specified. */ LBFGSERR_INVALID_FDECCOEFF, /** Invalid parameter lbfgs_parameter_t::s_curv_coeff specified. */ LBFGSERR_INVALID_SCURVCOEFF, /** Invalid parameter lbfgs_parameter_t::machine_prec specified. */ LBFGSERR_INVALID_MACHINEPREC, /** Invalid parameter lbfgs_parameter_t::max_linesearch specified. */ LBFGSERR_INVALID_MAXLINESEARCH, /** The function value became NaN or Inf. */ LBFGSERR_INVALID_FUNCVAL, /** The line-search step became smaller than lbfgs_parameter_t::min_step. */ LBFGSERR_MINIMUMSTEP, /** The line-search step became larger than lbfgs_parameter_t::max_step. */ LBFGSERR_MAXIMUMSTEP, /** Line search reaches the maximum, assumptions not satisfied or precision not achievable.*/ LBFGSERR_MAXIMUMLINESEARCH, /** The algorithm routine reaches the maximum number of iterations. */ LBFGSERR_MAXIMUMITERATION, /** Relative search interval width is at least lbfgs_parameter_t::machine_prec. */ LBFGSERR_WIDTHTOOSMALL, /** A logic error (negative line-search step) occurred. */ LBFGSERR_INVALIDPARAMETERS, /** The current search direction increases the cost function value. */ LBFGSERR_INCREASEGRADIENT, }; /** * Callback interface to provide cost function and gradient evaluations. * * The lbfgs_optimize() function call this function to obtain the values of cost * function and its gradients when needed. A client program must implement * this function to evaluate the values of the cost function and its * gradients, given current values of variables. * * @param instance The user data sent for lbfgs_optimize() function by the client. * @param x The current values of variables. * @param g The gradient vector. The callback function must compute * the gradient values for the current variables. * @retval double The value of the cost function for the current variables. */ typedef double (*lbfgs_evaluate_t)(void *instance, const Eigen::VectorXd &x, Eigen::VectorXd &g); /** * Callback interface to provide an upper bound at the beginning of the current line search. * * The lbfgs_optimize() function call this function to obtain the values of the * upperbound of the stepsize to search in, provided with the beginning values of * variables before the line search, and the current step vector (can be descent direction). * A client program can implement this function for more efficient linesearch. Any step * larger than this bound should not be considered. For example, it has a very large or even * inf function value. Note that the function value at the provided bound should be FINITE! * If it is not used, just set it nullptr. * * @param instance The user data sent for lbfgs_optimize() function by the client. * @param xp The values of variables before current line search. * @param d The step vector. It can be the descent direction. * @retval double The upperboud of the step in current line search routine, * such that (stpbound * d) is the maximum reasonable step. */ typedef double (*lbfgs_stepbound_t)(void *instance, const Eigen::VectorXd &xp, const Eigen::VectorXd &d); /** * Callback interface to monitor the progress of the minimization process. * * The lbfgs_optimize() function call this function for each iteration. Implementing * this function, a client program can store or display the current progress * of the minimization process. If it is not used, just set it nullptr. * * @param instance The user data sent for lbfgs_optimize() function by the client. * @param x The current values of variables. * @param g The current gradient values of variables. * @param fx The current value of the cost function. * @param step The line-search step used for this iteration. * @param k The iteration count. * @param ls The number of evaluations called for this iteration. * @retval int Zero to continue the minimization process. Returning a * non-zero value will cancel the minimization process. */ typedef int (*lbfgs_progress_t)(void *instance, const Eigen::VectorXd &x, const Eigen::VectorXd &g, const double fx, const double step, const int k, const int ls); /** * Callback data struct */ struct callback_data_t { void *instance = nullptr; lbfgs_evaluate_t proc_evaluate = nullptr; lbfgs_stepbound_t proc_stepbound = nullptr; lbfgs_progress_t proc_progress = nullptr; }; // ----------------------- L-BFGS Part ----------------------- /** * Line search method for smooth or nonsmooth functions. * This function performs line search to find a point that satisfy * both the Armijo condition and the weak Wolfe condition. It is * as robust as the backtracking line search but further applies * to continuous and piecewise smooth functions where the strong * Wolfe condition usually does not hold. * * @see * Adrian S. Lewis and Michael L. Overton. Nonsmooth optimization * via quasi-Newton methods. Mathematical Programming, Vol 141, * No 1, pp. 135-163, 2013. */ inline int line_search_lewisoverton(Eigen::VectorXd &x, double &f, Eigen::VectorXd &g, double &stp, const Eigen::VectorXd &s, const Eigen::VectorXd &xp, const Eigen::VectorXd &gp, const double stpmin, const double stpmax, const callback_data_t &cd, const lbfgs_parameter_t &param) { int count = 0; bool brackt = false, touched = false; double finit, dginit, dgtest, dstest; double mu = 0.0, nu = stpmax; /* Check the input parameters for errors. */ if (!(stp > 0.0)) { return LBFGSERR_INVALIDPARAMETERS; } /* Compute the initial gradient in the search direction. */ dginit = gp.dot(s); /* Make sure that s points to a descent direction. */ if (0.0 < dginit) { return LBFGSERR_INCREASEGRADIENT; } /* The initial value of the cost function. */ finit = f; dgtest = param.f_dec_coeff * dginit; dstest = param.s_curv_coeff * dginit; while (true) { x = xp + stp * s; /* Evaluate the function and gradient values. */ f = cd.proc_evaluate(cd.instance, x, g); ++count; /* Test for errors. */ if (std::isinf(f) || std::isnan(f)) { return LBFGSERR_INVALID_FUNCVAL; } /* Check the Armijo condition. */ if (f > finit + stp * dgtest) { nu = stp; brackt = true; } else { /* Check the weak Wolfe condition. */ if (g.dot(s) < dstest) { mu = stp; } else { return count; } } if (param.max_linesearch <= count) { /* Maximum number of iteration. */ return LBFGSERR_MAXIMUMLINESEARCH; } if (brackt && (nu - mu) < param.machine_prec * nu) { /* Relative interval width is at least machine_prec. */ return LBFGSERR_WIDTHTOOSMALL; } if (brackt) { stp = 0.5 * (mu + nu); } else { stp *= 2.0; } if (stp < stpmin) { /* The step is the minimum value. */ return LBFGSERR_MINIMUMSTEP; } if (stp > stpmax) { if (touched) { /* The step is the maximum value. */ return LBFGSERR_MAXIMUMSTEP; } else { /* The maximum value should be tried once. */ touched = true; stp = stpmax; } } } }注释上述代码并将原有英文注释翻译为英文
09-19
握手和证书验证在httpd模块请求入口那里就已经实现了对https的处理,这里是不是可以不用修改?基本上只要考虑事件推送pull point和basic notify相关,基于我前面给你的onvif协议上对此的规范,能不能重新给出完整的修改,分步骤,对每一步修改繇指出是根据协议规范上的哪一点来修改的?原因是什么?怎么修改?请根据协议重新对soap_tev.c和soap_event.c的代码进行修改——Real-time Pull-Point Notification Interface This section introduces the Real-time Pull-Point Notification Interface. This interface provides a firewall friendly notification interface that enables real-time polling and initiates all client communications. This interface is used in the following way: The client asks the device for a pull point with the CreatePullPointSubscriptionRequest message. The device evaluates the subscription request and returns either a CreatePullPointSubscriptionResponse or one of the Fault codes. If the subscription is accepted, the response contains a WS-EndpointReference to the instantiated pull point. This WS-Endpoint provides a PullMessages operation, which is used by the client to retrieve Notifications. Additionally it provides the Renew and Unsubscribe operations of the Base Subscription Manager Interface. The sequence diagram of the interaction is shown in Figure 6. Client Event Service CreatePullPoint SubscriptionRequest Instantiate CreatePullPoint SubscriptionResponse PullMessages Request PullPoint PullMessages Response Unsubscribe Request Unsubscribe Response Figure 6: Sequence diagram for the Real-time Pull-Point Notification Interface The device immediately responds with notifications that have been aggregated on behalf of the client. If there are no aggregated notifications, the device waits to respond until either a notification is produced for the client or the specified Timeout has exceeded. In any case, the response will contain, at most, the number of notifications specified by the MessageLimit parameter. The client can poll the notifications in real-time when it starts a new PullMessagesRequest immediately after each PullMessagesResponse. For a device implementation it is important to support multiple pull points (including multiple pullpoints per client) in order to allow precise event generation. If a device would only support one subscription at a time a client would need to subscribe without any scope restriction, because changing of event subscription is not possible. Hence this would require the device to serve all available events for which the device would have to activate all subsystems that generate events. This may cause unnecessary load by e.g. activating multiple motion detectors and similar without need. Additionally the traffic produced by all these events may cause a substantial network load. ONVIF™– 86 ONVIF Core Spec – Ver. 24.12 If the device supports persistent notification storage, see 9.1.7, the WS-Endpoint also provides a Seek opera tion. This operation allows to reposition the pull pointer into the past. With the Seek operation it is also possible to reverse the pull direction. There is also a BeginOfBuffer event, as defined in 9.11.1, that signals the start of the buffer. An ONVIF compliant device shall implement the Real Time Pull-Point Notification Interface. 9.1.1 Create pull point subscription An ONVIF compliant device shall provide the CreatePullPointSubscription command. If no Filter element is specified the pullpoint shall notify all occurring events to the client. By default the pull point keep alive is controlled via the PullMessages operation. In this case, after a PullMes sages response is returned, the subscription should be active for at least the timeout specified in the PullMes sages request. A device shall support an absolute time value specified in utc as well as a relative time value for the InitialTer minationTime parameter. A device shall respond both parameters CurrentTime and TerminationTime as utc using the ‘Z’ indicator. The following optional subscription policy elements are defined in tev:SubscriptionPolicy: • tev:ChangedOnly A pullpoint should not provide Initialized nor Deleted events for Properties. Both request and response message contain the same elements as the SubscriptionRequest and Response of [WS-BaseNotification] without the ConsumerReference. REQUEST: • Filter - optional [wsnt:FilterType] Optional filtering for e.g. topics. • InitialTerminationTime - optional [wsnt:AbsoluteOrRelativeTimeType] Initial termination time. • SubscriptionPolicy - optional [xs:any] RESPONSE: • SubscriptionReference [wsa:EndpointReferenceType] Endpoint reference of the subscription to be used for pulling the messages. • CurrentTime [xs:dateTime] Current time of the server for synchronization purposes. • TerminationTime [xs:dateTime] Date time when the PullPoint will be shut down without further pull requests. FAULTS: • The same faults as for Subscription Request of the [WS-BaseNotification] are used. ACCESS CLASS: READ_MEDIA 9.1.2 Pull messages The device shall provide the following PullMessages command for all SubscriptionManager endpoints returned by the CreatePullPointSubscription command. ONVIF™– 87 ONVIF Core Spec – Ver. 24.12 The device shall support a Timeout of at least one minute. The device shall not respond with a PullMessages FaultResponse when the MessageLimit is greater than the device supports. Instead, the device shall return up to the supported messages in the response. The response behavior shall be one of three types: • If there are one or more messages waiting (i.e., aggregated) when the request arrives, the device shall immediately respond with the waiting messages, up to the MessageLimit. The device shall not discard unsent messages, but shall await the next PullMessages request to send remaining messages. • If there are no messages waiting, and the device generates a message (or multiple simultaneous messages) prior to reaching the Timeout, the device shall immediately respond with the generated messages, up to the MessageLimit. The device shall not wait for additional messages before returning the response. • If there are no messages waiting, and the device does not generate any message prior to reaching the Timeout, the device shall respond with zero messages. The device shall not return a response with zero messages prior to reaching the Timeout. A device shall respond both parameters CurrentTime and TerminationTime as utc using the ‘Z’ indicator. After a seek operation the device shall return the messages in strict message utc time order. Note that this requirement is not applicable to standard realtime message delivery where the delivery order may be affected by device internal computations. A device should return an error (UnableToGetMessagesFault) when receiving a PullMessages request for a subscription where a blocking PullMessage request already exists. REQUEST: • Timeout [xs:duration] Maximum time to block until this method returns. • MessageLimit [xs:int] Upper limit for the number of messages to return at once. A server implementation may decide to return less messages. RESPONSE: • CurrentTime [xs:dateTime] The date and time when the messages have been delivered by the web server to the client. • TerminationTime [xs:dateTime] Date time when the PullPoint will be shut down without further pull requests. • NotificationMessage - optional, unbounded [wsnt:NotificationMessageHolderType] List of messages. This list shall be empty in case of a timeout. PULLMESSAGESFAULTRESPONSE: • MaxTimeout [xs:duration] Only when the Timeout exceeds the upper limit supported by the device. Not sent when the Message Limit is exceeded. The Fault Message shall contain the upper limits for both parameters. • MaxMessageLimit [xs:int] FAULTS: • No specific fault codes. ACCESS CLASS: READ_MEDIA ONVIF™– 88 ONVIF Core Spec – Ver. 24.12 9.1.3 Renew An ONVIF compliant device shall support this command if it signals support for [WS-Base Notification] via the MaxNotificationProducers capability. The command shall at least support a Timeout of one minute. A device shall respond both parameters Cur rentTime and TerminationTime as utc using the ‘Z’ indicator. REQUEST: • TerminationTime [wsnt:AbsoluteOrRelativeTimeType] The new relative or absolute termination time. RESPONSE: • CurrentTime [xs:dateTime] The current server time. • TerminationTime [xs:dateTime] The updated TerminationTime for the SubscriptionManager. RESOURCEUNKNOWNFAULTRESPONSE: • Timestamp [xs:dateTime] The pull point reference is invalid • Originator - optional [wsa:EndpointReferenceType] • ErrorCode - optional [xs:any] UNACCEPTABLETERMINATIONTIMEFAULTRESPONSE: • Timestamp [xs:dateTime] The Timeout exceeds the upper limit supported by the device. • Originator - optional [wsa:EndpointReferenceType] • ErrorCode - optional [xs:any] FAULTS: • No specific fault codes. ACCESS CLASS: READ_MEDIA 9.1.4 Unsubscribe The device shall provide the following Unsubscribe command for all SubscriptionManager endpoints returned by the CreatePullPointSubscription command. The command is defined in section 6.1.2 of [OASIS Web Ser vices Base Notification 1.3 [http://docs.oasis-open.org/wsn/wsn-ws_base_notification-1.3-spec-os.pdf]]. This command shall terminate the lifetime of a pull point. REQUEST: This is an empty message. RESPONSE: This is an empty message. ONVIF™– 89 ONVIF Core Spec – Ver. 24.12 RESOURCEUNKNOWNFAULTRESPONSE: • Timestamp [xs:dateTime] The pull point reference is invalid • Originator - optional [wsa:EndpointReferenceType] • ErrorCode - optional [xs:any] FAULTS: • No specific fault codes. ACCESS CLASS: READ_MEDIA 9.1.5 Seek A device supporting persistent notification storage as defined in section 9.1.7 shall provide the following Seek command for all SubscriptionManager endpoints returned by the CreatePullPointSubscription command. On a Seek a pullpoint shall abort any event delivery including any initial states of properties. Furthermore the pullpoint should flush events not already queued for transmission from the transmit queue. After a Seek request a pullpoint shall ignore the behavior described in section 9.6 for properties. A device shall only set the subscription in reverse pull mode if the Reverse argument is present and set to “true”. The UtcTime argument of the Seek request shall be matched against the UtcTime attribute of the notifications in the persistent notification storage. When Seek is used in the forward mode a device shall position the pull pointer to include all NotificationMes sages in the persistent storage with a UtcTime attribute greater than or equal to the Seek argument. When Seek is used in reverse mode a device shall position the pull pointer to include all NotificationMessages in the in the persistent storage with a UtcTime attribute less than or equal to the Seek argument. A device shall not provide information of the initial generate property state as response to a call to the Seek method. REQUEST: • UtcTime [xs:datetime] This message shall be addressed to a PullPoint in order to readjust the pull position: • Reverse - optional [xs:bool] RESPONSE: This is an empty message. FAULTS: • No specific fault codes. ACCESS CLASS: READ_MEDIA 9.1.6 Pull Point Lifecycle Figure 6 depicts the basic operation of a pull point. This chapter states the requirements on the pull point lifecycle. ONVIF™– 90 ONVIF Core Spec – Ver. 24.12 A device shall create a new pull point on each CreatePullPointSubscription command as long as the number of instantiated pull points does not exceed the capability MaxPullPoints. Each pull point shall have a unique endpoint reference to which the client can direct its consecutive operations on the pull point. A pull point shall exist until either its termination time has elapsed or the client has requested its disposal via an Unsubscribe request. There are no requirements regarding persistency of a pull point across a power cycle of a device. 9.1.7 Persistent notification storage To ensure that no notifications are lost by a client a device may store its notifications. The stored notifications can at any time be retrieved by a client. The device shall indicate if its support persistent notification storage with the PersistentNotificationStorage capability. See section 9.8. This specification defines that the interface to the persistent storage allows linear access via the originating message event time. This holds also for events that are delivered out of order in the live streaming case due to e.g. computational delay. The details of what notification and how and where those notifications actually are stored are outside the scope of this specification. Removal policy of stored notifications to get room for new ones is also out of scope. 9.2 Notification Streaming Interface This section defines the transmission of events via RTP streaming packets. For details regarding the configu ration see section “Metadata Configuration“ of the ONVIF Media Service Specification. The following requirements apply if a devices supports transmission of events via RTP streaming packets: • The events shall be encoded as wsnt:NotificationMessage as defined in [WS-BaseNotification] to trans port the Message Payload, the Topic and the ProducerReference. • Multiple instances of the wsnt:NotificationMessage elements can be placed within a metadata docu ment. • Since there is no explicit SubscriptionReference with streaming notifications, the wsnt:NotificationMes sage shall not contain the SubscriptionReference element. 9.3 Basic Notification Interface Section 9.3.1 briefly introduces the Basic Notification Interface of the [WS-BaseNotification] specification. Sec tion 9.3.2 summarizes the mandatory and the optional interfaces of the [WS-BaseNotification] specification. Please refer for a full documentation of the Basic Notification Interface to the [WS-BaseNotification] specifica tion. 9.3.1 Introduction The following logical entities participate in the notification pattern: Client: implements the NotificationConsumer interface. Event Service: implements the NotificationProducer interface. Subscription Manager: implements the BaseSubscriptionManager interface. The Event Service and the Subscription Manager should be instantiated on a device. Typical messages exchanged between the entities are shown in the sequence diagram in Figure 7. First, the client establishes a connection to the Event Service. The client can then subscribe for certain notifications by sending a SubscriptionRequest. If the Event Service accepts the Subscription, it dynamically instantiates a SubscriptionManager representing the Subscription. The Event Service shall return the WS-Endpoint-Address of the SubscriptionManager in the SubscriptionResponse. ONVIF™– 91 ONVIF Core Spec – Ver. 24.12 In order to transmit notifications matching the Subscription, another connection is established from the Event Service to the client. Via this connection, the Event Service sends a one-way Notify message to the Notifica tionConsumer interface of the client. Corresponding notifications can be sent at any time by the Event Service to the client, while the Subscription is active. To control the Subscription, the client directly addresses the SubscriptionManager returned in the Subscrip tionResponse. In the SubscriptionRequest the client can specify a termination time. The SubscriptionManager is automatically destroyed when the termination time is reached. RenewRequests can be initiated by the client in order to postpone the termination time. The client can also explicitly terminate the SubscriptionManager by sending an UnsubscribeRequest. After a successful Unsubscription, the SubscriptionManager no longer exists. The interaction between EventService and SubscriptionManager is not further specified by the [WS-BaseNo tification] and is up to the implementation of the device. Client Event Service SubscriptionRequest Instantiate SubscriptionResponse Notify RenewRequest RenewResponse Subscription Manager Notify UnsubscribeRequest UnsubscribeResponse Figure 7: Sequence diagram for the Base Notification Interface 9.3.2 Requirements This section details those interfaces of the [WS-BaseNotification] that a device shall provide. An ONVIF compliant device shall support the NotificationProducer Interface of the [WS-BaseNotification] if the capability MaxNotificationProducers is non-zero. The device shall support TopicExpression filters with the dialects described in 9.6.3. The support for MessageContent filters is signalled via the GetEventProperties method. If the device does not accept the InitialTerminationTime of a subscription, it shall provide a valid Ini tialTerminationTime within the Fault Message. The device shall be able to provide notifications using the Noti fy wrapper of the [WS-BaseNotification] specification. The SubscriptionPolicy wsnt:UseRaw is optional for the device. Although the [WS-BaseNotification] has CurrentTime and TerminationTime as optional elements in a SubscribeResponse and RenewResponse, an ONVIF compliant device shall list them in both SubscribeRe sponses and RenewResponse. The device may respond to any GetCurrentMessage request with a Fault mes sage indicating that no current message is available on the requested topic. An ONVIF compliant device shall implement the Base Subscription Manager Interface of the [WS-BaseNotifi cation] specification consisting of the Renew and Unsubscribe operations. The Pausable Subscription Manager Interface is optional. The implementation of Subscriptions as WS-Resources is optional. ONVIF™– 92 ONVIF Core Spec – Ver. 24.12 An ONVIF compliant device shall support time values in request parameters that are given in utc with the ‘Z’ indicator and respond all time values as utc including the ‘Z’ indicator
10-10
【事件触发一致性】研究多智能体网络如何通过分布式事件驱动控制实现有限时间内的共识(Matlab代码实现)内容概要:本文围绕多智能体网络中的事件触发一致性问题,研究如何通过分布式事件驱动控制实现有限时间内的共识,并提供了相应的Matlab代码实现方案。文中探讨了事件触发机制在降低通信负担、提升系统效率方面的优势,重点分析了多智能体系统在有限时间收敛的一致性控制策略,涉及系统模型构建、触发条件设计、稳定性与收敛性分析等核心技术环节。此外,文档还展示了该技术在航空航天、电力系统、机器人协同、无人机编队等多个前沿领域的潜在应用,体现了其跨学科的研究价值和工程实用性。; 适合人群:具备一定控制理论基础和Matlab编程能力的研究生、科研人员及从事自动化、智能系统、多智能体协同控制等相关领域的工程技术人员。; 使用场景及目标:①用于理解和实现多智能体系统在有限时间内达成一致的分布式控制方法;②为事件触发控制、分布式优化、协同控制等课题提供算法设计与仿真验证的技术参考;③支撑科研项目开发、学术论文复现及工程原型系统搭建; 阅读建议:建议结合文中提供的Matlab代码进行实践操作,重点关注事件触发条件的设计逻辑与系统收敛性证明之间的关系,同时可延伸至其他应用场景进行二次开发与性能优化。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值