Abstract: The disclosed architecture leverages realtime continuous event processing (CEP) to address using a general input interface framework to import a dynamic set of event types (e.g., assets), and using a declarative, expressive query model to implement monitoring and management tasks on an asset level. This is in contrast to looking separately at single values from static databases and/or realtime streams as is common conventionally. The architecture uses the CEP data model to model assets as realtime event types. Thus, queries can be formulated per asset and not just per single stream. The architecture uses the query capabilities of CEP to formulate asset management and monitoring tasks as standing, declarative queries, and uses the input interface of a CEP platform to correlate data from different data sources with different dynamic properties.

Abstract: The disclosed architecture leverages realtime continuous event processing (CEP) to address using a general input interface framework to import a dynamic set of event types (e.g., assets), and using a declarative, expressive query model to implement monitoring and management tasks on an asset level. This is in contrast to looking separately at single values from static databases and/or realtime streams as is common conventionally. The architecture uses the CEP data model to model assets as realtime event types. Thus, queries can be formulated per asset and not just per single stream. The architecture uses the query capabilities of CEP to formulate asset management and monitoring tasks as standing, declarative queries, and uses the input interface of a CEP platform to correlate data from different data sources with different dynamic properties.

Abstract: The disclosed architecture leverages realtime continuous event processing (CEP) to address using a general input interface framework to import a dynamic set of event types (e.g., assets), and using a declarative, expressive query model to implement monitoring and management tasks on an asset level. This is in contrast to looking separately at single values from static databases and/or realtime streams as is common conventionally. The architecture uses the CEP data model to model assets as realtime event types. Thus, queries can be formulated per asset and not just per single stream. The architecture uses the query capabilities of CEP to formulate asset management and monitoring tasks as standing, declarative queries, and uses the input interface of a CEP platform to correlate data from different data sources with different dynamic properties.

Abstract: The disclosed architecture leverages realtime continuous event processing (CEP) to address using a general input interface framework to import a dynamic set of event types (e.g., assets), and using a declarative, expressive query model to implement monitoring and management tasks on an asset level. This is in contrast to looking separately at single values from static databases and/or realtime streams as is common conventionally. The architecture uses the CEP data model to model assets as realtime event types. Thus, queries can be formulated per asset and not just per single stream. The architecture uses the query capabilities of CEP to formulate asset management and monitoring tasks as standing, declarative queries, and uses the input interface of a CEP platform to correlate data from different data sources with different dynamic properties.

Abstract: The disclosed architecture leverages realtime continuous event processing (CEP) to address using a general input interface framework to import a dynamic set of event types (e.g., assets), and using a declarative, expressive query model to implement monitoring and management tasks on an asset level. This is in contrast to looking separately at single values from static databases and/or realtime streams as is common conventionally. The architecture uses the CEP data model to model assets as realtime event types. Thus, queries can be formulated per asset and not just per single stream. The architecture uses the query capabilities of CEP to formulate asset management and monitoring tasks as standing, declarative queries, and uses the input interface of a CEP platform to correlate data from different data sources with different dynamic properties.

Abstract: The disclosed architecture utilizes realtime continuous event processing (CEP) to address the use of a general input interface framework to import a dynamic set of event types (e.g., assets), and a declarative, expressive query model to implement monitoring and management tasks on an asset level. In one implementation, a realtime event processing system is provided, comprising a synchronization component configured to synchronize realtime event data and static event data of assets, and a realtime merge component configured to merge the synchronized realtime event data and static event data into a realtime event stream using one or more operators. The merged synchronized realtime event data and static event data is queriable as a single event type using a query to return related asset items.

Abstract: Evaluating an expression tree. A method includes, at a first domain, accessing an expression tree. The expression tree comprises a plurality of nested expressions. The plurality of nested expressions spans a plurality of domains. The expressions in the expression tree are expressed in a common format in spite of the different expressions of the expression tree being intended to be evaluated by different domains. At the first domain, the method includes evaluating one or more references to local variables included in the plurality of nested expressions. The method further includes determining that one or more expressions in the plurality of expressions are to be evaluated by a different domain. The method further includes expanding the one or more expressions in the plurality of expressions to be evaluated by different domains to allow the one or more expressions to be evaluated by the different domain.

Abstract: Described are sequence numbers for client-server communication, to control a client's use of server resources. A server grants the client credits, and the client consumes a credit for sending each command to the server. Each credit corresponds to a sequence number, with the set of sequence numbers forming a valid command window. The server enforces that for each received command, the command includes a sequence number that is within the valid command window and that the sequence number has not been used with another command. The server may also maintain a maximum window size, such that clients with credits cannot send a command with a sequence number that beyond a maximum sequence number. When incorporated into a data communication protocol, quality of service, combating denial of service, detection of message loss, division of server resources, secure message signing, and other numerous benefits result.

Abstract: Described are sequence numbers for client-server communication, to control a client's use of server resources. A server grants the client credits, and the client consumes a credit for sending each command to the server. Each credit corresponds to a sequence number, with the set of sequence numbers forming a valid command window. The server enforces that for each received command, the command includes a sequence number that is within the valid command window and that the sequence number has not been used with another command. The server may also maintain a maximum window size, such that clients with credits cannot send a command with a sequence number that beyond a maximum sequence number. When incorporated into a data communication protocol, quality of service, combating denial of service, detection of message loss, division of server resources, secure message signing, and other numerous benefits result.

Abstract: The present invention extends to methods, systems, and computer program products for altering event lifetimes. Embodiments of the invention include using operators in an event-processing framework (algebra) to shorten (or “clip”) the duration of events. An operator can receive a primary event stream, a clip event stream, and condition as parameters. The operator clips the lifetime of an event in the primary stream to the next event in the clip stream that fulfills the condition. Altering event lifetimes can be used to facilitate cleaning event stream state, converting point events to a continuous signal, and creating and annotating session events.

Abstract: Described are sequence numbers for client-server communication, to control a client's use of server resources. A server grants the client credits, and the client consumes a credit for sending each command to the server. Each credit corresponds to a sequence number, with the set of sequence numbers forming a valid command window. The server enforces that for each received command, the command includes a sequence number that is within the valid command window and that the sequence number has not been used with another command. The server may also maintain a maximum window size, such that clients with credits cannot send a command with a sequence number that beyond a maximum sequence number. When incorporated into a data communication protocol, quality of service, combating denial of service, detection of message loss, division of server resources, secure message signing, and other numerous benefits result.

Abstract: The disclosed architecture leverages realtime continuous event processing (CEP) to address using a general input interface framework to import a dynamic set of event types (e.g., assets), and using a declarative, expressive query model to implement monitoring and management tasks on an asset level. This is in contrast to looking separately at single values from static databases and/or realtime streams as is common conventionally. The architecture uses the CEP data model to model assets as realtime event types. Thus, queries can be formulated per asset and not just per single stream. The architecture uses the query capabilities of CEP to formulate asset management and monitoring tasks as standing, declarative queries, and uses the input interface of a CEP platform to correlate data from different data sources with different dynamic properties.

Abstract: The disclosed architecture leverages realtime continuous event processing (CEP) to address using a general input interface framework to import a dynamic set of event types (e.g., assets), and using a declarative, expressive query model to implement monitoring and management tasks on an asset level. This is in contrast to looking separately at single values from static databases and/or realtime streams as is common conventionally. The architecture uses the CEP data model to model assets as realtime event types. Thus, queries can be formulated per asset and not just per single stream. The architecture uses the query capabilities of CEP to formulate asset management and monitoring tasks as standing, declarative queries, and uses the input interface of a CEP platform to correlate data from different data sources with different dynamic properties.

Abstract: Described are sequence numbers for client-server communication, to control a client's use of server resources. A server grants the client credits, and the client consumes a credit for sending each command to the server. Each credit corresponds to a sequence number, with the set of sequence numbers forming a valid command window. The server enforces that for each received command, the command includes a sequence number that is within the valid command window and that the sequence number has not been used with another command. The server may also maintain a maximum window size, such that clients with credits cannot send a command with a sequence number that beyond a maximum sequence number. When incorporated into a data communication protocol, quality of service, combating denial of service, detection of message loss, division of server resources, secure message signing, and other numerous benefits result.

Abstract: Described are sequence numbers for client-server communication, to control a client's use of server resources. A server grants the client credits, and the client consumes a credit for sending each command to the server. Each credit corresponds to a sequence number, with the set of sequence numbers forming a valid command window. The server enforces that for each received command, the command includes a sequence number that is within the valid command window and that the sequence number has not been used with another command. The server may also maintain a maximum window size, such that clients with credits cannot send a command with a sequence number that beyond a maximum sequence number. When incorporated into a data communication protocol, quality of service, combating denial of service, detection of message loss, division of server resources, secure message signing, and other numerous benefits result.

Abstract: The present invention extends to methods, systems, and computer program products for altering event lifetimes. Embodiments of the invention include using operators in an event-processing framework (algebra) to shorten (or “clip”) the duration of events. An operator can receive a primary event stream, a clip event stream, and condition as parameters. The operator clips the lifetime of an event in the primary stream to the next event in the clip stream that fulfills the condition. Altering event lifetimes can be used to facilitate cleaning event stream state, converting point events to a continuous signal, and creating and annotating session events.

Abstract: The present invention extends to methods, systems, and computer program products for altering event lifetimes. Embodiments of the invention include using operators in an event-processing framework (algebra) to shorten (or “clip”) the duration of events. An operator can receive a primary event stream, a clip event stream, and condition as parameters. The operator clips the lifetime of an event in the primary stream to the next event in the clip stream that fulfills the condition. Altering event lifetimes can be used to facilitate cleaning event stream state, converting point events to a continuous signal, and creating and annotating session events.

Abstract: Aspects of the subject matter described herein relate to stream operators. In aspects, a stream event is received. Based on a timestamp associated with the stream event and the number of stream operators that have asked to be activated prior to or at the timestamp, zero or more stream objects are informed of one or more time events and torn down if no longer needed. In addition, a destination stream operator is instantiated, if needed, data (e.g., the timestamp and packet, if any) corresponding to the stream event is provided to a stream operator, output data, if any, is received from the stream operator, and the stream operator is torn down if it no longer needs state data between invocations.

Abstract: Evaluating an expression tree. A method includes, at a first domain, accessing an expression tree. The expression tree comprises a plurality of nested expressions. The plurality of nested expressions spans a plurality of domains. The expressions in the expression tree are expressed in a common format in spite of the different expressions of the expression tree being intended to be evaluated by different domains. At the first domain, the method includes evaluating one or more references to local variables included in the plurality of nested expressions. The method further includes determining that one or more expressions in the plurality of expressions are to be evaluated by a different domain. The method further includes expanding the one or more expressions in the plurality of expressions to be evaluated by different domains to allow the one or more expressions to be evaluated by the different domain.

Abstract: Described is a data communication protocol, in which a client and server negotiate in a manner that does not require the client to retry negotiation when servers are not capable of the client-desired protocol. In one example implementation, the desired protocol is SMB 2.0 or greater. The protocol describes a create command with possibly additional context data attached for built-in extensibility, and a compound command comprising a plurality of related commands or unrelated commands. A multi-channel command requests data transfer on a separate data channel, a signed capability verification may be used to ensure that a secure connection is established, and the protocol provides the ability to transfer extended error data from the server in response to a request.