Abstract: Techniques are disclosed for validating the resiliency of a networked application made available using a distributed computing infrastructure. In one embodiment, a latency monitoring application observes each active application component and at specified or unspecified intervals, selects one and introduces latency or error messages in one or more messages emanating from the selected active application component. The latency monitoring application then measures the effect of the latency or error messages on other active application components that are dependent on the affected active application component. By observing the effects of the failed server on the rest of the network application, a provider can ensure that each component can tolerate any unexpected latency or error conditions with the distributed computing infrastructure.

Abstract: Techniques are disclosed for validating the resiliency of a networked application made available using a distributed computing infrastructure. In one embodiment, a latency monitoring application observes each active application component and at specified or unspecified intervals, selects one and introduces latency or error messages in one or more messages emanating from the selected active application component. The latency monitoring application then measures the effect of the latency or error messages on other active application components that are dependent on the affected active application component. By observing the effects of the failed server on the rest of the network application, a provider can ensure that each component can tolerate any unexpected latency or error conditions with the distributed computing infrastructure.

Abstract: Techniques are disclosed for validating the resiliency of a networked application made available using a distributed computing infrastructure. In one embodiment, a latency monitoring application observes each active application component and at specified or unspecified intervals, selects one and introduces latency or error messages in one or more messages emanating from the selected active application component. The latency monitoring application then measures the effect of the latency or error messages on other active application components that are dependent on the affected active application component. By observing the effects of the failed server on the rest of the network application, a provider can ensure that each component can tolerate any unexpected latency or error conditions with the distributed computing infrastructure.

Abstract: Techniques are disclosed for validating the resiliency of a networked application made available using a distributed computing infrastructure. In one embodiment, a latency monitoring application observes each active application component and at specified or unspecified intervals, selects one and introduces latency or error messages in one or more messages emanating from the selected active application component. The latency monitoring application then measures the effect of the latency or error messages on other active application components that are dependent on the affected active application component. By observing the effects of the failed server on the rest of the network application, a provider can ensure that each component can tolerate any unexpected latency or error conditions with the distributed computing infrastructure.

Abstract: A device, system, and method are directed towards determining network information. A network address is determined for a possible proxy. A determination is made whether a port on the possible proxy is open and/or if the port supports an HyperText Transfer Protocol (HTTP) proxy request. A request is sent to the possible proxy over the port, the request being configured to be forwarded to a network device. A type of the possible proxy is determined based in part on a behavior of the network device. The behavior may indicate whether the request is received by the network device, or whether the possible proxy obscures an origin of the request. The proxy type may include whether the possible proxy is a non-proxy, an anonymous-proxy, a controlled-proxy, and/or an open-proxy. Various types of network analysis may then be performed using the possible proxy and the determined proxy type.

Abstract: A device, system, and method are directed towards determining network information. A network address is determined for a possible proxy. A determination is made whether a port on the possible proxy is open and/or if the port supports an HyperText Transfer Protocol (HTTP) proxy request. A request is sent to the possible proxy over the port, the request being configured to be forwarded to a network device. A type of the possible proxy is determined based in part on a behavior of the network device. The behavior may indicate whether the request is received by the network device, or whether the possible proxy obscures an origin of the request. The proxy type may include whether the possible proxy is a non-proxy, an anonymous-proxy, a controlled-proxy, and/or an open-proxy. Various types of network analysis may then be performed using the possible proxy and the determined proxy type.

Abstract: An improved system and method is disclosed for transparent and agent-less remote access to CIMOMs and the management information they provide, regardless of the CIMOM communication protocol implemented. Differences between disparate CIM object manager (CIMOM) implementations are abstracted to provide clients a common interface when accessing information management data. A protocol layer is implemented that comprises protocol adapters that are dynamically loaded to handle communications with WBEM implementation. Target CIMOM protocols are discovered on-line by the protocol layer, which provides the appropriate interface to transparently convey management information from the CIMOM to the abstraction layer.

Abstract: A system and method is disclosed for the dynamic load of protocol adapters in a client-server environment. In operation, the client and a coupled data server may have different communications protocols. At startup or run-time, the client accesses a protocol factory and retrieves a protocol adapter that is operable to convert communications between the protocol of the data server and the protocol of the client. The identification of the protocol adapter from the protocol factory is made by testing each protocol adapter on a serial basis to identify the first protocol adapter that is able to convert communications between the protocol of the data server and the protocol of the client.