Recent changes to client-connection

WikiPage client-connection modified by ckeeline

ckeeline — Mon, 02 Apr 2012 20:24:47 -0000

--- v8 
+++ v9 
@@ -3,49 +3,55 @@
 Client-Side Connection Manager
 ==============================
 
-Clients will contact the web server via HTTP to discover their super-node name and IP address. If there is no super-node, the client should try again later. Clients will then set up a TCP connection to the super-node. If the connection fails, the client should re-initialize by going back to the web server again to ask for a super-node address. 
-
-The super-node keeps a list of nodes that connect to it, including their names. The super-node tells all nodes (in the entire federation) via the publish-subscribe layer which nodes are in its orchestra. This information can be used by the chat system to form a directory of nodes.
-
-A similar protocol is used for super-nodes. Contact the server to register, get back a list of super-nodes. In this case, the super-node connects over the Internet to all other super-nodes. 
-
-The connection manager for clients and super-nodes should encapsulate the setup and connection phase, and offer a simple message delivery service via an API.
-
-The web server URL should be set-able from a menu item and saved in preferences. It is not expected to ever change.
-
-Every node needs to know who is the conductor (one global conductor per federation). This is tricky because nodes, super-nodes, and the conductor will all join asynchronously. One possibility is to simply broadcast the conductor identity every 20s or so. Since the conductor will be broadcasting a lot of other information, this should not cause any problems. This might require some coordination with the [conducting interface](conducting) group.
-
-A more complex solution: Make the super-nodes responsible. Invariant 1: a super-node will (eventually) tell each node in its orchestra who the conductor is. Invariant 2: when a node becomes the conductor, it will tell its super-node, and its super-node will tell all other super-nodes who is the conductor. To achieve Invariant 2, when a new super-node joins and connects to the super-node with the conductor, a message must be sent to the new super-node identifying the conductor. To achieve Invariant 1, each super-node will inform all its nodes when it finds out the identity of the conductor. After that, when a new node connects to the super-node, the super-node will generate a message to tell who is the conductor. This is nice in terms of getting information out fast with the fewest messages, but it seems hard to implement and test with high confidence.
-
+Clients contact the web server via HTTP to register themselves. The server will give names and IP addresses for nodes this one should connect to (sometimes no connections should be made). Each client listens for new connections, nodes listen for their supernode, and supernodes listen for connections from nodes in their orchestra, and for other supernodes.
+
+In effect, when the connection manager is started, it connects to what it should connect to in the federation that is already there, and waits for connections from things joining the federation in the future. 
+
+The supernode keeps lists of all nodes and supernodes it is connected to. This information is available through the API.
+TODO: Does anyone need a message sent when things connect (e.g. chat)? 
+
+The connection manager for clients and supernodes encapsulates the setup and connection phase, and offers message delivery service in the form of the API below.
+
+We leave the designation of who is the conductor up to the conducting team. It should be possible to do whatever they need to do through publish subscribe.
+
 Design
 ------
 
 Our design focuses on the network topology between the nodes and the supernodes and leaves protocol decisions to other modules, such as the Publication/Subscription module. As is such, our modules create connections between the nodes, supernodes, and the HTTP server, and allow other modules to communicate to specific parties via Strings.
 
 HttpConnection: Handles connection to the HTTP server
 
     - Constructor sets the server path
     - init creates all needed federations, orchestras and nodes
     - shutdown unregisters our user
     - getSupernodeAddr gets the IP address of the supernode
     - getOtherSupernodesAddrs gets the IP addresses of the other supernodes
 
 NodeConnection: Encapsulates a leaf node
 
     - init connects to the HTTP server and then to the supernode
     - shutdown cleans up sockets and the HttpConnection object
     - sendMessage sends a message to the supernode
 
 SupernodeConnection: Encapsulates a supernode
 
     - init connects to the HTTP server, then to all other supernodes. Listens for other supernode connections and child node connections
     - shutdown cleans up all child connections
     - sendNodeMessage sends a message to a node
     - sendSupernodeMessage sends a message to a supernode
     - connectedNodes returns the set of nodes connected to this supernode
     - connectedSupernodes returns the set of supernodes connected to this supernode
 These sets are not guaranteed to be up to date though, as sending a message can cause a connection to die. (If the other node was restarted, the connection will die when you write to it.)
 
-
+Implementation Details
+---------------------
+
+The connection manager is initialized during program start up, at which point it registers a timer in the GUI scheduler, to poll for network IO frequently. When polled, the connection manager uses select to determine which connections have anything to do.
+
+When writing, we serialize the message, and send the size over beforehand. Then for reading, we read the size, and after reading that many bytes from the socket, then we deserialize it. This behavior is encapsulated in the NonBlockingIO object.
+
+We connect in nonblocking mode, so we just start connecting, and then finish it when select tells us to. At that point we send a string which is our address (e.g. /ochh/node). This is so the accepting side will know the address of the newly connected node. Things get a little tricky as we have also enabled low level debugging messages that are strings.
+
+There are many places where the code can throw exceptions. Hopefully, the code will give a short output detailing what happened, and continue in an appropriate fashion. Sometimes, we will close the connection which had a problem, and continue. Other times, the exception is considered fatal to the connection manager, and it will restart. Right now repeated problems in the connection manager will make it restart continuously. This part is a bit tricky, so if anyone runs into problems with exceptions from the connection manager, let us know.
 
 [Home](/p/floctrl/wiki/)

WikiPage client-connection modified by ckeeline

ckeeline — Tue, 20 Mar 2012 20:19:57 -0000

--- v7 
+++ v8 
@@ -35,24 +35,17 @@
     - init connects to the HTTP server and then to the supernode
     - shutdown cleans up sockets and the HttpConnection object
     - sendMessage sends a message to the supernode
-    - receiveMessage receives a message from the supernode
-
+
 SupernodeConnection: Encapsulates a supernode
 
     - init connects to the HTTP server, then to all other supernodes. Listens for other supernode connections and child node connections
     - shutdown cleans up all child connections
     - sendNodeMessage sends a message to a node
-    - broadcastNodeMessage sends a message to all nodes
-    - receiveNodeMessage receives a message from a node
     - sendSupernodeMessage sends a message to a supernode
-    - broadcastSupernodeMessage sends a message to all supernodes
-    - receiveSupernodeMessage receives a message from a supernode
-
-Still TODO:
-------
-
-- TESTING
-- Integration with Publication/Subscribe team
-- Figure out how to handle the conductor interface intelligently
+    - connectedNodes returns the set of nodes connected to this supernode
+    - connectedSupernodes returns the set of supernodes connected to this supernode
+These sets are not guaranteed to be up to date though, as sending a message can cause a connection to die. (If the other node was restarted, the connection will die when you write to it.)
+
+
 
 [Home](/p/floctrl/wiki/)

WikiPage client-connection modified by Maxwell J. Koo

Maxwell J. Koo — Fri, 09 Mar 2012 04:32:10 -0000

--- v6 
+++ v7 
@@ -23,24 +23,36 @@
 Our design focuses on the network topology between the nodes and the supernodes and leaves protocol decisions to other modules, such as the Publication/Subscription module. As is such, our modules create connections between the nodes, supernodes, and the HTTP server, and allow other modules to communicate to specific parties via Strings.
 
 HttpConnection: Handles connection to the HTTP server
+
     - Constructor sets the server path
     - init creates all needed federations, orchestras and nodes
     - shutdown unregisters our user
     - getSupernodeAddr gets the IP address of the supernode
     - getOtherSupernodesAddrs gets the IP addresses of the other supernodes
+
 NodeConnection: Encapsulates a leaf node
+
     - init connects to the HTTP server and then to the supernode
     - shutdown cleans up sockets and the HttpConnection object
     - sendMessage sends a message to the supernode
     - receiveMessage receives a message from the supernode
+
 SupernodeConnection: Encapsulates a supernode
+
     - init connects to the HTTP server, then to all other supernodes. Listens for other supernode connections and child node connections
     - shutdown cleans up all child connections
     - sendNodeMessage sends a message to a node
     - broadcastNodeMessage sends a message to all nodes
     - receiveNodeMessage receives a message from a node
     - sendSupernodeMessage sends a message to a supernode
     - broadcastSupernodeMessage sends a message to all supernodes
-    - receiveSupernodeMessage receives a message from a supernode    
+    - receiveSupernodeMessage receives a message from a supernode
+
+Still TODO:
+------
+
+- TESTING
+- Integration with Publication/Subscribe team
+- Figure out how to handle the conductor interface intelligently
 
 [Home](/p/floctrl/wiki/)

WikiPage client-connection modified by Maxwell J. Koo

Maxwell J. Koo — Fri, 09 Mar 2012 04:29:54 -0000

--- v5 
+++ v6 
@@ -19,15 +19,28 @@
 
 Design
 ------
-Tentative API:
-Connection(String federation, String orchestra, String name, boolean superNode, boolean conductor)
-Call the constructor to connect to the orchestra
-
-boolean sendMessage(FloMessage msg)
-We still have to flesh out the details of the message format with the publish/subscribe team
-
-Subtask Assignments
--------------------
-- Document who will do what when.
+
+Our design focuses on the network topology between the nodes and the supernodes and leaves protocol decisions to other modules, such as the Publication/Subscription module. As is such, our modules create connections between the nodes, supernodes, and the HTTP server, and allow other modules to communicate to specific parties via Strings.
+
+HttpConnection: Handles connection to the HTTP server
+    - Constructor sets the server path
+    - init creates all needed federations, orchestras and nodes
+    - shutdown unregisters our user
+    - getSupernodeAddr gets the IP address of the supernode
+    - getOtherSupernodesAddrs gets the IP addresses of the other supernodes
+NodeConnection: Encapsulates a leaf node
+    - init connects to the HTTP server and then to the supernode
+    - shutdown cleans up sockets and the HttpConnection object
+    - sendMessage sends a message to the supernode
+    - receiveMessage receives a message from the supernode
+SupernodeConnection: Encapsulates a supernode
+    - init connects to the HTTP server, then to all other supernodes. Listens for other supernode connections and child node connections
+    - shutdown cleans up all child connections
+    - sendNodeMessage sends a message to a node
+    - broadcastNodeMessage sends a message to all nodes
+    - receiveNodeMessage receives a message from a node
+    - sendSupernodeMessage sends a message to a supernode
+    - broadcastSupernodeMessage sends a message to all supernodes
+    - receiveSupernodeMessage receives a message from a supernode    
 
 [Home](/p/floctrl/wiki/)

WikiPage client-connection modified by ckeeline

ckeeline — Thu, 08 Mar 2012 14:09:21 -0000

--- v4 
+++ v5 
@@ -19,8 +19,12 @@
 
 Design
 ------
-- Put a design here
-- Include how the next level up will be able to use connections to send messages.
+Tentative API:
+Connection(String federation, String orchestra, String name, boolean superNode, boolean conductor)
+Call the constructor to connect to the orchestra
+
+boolean sendMessage(FloMessage msg)
+We still have to flesh out the details of the message format with the publish/subscribe team
 
 Subtask Assignments
 -------------------

WikiPage client-connection modified by Roger B. Dannenberg

Roger B. Dannenberg — Sun, 26 Feb 2012 16:47:20 -0000

--- v3 
+++ v4 
@@ -13,6 +13,10 @@
 
 The web server URL should be set-able from a menu item and saved in preferences. It is not expected to ever change.
 
+Every node needs to know who is the conductor (one global conductor per federation). This is tricky because nodes, super-nodes, and the conductor will all join asynchronously. One possibility is to simply broadcast the conductor identity every 20s or so. Since the conductor will be broadcasting a lot of other information, this should not cause any problems. This might require some coordination with the [conducting interface](conducting) group.
+
+A more complex solution: Make the super-nodes responsible. Invariant 1: a super-node will (eventually) tell each node in its orchestra who the conductor is. Invariant 2: when a node becomes the conductor, it will tell its super-node, and its super-node will tell all other super-nodes who is the conductor. To achieve Invariant 2, when a new super-node joins and connects to the super-node with the conductor, a message must be sent to the new super-node identifying the conductor. To achieve Invariant 1, each super-node will inform all its nodes when it finds out the identity of the conductor. After that, when a new node connects to the super-node, the super-node will generate a message to tell who is the conductor. This is nice in terms of getting information out fast with the fewest messages, but it seems hard to implement and test with high confidence.
+
 Design
 ------
 - Put a design here

WikiPage client-connection modified by Roger B. Dannenberg

Roger B. Dannenberg — Sat, 25 Feb 2012 04:30:22 -0000

--- v2 
+++ v3 
@@ -5,7 +5,7 @@
 
 Clients will contact the web server via HTTP to discover their super-node name and IP address. If there is no super-node, the client should try again later. Clients will then set up a TCP connection to the super-node. If the connection fails, the client should re-initialize by going back to the web server again to ask for a super-node address. 
 
-The super-node keeps a list of nodes that connect to it, including their names. The super-node tells all nodes (in the entire federation) which nodes are in its orchestra. This information can be used by the chat system to form a directory of nodes.
+The super-node keeps a list of nodes that connect to it, including their names. The super-node tells all nodes (in the entire federation) via the publish-subscribe layer which nodes are in its orchestra. This information can be used by the chat system to form a directory of nodes.
 
 A similar protocol is used for super-nodes. Contact the server to register, get back a list of super-nodes. In this case, the super-node connects over the Internet to all other super-nodes.

WikiPage client-connection modified by Roger B. Dannenberg

Roger B. Dannenberg — Sat, 25 Feb 2012 04:20:08 -0000

--- v1 
+++ v2 
@@ -5,7 +5,9 @@
 
 Clients will contact the web server via HTTP to discover their super-node name and IP address. If there is no super-node, the client should try again later. Clients will then set up a TCP connection to the super-node. If the connection fails, the client should re-initialize by going back to the web server again to ask for a super-node address. 
 
-A similar protocol is used for super-nodes, but in this case, the super-node is trying to connect over the Internet to all other super-nodes. 
+The super-node keeps a list of nodes that connect to it, including their names. The super-node tells all nodes (in the entire federation) which nodes are in its orchestra. This information can be used by the chat system to form a directory of nodes.
+
+A similar protocol is used for super-nodes. Contact the server to register, get back a list of super-nodes. In this case, the super-node connects over the Internet to all other super-nodes. 
 
 The connection manager for clients and super-nodes should encapsulate the setup and connection phase, and offer a simple message delivery service via an API.

WikiPage client-connection modified by Roger B. Dannenberg

Roger B. Dannenberg — Sat, 25 Feb 2012 04:00:47 -0000

[Home](/p/floctrl/wiki/) Client-Side Connection Manager ============================== Clients will contact the web server via HTTP to discover their super-node name and IP address. If there is no super-node, the client should try again later. Clients will then set up a TCP connection to the super-node. If the connection fails, the client should re-initialize by going back to the web server again to ask for a super-node address. A similar protocol is used for super-nodes, but in this case, the super-node is trying to connect over the Internet to all other super-nodes. The connection manager for clients and super-nodes should encapsulate the setup and connection phase, and offer a simple message delivery service via an API. The web server URL should be set-able from a menu item and saved in preferences. It is not expected to ever change. Design ------ - Put a design here - Include how the next level up will be able to use connections to send messages. Subtask Assignments ------------------- - Document who will do what when. [Home](/p/floctrl/wiki/)