Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

New SEND

As of Swarm 11.2, SCSP SEND has been expanded to support all feed types and to use the new replication (PUSH) method. For backwards compatibility, the following legacy behavior of SEND is still supported. If a SEND request is missing the new required query arguments, then the behavior described here is in force. (v11.2)

The SCSP SEND method applies to both named and unnamed objects. The SEND request allows explicit transmission of a single object from a source cluster to a remote one, such as for keeping two clusters immediately synchronized. This feature is best used with a replication feed, which acts as a catch-up mechanism if the intracluster network is down or the SEND command should fail. 

SEND Requests

SEND can only be used by an admin user. With a SEND request, Swarm performs the appropriate GET/retrieve in the destination cluster to verify whether the object already exists there. 

Note

You issue SEND directly on a Swarm node in the source cluster, to transfer a single object to a destination cluster. Do not send the request to a Gateway or other proxy.

You use the following headers with SEND requests:

Castor-System-Cluster

required

The value of the cluster.name setting of the destination cluster.

Castor-System-Target

required

The IP:port of a node or reverse proxy of the destination cluster.

Castor-System-Auth

optional

The username:password for an administrative account on the remote cluster,
only if it differs from the source cluster.

Responses to SEND

The request returns information about that request in the body of the response. SEND behaves like a HEAD request, with the headers of the response resembling that of a HEAD request. 

Important

The SEND response is chunked transfer encoded, so the client of the SEND request must be prepared for chunked transfer encoding. The response body may contain additional leading newlines sent incrementally, which keeps the connection open in long requests.

The most common response codes are these:

  • 201 - the object has been transferred successfully

  • 409 - the object already exists in the destination cluster

Example of SEND

The following request transfers the object to the "dr" cluster at 192.168.1.13, with a 201 in that cluster:

curl -i -X SEND --location-trusted 
	-H "Castor-System-Cluster: dr" 
	-H "Castor-System-Target: 192.168.1.13:80" 	
	--anyauth -u admin:ourpwdofchoicehere 
	"http://192.168.1.12:80/97f7149dec6cbc0aa1e9425688158969?alias&admin"

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest realm="CAStor administrator", nonce="0c6da76911cbf5cd495afbb0c66e6d9a", 
	opaque="3e894c0cf7c1ad980e1fd46320307f1a", stale=false, qop="auth", algorithm=MD5
WWW-Authenticate: Basic realm="CAStor administrator"
Content-Length: 53
Content-Type: text/html
Date: Thu, 18 Apr 2016 15:13:00 GMT
Server: CAStor Cluster/9.1.0
Allow: HEAD, HOLD, GET, SEND, PUT, RELEASE, POST, COPY, GEN, APPEND, DELETE

HTTP/1.1 200 OK
Castor-System-Alias: 97f7149dec6cbc0aa1e9425688158969
Castor-System-Cluster: baker
Castor-System-Created: Thu, 18 Apr 2016 15:10:40 GMT
Castor-System-Version: 1366297840.592
Content-type: text/xml
Last-Modified: Thu, 18 Apr 2013 15:10:40 GMT
transfer-encoding: chunked
Etag: "166e93908fc32ffb5f55beb7ed531ba1"
Volume: 8f61a5127994365e3dd89bbf83aa0964
Volume-Hint: b79cf7801f71f545c62957ae5659299b
Date: Thu, 18 Apr 2016 15:13:01 GMT
Server: CAStor Cluster/9.1.0

Remote cluster returned: 201
  • No labels