Swap:Custom Protocol - Revision history

Toaster at 22:00, 18 February 2010

2010-02-18T22:00:05Z

← Older revision		Revision as of 22:00, 18 February 2010
Line 45:		Line 45:
	# Connect to server		# Connect to server
	# Start SSL Tunnel		# Start SSL Tunnel
	# Client: Send ~~user/pass/ssl status (AUTH_REQUEST)~~		# Server: Send SASL_MECHANISMS
	# Server: send ~~AUTH_RESPONSE w~~/ ~~ssl confirmation.~~		# Client: Send SASL_REQUEST
			# Server: send SASL_RESPONSE. (repeat req/response)
	# On success, client and server toggle SSL state.		# On success, client and server toggle SSL state.
	# Client ~~is sent a list of appropriate file groups~~		# Client requests whatever startup junk it needs

	Once a client authenticated, it may not re-authenticate as a different user, a reconnect is required.		Once a client authenticated, it may not re-authenticate as a different user, a reconnect is required.

	The SwapAuthFilter filter intercepts authentication requests and handles enabling/disabling ssl. In addition, it ensures that no authentication information is delivered to the higher level handler, and that no requests are processed until a client has successfully authenticated.		The SwapAuthFilter filter intercepts authentication requests and handles enabling/disabling ssl. In addition, it ensures that no authentication information is delivered to the higher level handler, and that no requests are processed until a client has successfully authenticated.

Toaster at 04:40, 16 February 2010

2010-02-16T04:40:17Z

← Older revision		Revision as of 04:40, 16 February 2010
Line 52:		Line 52:
	Once a client authenticated, it may not re-authenticate as a different user, a reconnect is required.		Once a client authenticated, it may not re-authenticate as a different user, a reconnect is required.

	The SwapAuthFilter filter intercepts authentication requests and handles enabling/disabling ssl. In addition, it ensures that no authentication information is delivered to the higher level handler		The SwapAuthFilter filter intercepts authentication requests and handles enabling/disabling ssl. In addition, it ensures that no authentication information is delivered to the higher level handler, and that no requests are processed until a client has successfully authenticated.

Toaster at 04:35, 16 February 2010

2010-02-16T04:35:45Z

← Older revision		Revision as of 04:35, 16 February 2010
Line 51:		Line 51:

	Once a client authenticated, it may not re-authenticate as a different user, a reconnect is required.		Once a client authenticated, it may not re-authenticate as a different user, a reconnect is required.

			The SwapAuthFilter filter intercepts authentication requests and handles enabling/disabling ssl. In addition, it ensures that no authentication information is delivered to the higher level handler

Toaster at 04:30, 16 February 2010

2010-02-16T04:30:38Z

← Older revision		Revision as of 04:30, 16 February 2010
Line 3:		Line 3:
	==Mina==		==Mina==
	SWAP uses mina to manage socket communication. Protocol decoding is handled through a set of filters and a final handler to dispatch command.		SWAP uses mina to manage socket communication. Protocol decoding is handled through a set of filters and a final handler to dispatch command.

			The SwapProtocolEncoder/Decoder filters translates messages to and from SwapMessages. These SwapMessages are delivered to the registered mina handler. The NetworkIOHandler class provides a simple mechanism for decoding SwapMessages and dispatching multiple calls corresponding to the type of message received.

	==Wire-level message Structure==		==Wire-level message Structure==

Toaster at 04:27, 16 February 2010

2010-02-16T04:27:17Z

← Older revision		Revision as of 04:27, 16 February 2010
Line 46:		Line 46:
	# Server: send AUTH_RESPONSE w/ ssl confirmation.		# Server: send AUTH_RESPONSE w/ ssl confirmation.
	# On success, client and server toggle SSL state.		# On success, client and server toggle SSL state.
			# Client is sent a list of appropriate file groups

			Once a client authenticated, it may not re-authenticate as a different user, a reconnect is required.

Toaster at 04:21, 16 February 2010

2010-02-16T04:21:32Z

← Older revision		Revision as of 04:21, 16 February 2010
Line 39:		Line 39:

	==Authentication==		==Authentication==
	Due to how swap authenticates against LDAP, clients must supply a clear-text username and password to the server. To secure this, an ssl tunnel is established during the initial connection to a swap server. ~~Once~~ authentication ~~has finished~~ the ~~client may tell~~ the server to disable ~~the tunnel~~.		Due to how swap authenticates against LDAP, clients must supply a clear-text username and password to the server. To secure this, an ssl tunnel is established during the initial connection to a swap server. As part of authentication a client will instruct the server whether or not it should keep the ssl connection enabled, disable it, or let server decide. The server will respond with an AUTH_RESPONSE indicating success/failure and whether SSL will remain enabled. The server is able to override a clients request to disable or keep ssl enabled.

			# Connect to server
			# Start SSL Tunnel
			# Client: Send user/pass/ssl status (AUTH_REQUEST)
			# Server: send AUTH_RESPONSE w/ ssl confirmation.
			# On success, client and server toggle SSL state.

Toaster at 04:14, 16 February 2010

2010-02-16T04:14:19Z

← Older revision		Revision as of 04:14, 16 February 2010
Line 10:		Line 10:
	* short - message type (See MessageType enum)		* short - message type (See MessageType enum)
	* short - repetitions of message		* short - repetitions of message
	( byte[] - content		* byte[] - content

	Content is the list of packed messages. Each message is composed of a set of primitive segments (long, string, uuid, long[], etc). What segments comprise a message are described in the MessageType enum. Allowable types of segments are defined in MessageSegment.		Content is the list of packed messages. Each message is composed of a set of primitive segments (long, string, uuid, long[], etc). What segments comprise a message are described in the MessageType enum. Allowable types of segments are defined in MessageSegment.

Toaster at 04:14, 16 February 2010

2010-02-16T04:14:02Z

← Older revision		Revision as of 04:14, 16 February 2010
Line 7:		Line 7:
	Each SWAP command is sent as a list of a single SWAP message. This is done to allow efficient packing of small messages (ie, results of stat, etc)		Each SWAP command is sent as a list of a single SWAP message. This is done to allow efficient packing of small messages (ie, results of stat, etc)

	Int - size of message (type + reps + content)		* Int - size of message (type + reps + content)
	short - message type (See MessageType enum)		* short - message type (See MessageType enum)
	short - repetitions of message		* short - repetitions of message
	byte[] - content		( byte[] - content

	Content is the list of packed messages. Each message is composed of a set of primitive segments (long, string, uuid, long[], etc). What segments comprise a message are described in the MessageType enum. Allowable types of segments are defined in MessageSegment.		Content is the list of packed messages. Each message is composed of a set of primitive segments (long, string, uuid, long[], etc). What segments comprise a message are described in the MessageType enum. Allowable types of segments are defined in MessageSegment.

	For example, the GET_PATH_DETAILS request has the following structure:		For example, the GET_PATH_DETAILS request has the following structure:
	UUID - uuid of file group		* UUID - uuid of file group
	STRING[] - list of paths for details w/in that file group.		* STRING[] - list of paths for details w/in that file group.

	To request for just one group the message would have the following information:		To request for just one group the message would have the following information:
	size=message size		* size=message size
	type=13,		* type=13,
	reps=1		* reps=1
	UUID of file group		* UUID of file group
	"path1","path2"		* "path1","path2"

	Since we can issue multiple requests of the same message, in one message, we could include a request for files from two different groups. This message would look slightly different:		Since we can issue multiple requests of the same message, in one message, we could include a request for files from two different groups. This message would look slightly different:

	size=message size		* size=message size
	type=13		* type=13
	reps=2		* reps=2
	UUID of group 1		* UUID of group 1
	"path1","path2"		* "path1","path2"
	UUID of group 2		* UUID of group 2
	"path3","path4"		* "path3","path4"

	This packing and unpacking is handled by the two mina filters, SwapProtocolEncoder and SwapProtocolDecoder. These two filters encode/decode messages to and from an array of SwapMessage. A SwapMessage is a simple container holding the type of message along w/ the an array of Objects representing the message content. The size of the content is equal to the number of segments in a message * the number of repetitions in a message.		This packing and unpacking is handled by the two mina filters, SwapProtocolEncoder and SwapProtocolDecoder. These two filters encode/decode messages to and from an array of SwapMessage. A SwapMessage is a simple container holding the type of message along w/ the an array of Objects representing the message content. The size of the content is equal to the number of segments in a message * the number of repetitions in a message.

Toaster at 04:12, 16 February 2010

2010-02-16T04:12:49Z

New page

SWAP has a custom protocol available that is used for management and inter-node communication. This is a persistent socket connection between nodes. This is not run over http due to the small size of most messages and overhead in establishing a connection for each message.

==Mina==
SWAP uses mina to manage socket communication. Protocol decoding is handled through a set of filters and a final handler to dispatch command.

==Wire-level message Structure==
Each SWAP command is sent as a list of a single SWAP message. This is done to allow efficient packing of small messages (ie, results of stat, etc)

Int - size of message (type + reps + content)
short - message type (See MessageType enum)
short - repetitions of message
byte[] - content

Content is the list of packed messages. Each message is composed of a set of primitive segments (long, string, uuid, long[], etc). What segments comprise a message are described in the MessageType enum. Allowable types of segments are defined in MessageSegment.

For example, the GET_PATH_DETAILS request has the following structure:
UUID - uuid of file group
STRING[] - list of paths for details w/in that file group.

To request for just one group the message would have the following information:
size=message size
type=13,
reps=1
UUID of file group
"path1","path2"

Since we can issue multiple requests of the same message, in one message, we could include a request for files from two different groups. This message would look slightly different:

size=message size
type=13
reps=2
UUID of group 1
"path1","path2"
UUID of group 2
"path3","path4"

This packing and unpacking is handled by the two mina filters, SwapProtocolEncoder and SwapProtocolDecoder. These two filters encode/decode messages to and from an array of SwapMessage. A SwapMessage is a simple container holding the type of message along w/ the an array of Objects representing the message content. The size of the content is equal to the number of segments in a message * the number of repetitions in a message.

==Authentication==
Due to how swap authenticates against LDAP, clients must supply a clear-text username and password to the server. To secure this, an ssl tunnel is established during the initial connection to a swap server. Once authentication has finished the client may tell the server to disable the tunnel.