Abstract: Methods, systems, and computer-readable media for facilitating coordination between a fabric controller of a cloud-computing network and a service application running in the cloud-computing network are provided. Initially, an update domain (UD) that includes role instance(s) of the service application is selected, where the service application represents a stateful application is targeted for receiving a tenant job executed thereon. The process of coordination involves preparing the UD for execution of the tenant job, disabling the role instance(s) of the UD to an offline condition, allowing the tenant job to execute, and restoring the role instance(s) to an online condition upon completing execution of the tenant job.

Abstract: Goal state indicators can be communicated from a fabric controller of a computer cluster to each of multiple compute instances in the computer cluster managed by the fabric controller. The goal state indicators can be formatted according to a structured protocol that defines multiple possible goal states. Additionally, status reports can be received from the compute instances. Each of the status reports can indicate a current state of one of the compute instances relative to a goal state previously indicated in a goal state indicator communicated to that one of the compute instances.

Abstract: A form of multicast, referred to as “on-demand multicast,” provides a methodology that allows for “on demand” multicasting of data. On-demand multicast allows clients to join or leave a transmission at any point. There is no transmission session start or end time—the session is continuously available, although data is not necessarily continuously transmitted. Data blocks missed by late-joining clients are retransmitted per amalgamated client requests through multiple transmission cycles until all clients that have joined the transmission session receive all content. Once a client has received all data blocks comprising the content for the session, the client may exit the ongoing session.

Abstract: A form of multicast, referred to as “on-demand multicast,” provides a methodology that allows for “on demand” multicasting of data. On-demand multicast allows clients to join or leave a transmission at any point. There is no transmission session start or end time—the session is continuously available, although data is not necessarily continuously transmitted. Data blocks missed by late-joining clients are retransmitted per amalgamated client requests through multiple transmission cycles until all clients that have joined the transmission session receive all content. Once a client has received all data blocks comprising the content for the session, the client may exit the ongoing session.

Abstract: A slow client that participates in a reliable multicast session may reduce the speed of data transfer for other clients in the session. A multicast server can mitigate the effect of a slow client by identifying and disconnecting one or more clients that are slowing down the session, or by using other criteria to identify clients to be disconnected. The server may monitor the performance of clients in the session based on factors such as the rate at which each of the clients is able to receive data, the number or rate of packets lost by a client, the amount of time that a client has spent as the slowest client in the session, the identity of a particular client, etc. A client that has been identified for disconnection based on the server's detection efforts, or that has been identified by an administrator, may be disconnected.

Abstract: Applications, such as cloud services, may be deployed within a network environment (e.g., a cloud computing environment). Unfortunately, when the applications are instantiated within the network environment, they have the ability to compromise the security of other applications and/or the infrastructure of the network environment. Accordingly, as provided herein, a security scheme may be applied to a network environment within which an application is to be instantiated. The security scheme may comprise one or more security layers (e.g., virtual machine level security, application level security, operating system level security, etc.) derived from an application service model describing the application and/or resources allocated to the application.

Abstract: Methods, systems, and computer-readable media for deploying an updated image to nodes propagated throughout a distributed computing platform are provided. Upon receiving an indication to install a patch to an operating system residing on the nodes, an existing image of the operating system is accessed at a staging service. The staging service generates the updated image by applying the patch to the existing image. The process of applying the patch includes mounting the existing image of the operating system to a virtual machine, copying the patch to the mounted existing image, setting a command within the existing image that executes upon activating the virtual machine, and activating the virtual machine, thereby executing the command. This directs the patch to be installed. The updated image is pushed to the nodes. The nodes are configured to utilize the updated image as the operating system without performing an individual installation of the patch.

Abstract: A computing device is configured to assemble and boot an operating system in stages. A primary boot image is first obtained that includes enough of the operating system to support basic networking. Once the primary boot image is obtained, either through download or from storage on the device, the primary boot image is booted to start the networking. Once the networking is active, the boot activity for the device is suspended and one or more secondary operating system images are downloaded by the device. These images are chained to the primary boot image thereby creating a single/cohesive operating system. These secondary operating system images are successively booted in “stages” with each successive stage building upon the functionality of the previous stage.

Abstract: A control protocol is used to deploy and install an operating system image on a client. The data structure of the control protocol includes an operation code corresponding to an operation associated with the deployment and installation of the operating system image on the client. When a server receives a request packet from the client, the server parses the request packet and sends the parsed request packet to a provider. The provider then executes the operation associated with the operation code and generates a return value. The return value is sent to the server. The server then composes a reply packet including the return value and transmits the reply packet to the client.

Abstract: File system write filters are provided which can selectively permit or prevent data from being written-protected storage media. The write filter utilized volatile cache memory to store data that is requested to be written to storage media by applications programming interface function calls. In one aspect, if the particular data is requested to be written to a file that is a file identified on the file exclusion list, the data can be written to the file in non-volatile storage. Otherwise, the particular data is written to volatile cache memory. In another aspect, the write filters can be utilized on computing devices to create a stateless computing device wherein data is written to volatile cache memory in response to write function calls. Upon rebooting, any data that was saved to the volatile cache memory is discarded and the computing device is restored to its original state.

Abstract: A control protocol is used to deploy and install an operating system image to a client. The data structure of the protocol includes an operation code corresponding to an operation associated with the deployment and installation of an operating system image to a client. When the server receives a request packet, the server parses the request and sends the parsed request to the provider. The provider then executes the operation associated with the operation code and generates a return value. The return value is sent to the server. The server then composes a rely packet including the return value and transmits the reply packet to the client.

Abstract: Multiple providers of application logic are used to deploy and install an operating system image to a client. Each provider configured with application logic designed to deploy and install an operating system image to a distinct class of clients. When a server receives a request associated with deploying and installing the operating system image from the client, the server sends the request to the provider configured with application logic designed to deploy and install an operating system to the client.

Abstract: A method includes loading an optical media image representing the content of a physical optical media device from an optical media image source into random access memory (RAM) and emulating the physical optical media device using the optical media image. The optical media image is in an optical media format. A system includes an optical media image stored in random access memory (RAM), the optical media image being in an optical media format, and including operating system (OS) code executable by a microprocessor. A RAM disk program accesses the optical media image according to the optical media format.

Abstract: Approving a client to boot in a pre-boot execution environment. A request is received from the client to boot the client by a computing device. The request includes device information associated with the client. A data store having a collection of known device information is queried in response to the received request. The request is stored, and it is determined whether to execute the received request by evaluating the device information in the stored request. The received request is responded to as a function of the evaluated device information.

Abstract: Identifying characteristics of a client in a pre-boot environment. A packet is received from the client. The packet includes a request for an image to boot the client by a computing device. An application is transmitted from the computing device to the client in response to the received packet. The client executes the transmitted application. A response is received from the application executed by the client. The characteristics of the client are determined based on the received response. An image to boot the client is transmitted, and the transmitted image is a function of the determined characteristics.

Abstract: Software deployment to server nodes within large-scale networked systems is provided using image-based deployment. A mostly immutable image is provided at a central service and transferred from the central service to the server nodes. The image includes a base image, which is immutable, and a delta image, which is writable and provides role-specific and/or node-specific state to the base portion. When a server node receives an image from the central server, the server node stores the image intact without installation. The server node then runs software directly from the stored image.

Abstract: A slow client that participates in a reliable multicast session may reduce the speed of data transfer for other clients in the session. A multicast server can mitigate the effect of a slow client by identifying and disconnecting one or more clients that are slowing down the session, or by using other criteria to identify clients to be disconnected. The server may monitor the performance of clients in the session based on factors such as the rate at which each of the clients is able to receive data, the number or rate of packets lost by a client, the amount of time that a client has spent as the slowest client in the session, the identity of a particular client, etc. A client that has been identified for disconnection based on the server's detection efforts, or that has been identified by an administrator, may be disconnected.

Abstract: A multicast content provider operates on a multicast server in conjunction with a multicast transmission protocol that is independent of the content data transmitted and allows extensibility in the content provider to distribute any type of content. The content provider module is designed to find, read, write, and transform particular types of data into a form acceptable for transmission by the transmission protocol on the multicast server. The transmission protocol is agnostic to the type, size, format, or location of the data file. The content provider module manages these issues so that the transmission protocol does not have to. This relationship between the content provider module and the transmission protocol establishes a “generic” multicast solution, capable of complete flexibility with regard to content delivery.

Abstract: A form of multicast, referred to as “on-demand multicast,” provides a methodology that allows for “on demand” multicasting of data. On-demand multicast allows clients to join or leave a transmission at any point. There is no transmission session start or end time—the session is continuously available, although data is not necessarily continuously transmitted. Data blocks missed by late-joining clients are retransmitted per amalgamated client requests through multiple transmission cycles until all clients that have joined the transmission session receive all content. Once a client has received all data blocks comprising the content for the session, the client may exit the ongoing session.

Abstract: A computing device is configured to assemble and boot an operating system in stages. A primary boot image is first obtained that includes enough of the operating system to support basic networking. Once the primary boot image is obtained, either through download or from storage on the device, the primary boot image is booted to start the networking. Once the networking is active, the boot activity for the device is suspended and one or more secondary operating system images are downloaded by the device. These images are chained to the primary boot image thereby creating a single/cohesive operating system. These secondary operating system images are successively booted in “stages” with each successive stage building upon the functionality of the previous stage.