Abstract: Technology for computing number of active servers needed over time in a cloud/compute cluster includes the following operations (not necessarily in the following order): (i) determining the capacity of each VCE provisioned on the cloud against the resource guaranteed to that VCE; (ii) forecasting the resource needs over time using historical requests for each VCE flavor; and (iii) using the forecasted resource needs to determine the required number of future servers at some future time. Some embodiments of the present invention use a formula that accounts for the interplay among various parameter values of the VCE flavors and also the mapping of the needs of VCEs of various flavors to the capabilities of physical resources.

Abstract: Technology for computing number of active servers needed over time in a cloud/compute cluster includes the following operations (not necessarily in the following order): (i) determining the capacity of each VCE provisioned on the cloud against the resource guaranteed to that VCE; (ii) forecasting the resource needs over time using historical requests for each VCE flavor; and (iii) using the forecasted resource needs to determine the required number of future servers at some future time. Some embodiments of the present invention use a formula that accounts for the interplay among various parameter values of the VCE flavors and also the mapping of the needs of VCEs of various flavors to the capabilities of physical resources.

Abstract: Technology for computing number of active servers needed over time in a cloud/compute cluster includes the following operations (not necessarily in the following order): (i) determining the capacity of each VCE provisioned on the cloud against the resource guaranteed to that VCE; (ii) forecasting the resource needs over time using historical requests for each VCE flavor; and (iii) using the forecasted resource needs to determine the required number of future servers at some future time. Some embodiments of the present invention use a formula that accounts for the interplay among various parameter values of the VCE flavors and also the mapping of the needs of VCEs of various flavors to the capabilities of physical resources.

Abstract: Technology for computing number of active servers needed over time in a cloud/compute cluster includes the following operations (not necessarily in the following order): (i) determining the capacity of each VCE provisioned on the cloud against the resource guaranteed to that VCE; (ii) forecasting the resource needs over time using historical requests for each VCE flavor; and (iii) using the forecasted resource needs to determine the required number of future servers at some future time. Some embodiments of the present invention use a formula that accounts for the interplay among various parameter values of the VCE flavors and also the mapping of the needs of VCEs of various flavors to the capabilities of physical resources.

Abstract: A data communication network includes a network client, a network server, and a name caching entity located between the network client and the network server. The network server is coupled to the data communication network by a plurality of network adapters that each have a different network (e.g., Media Access Control (MAC)) address, but share a common logical name. The name caching entity includes a name cache, which stores the common logical name shared by the server's network adapters in association with the network address of one of the network adapters. By reference to the name cache, the name caching entity is able to convert broadcast frames to unicast frames, thereby advantageously reducing broadcast frames in the network.

Abstract: An object oriented representation for sending network protocol requests between a first and a second process in a computer network. In an object oriented implementation of a protocol stack a network definition object is used for defining an interface to a communication endpoint for a client application and a network address object for defining the communication endpoint. The protocol stack is formed by layers of instances of a protocol interface class object for defining protocol interface for a protocol layer in the protocol stack and a protocol layer class object for defining the protocol layers in the stack. The network protocol requests are sent in an instance of one of a set of network operation classes each of which correspond to a method in the protocol interface class. The client requests are wrapped in the network operation object which contains all the necessary information so the request can be presented to the appropriate protocol layer object in the protocol stack.

Abstract: An object oriented protocol interface for establishing a communication path between communication endpoints in a computer network. The generic nature of the interface allows any and several protocol layers to be developed from the same set of protocol class objects. The interface to a communication endpoint for a client application is defined by instantiating a network definition object for the communication endpoint from a network definition class object. The communication endpoint itself is represented by instantiating a network address object from a network address class object. The protocol layers which form the protocol stack are derived from a set of protocol interface objects from a protocol interface class object and a set of protocol layer objects from a protocol layer class object. The objects forming each of the layers in the protocol stack differ in their capabilities according to their respective layer and the protocol which is provided by the protocol stack.

Abstract: A session-oriented local area network (LAN) application and an ISO 8802-2 protocol driver code will cooperate in a new form of connectionless, session-oriented communication called Sideband. At each session start-up time, the LAN Application will communicate with the enhanced ISO 8802-2 based protocol driver on the local system and the LAN Application and the 8802-2 based protocol driver on the remote system to determine if they all support the Sideband. If Sideband is fully supported by both systems, Sideband will be activated for the session. To communicate on a session which has Sideband active, the LAN Application requests that data is to be sent using the Sideband. A check is performed to see if the data meets Sideband criteria. As Sideband is a connectionless medium, the additional code path needed to set up and track timers and to handle the resend attempts are saved in the protocol.