Abstract: The present invention provides, among other things, methods of treating pruritic or inflammatory skin diseases or disorders, or pruritus associated with a disease or disorder, with an anti-OSMR? antibody, including methods of treating pruritus, associated with atopic dermatitis, chronic kidney disease-associated pruritus, uremic pruritus or prurigo nodularis, chronic idiopathic pruritus, chronic idiopathic urticaria, chronic spontaneous urticaria, cutaneous amyloidosis, lichen simplex chronicus, plaque psoriasis, lichens planus, inflammatory ichthyosis, mastocytosis and bullous pemphigoid, comprising a step of administering to a subject in need of treatment an anti-OSMR? antibody at a therapeutically effective dose and an administration interval for a treatment period sufficient to improve, stabilize or reduce one or more symptoms of the disease or disorder relative to a control.

Abstract: Techniques for facilitating load balancing in distributed computing systems are disclosed herein. In one embodiment, a method includes receiving, at a destination server, a request packet from a load balancer via the computer network requesting a remote direct memory access (“RDMA”) connection between an originating server and one or more other servers selectable by the load balancer. The method can also include configuring, at the destination server, a rule for processing additional packets transmittable to the originating server via the RDMA connection based on the received reply packet. The rule is configured to encapsulate an outgoing packet transmittable to the originating server with an outer header having a destination field containing a network address of the originating server and a source field containing another network address of the destination server.

Abstract: Cross-Site Request Forgery attacks are mitigated by a CSRF mechanism executing at a computing entity. The CSRF mechanism is operative to analyze information associated with an HTTP request for a resource. The HTTP request typically originates as an HTTP redirect from another computing entity, such as an enterprise Web portal. Depending on the nature of the information associated with the HTTP request, the HTTP request may be rejected because the CSRF mechanism determines that the request is or is likely associated with a CSRF attack. To facilitate this determination, the approach leverages a new type of “referer” attribute, a trustedReferer, which indicates that the request originates from a server that has previously established a trust relationship with the site at which the CSRF mechanism executes. The trustedReferer attribute typically is set by the redirecting entity, and in an HTTP request header field dedicated for that attribute.

Abstract: A new management node associated with a new rack sends at least a public key of the new management node to a first management node associated with a first rack and a plurality of autonomous management nodes. The first management node sends the new management node an access token trusted by at least a portion of the plurality of autonomous management nodes and a set of public keys corresponding to at least a portion of the plurality of autonomous management nodes. The new management node can send its public key and the access token to at least a portion of the plurality of autonomous management nodes. In response, the new management node can establish a mutual trust relationship with at least a portion of the plurality of autonomous management nodes.

Abstract: A construct having a plurality of distributed resources can include a portion of a second rack having a plurality of computing devices controlled by a second management node. The second management node can determine it contains insufficient construct data such as user data, group data, resource data, or authorization policy data to execute an operation associated with the construct. The second management node can synchronize at least a portion of construct data with a first management node. The first management node can be associated with the construct and a mutual trust relationship can exist between the first management node and the second management node. The first management node and the second management node can comprise autonomous management nodes capable of functioning independent of the network.

Abstract: A new management node associated with a new rack sends at least a public key of the new management node to a first management node associated with a first rack and a plurality of autonomous management nodes. The first management node sends the new management node an access token trusted by at least a portion of the plurality of autonomous management nodes and a set of public keys corresponding to at least a portion of the plurality of autonomous management nodes. The new management node can send its public key and the access token to at least a portion of the plurality of autonomous management nodes. In response, the new management node can establish a mutual trust relationship with at least a portion of the plurality of autonomous management nodes.

Abstract: Techniques for facilitating load balancing in distributed computing systems are disclosed herein. In one embodiment, a method includes receiving, at a destination server, a request packet from a load balancer via the computer network requesting a remote direct memory access (“RDMA”) connection between an originating server and one or more other servers selectable by the load balancer. The method can also include configuring, at the destination server, a rule for processing additional packets transmittable to the originating server via the RDMA connection based on the received reply packet. The rule is configured to encapsulate an outgoing packet transmittable to the originating server with an outer header having a destination field containing a network address of the originating server and a source field containing another network address of the destination server.

Abstract: A new management node associated with a new rack sends at least a public key of the new management node to a first management node associated with a first rack and a plurality of autonomous management nodes. The first management node sends the new management node an access token trusted by at least a portion of the plurality of autonomous management nodes and a set of public keys corresponding to at least a portion of the plurality of autonomous management nodes. The new management node can send its public key and the access token to at least a portion of the plurality of autonomous management nodes. In response, the new management node can establish a mutual trust relationship with at least a portion of the plurality of autonomous management nodes.

Abstract: A first management node of a first rack can be registered to a shared file storage system by establishing a mutual trust relationship between the first management node and the shared file storage system. The first management node can access a plurality of respective public keys and a plurality of respective certificates of authority that are stored in the shared file storage system and associated with a plurality of respective registered management nodes. The first management node can store a public key and a certificate of authority in the shared file storage system. The first management node can form mutual trust relationships with other registered management nodes. The first management node can validate authenticity of messages received from registered management nodes of the plurality of registered management nodes using a respective public key and a respective certificate of authority associated with a respective registered management node sending a message.

Abstract: A new management node associated with a new rack sends at least a public key of the new management node to a first management node associated with a first rack and a plurality of autonomous management nodes. The first management node sends the new management node an access token trusted by at least a portion of the plurality of autonomous management nodes and a set of public keys corresponding to at least a portion of the plurality of autonomous management nodes. The new management node can send its public key and the access token to at least a portion of the plurality of autonomous management nodes. In response, the new management node can establish a mutual trust relationship with at least a portion of the plurality of autonomous management nodes.

Abstract: Cross-Site Request Forgery attacks are mitigated by a CSRF mechanism executing at a computing entity. The CSRF mechanism is operative to analyze information associated with an HTTP request for a resource. The HTTP request typically originates as an HTTP redirect from another computing entity, such as an enterprise Web portal. Depending on the nature of the information associated with the HTTP request, the HTTP request may be rejected because the CSRF mechanism determines that the request is or is likely associated with a CSRF attack. To facilitate this determination, the approach leverages a new type of “referer” attribute, a trustedReferer, which indicates that the request originates from a server that has previously established a trust relationship with the site at which the CSRF mechanism executes. The trustedReferer attribute typically is set by the redirecting entity, and in an HTTP request header field dedicated for that attribute.

Abstract: A first management node of a first rack can be registered to a shared file storage system by establishing a mutual trust relationship between the first management node and the shared file storage system. The first management node can access a plurality of respective public keys and a plurality of respective certificates of authority that are stored in the shared file storage system and associated with a plurality of respective registered management nodes. The first management node can store a public key and a certificate of authority in the shared file storage system. The first management node can form mutual trust relationships with other registered management nodes. The first management node can validate authenticity of messages received from registered management nodes of the plurality of registered management nodes using a respective public key and a respective certificate of authority associated with a respective registered management node sending a message.

Abstract: A construct having a plurality of distributed resources can include a portion of a second rack having a plurality of computing devices controlled by a second management node. The second management node can determine it contains insufficient construct data such as user data, group data, resource data, or authorization policy data to execute an operation associated with the construct. The second management node can synchronize at least a portion of construct data with a first management node. The first management node can be associated with the construct and a mutual trust relationship can exist between the first management node and the second management node. The first management node and the second management node can comprise autonomous management nodes capable of functioning independent of the network.

Abstract: A load balancer system is described herein which uses one or more switch-based hardware multiplexers, each of which performs a multiplexing function. Each such hardware multiplexer operates based on an instance of mapping information associated with a set of virtual IP (VIP) addresses, corresponding to a complete set of VIP addresses or a portion of the complete set. That is, each hardware multiplexer operates by mapping VIP addresses that correspond to its set of VIP addresses to appropriate direct IP (DIP) addresses. In another implementation, the load balancer system may also use one or more software multiplexers that perform a multiplexing function with respect to the complete set of VIP addresses. A main controller can generate one or more instances of mapping information, and then load the instance(s) of mapping information on the hardware multiplexer(s), and the software multiplexer(s) (if used).