Commits

bitblaze committed ec22e39 Merge

Merge branch 'master' of bitbucket.org:cometpeak/ringmaster

Comments (0)

Files changed (1)

doc/438-report/final-report.tex

 
 \section{Server Framework}
 
-The purpose of each ringmaster server is to run a Paxos consensus protocol in conjunction with the other servers, which we call peers. To accomplish this, each server needs to perform the following roles: 1) establish a network connection with all other servers and the client. 2) receive requests from thr client. 3) forward client requests to thr paxos protocol and participate in consensus with other servers. 4) respond to the client with thr results of the proposal.
+The purpose of each ringmaster server is to run a Paxos consensus protocol in conjunction with the other servers, which we call peers. To accomplish this, each server needs to perform the following roles: 1) establish a network connection with all other servers and the client. 2) receive requests from the client. 3) forward client requests to the paxos protocol and participate in consensus with other servers. 4) respond to the client with the results of the proposal.
 
-The ringmaster server consists of two core components: network and paxos. Network encapsulates all server to server communications, exposing a simple interface for message delivery and receipt. Each Paxos implementation represents a version if the Paxos consensus protocol, defining it's own behavior and and message formats. Network handles all the communication for Paxos.
+The Ringmaster server consists of two core components: \texttt{network} and \texttt{paxos}. \texttt{Network} encapsulates all server to server communications, exposing a simple interface for message delivery and receipt. Each Paxos implementation represents a version of the Paxos consensus protocol, defining it's own behavior and and message formats. \texttt{Network} handles all the communication for Paxos.
 
-On top of the network and paxos components, the server maintains communications with the client and handles server-server communications, each in its own goroutine. The server maintains a TCP connection with the client and proceses its incoming messages accordingly. It also waits on network. Incoming which is a Go channel of messages, which the server processes in order of arrival. Processing these network-layer messges usually entails unwrapping the payload and passing it to the Paxos layer.
+On top of the \texttt{network} and \texttt{paxos} components, the server maintains communications with the client and handles server-server communications, each in its own goroutine. The server maintains a TCP connection with the client and proceses its incoming messages accordingly. It also waits on network. \texttt{Incoming} which is a Go channel of messages, which the server processes in order of arrival. Processing these network-layer messges usually entails unwrapping the payload and passing it to the Paxos layer.
 
 \subsection{Network}
 
-We implemented a separate network layer to handle server to server communications for the ease of imposing simulation conditions later on, as our network conditiond are limited by our testing environment set up. By separating the communications layer from the actual server, we are able to simulate different network conditions  (additional delays, loss of messages) that might be reflective of real-world situations (e.g. Servers deployed in different continents; variable server servers latency). With out design, we can add arbitrary delays and loss rates between certain edges to simulate these conditions.
+We implemented a separate network layer to handle server to server communications for the ease of imposing simulation conditions later on, as our network conditions are limited by our testing environment set up. By separating the communications layer from the actual server, we are able to simulate different network conditions  (additional delays, loss of messages) that might be reflective of real-world situations (e.g. Servers deployed in different continents; variable server servers latency). With our design, we can add arbitrary delays and loss rates between certain edges to simulate these conditions.
 
-The current implementation opens two directional TCP connections between peers (all of which are different hosts).  It first starts a listening socket and then begins to dial each of its peers. Setup is not complete until all TCP connections are established. To ensure messages aren't interleaved, the network uses two go channels, for incoming and outgoing network messages. For each accepted connection, a goroutine  is started to read network messages from thr connection. The goroutine then pushes each created message to the incoming channel, which can be read from by the server.
+The current implementation opens two directional TCP connections between peers (all of which are different hosts).  It first starts a listening socket and then begins to dial each of its peers. Setup is not complete until all TCP connections are established. To ensure messages aren't interleaved, the network uses two go channels, for incoming and outgoing network messages. For each accepted connection, a goroutine  is started to read network messages from the connection. The goroutine then pushes each created message to the incoming channel, which can be read from by the server.
 
-Thr network also supports sends an arbitrary payload (wrapped in a network message) to a single peer,  and broadcast, which sends a message to all peers. For send, a message with the destination peer and desired payload is created and pushed to the outgoing channel. For broadcast, the same is done for all peer destinations. Finally, a dedicated goroutine writes messages from the outgoing channel to the appropriate outgoing TCP connection
+The network also supports sends an arbitrary payload (wrapped in a network message) to a single peer,  and broadcast, which sends a message to all peers. For send, a message with the destination peer and desired payload is created and pushed to the outgoing channel. For broadcast, the same is done for all peer destinations. Finally, a dedicated goroutine writes messages from the outgoing channel to the appropriate outgoing TCP connection
 
 \section{Client Library}