Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Persisting connections #3

Open
3rd-Eden opened this issue Dec 1, 2014 · 0 comments
Open

Persisting connections #3

3rd-Eden opened this issue Dec 1, 2014 · 0 comments

Comments

@3rd-Eden
Copy link
Member

3rd-Eden commented Dec 1, 2014

From @jcrugzz

Related to the raft implementation, how should we go about managing connections to all the nodes? In the current use here, a new socket connection is opened up EACH time the write function is called. @3rd-Eden if Im missing something here then the interface is a bit confusing in how its communicating between all the servers. I know we keep the nodes that are in a specific cluster as child nodes of the main raft node but its not clear how the messages are being distributed to all of them. Is the write function called with the context of the child nodes in the cases where a message is being sent to them? (because this.name is the port/host signifier).

This is kind of a combo liferaft/sumo issue but made sense to put it here. @3rd-Eden tell me if im crazy or explain a bit of your thought process if you see where I'm coming from.


@3rd-Eden reply

It was somewhat intentional to open a connection for every single write as raft requires a request response pattern for communication. By just opening a new connection for every single write makes the code a bit easier to reason about as liferaft is still an early stage project and I didn't to complicate the logic to much by adding a persistent communications to sumo. It would need to have reconnection logic, message framing, some sort of protocol written on top the connection logic to figure out when something is a response to a message. We need to implement ping/heartbeats to ensure that the connection stays alive etc. All of this would add much more technical burden to the project so I decided to ignore it for now as connections are cheap anyways if we hit a limit with sumo where we're creating to much connections we can always easily switch out the connection logic.

As for the internal messaging interface I can understand it's a bit confusing. I think my poor decision to call a property name also contributes to the confusion but that can be resolved easily. As for the transport logic:

When you construct a new raft node, it will call the initialize method so it can construct a server/connection to receive messages. This raft node does use the write method because all communication will be done by writing directly to the incoming connections.

The write method is only used when you call the join method so it becomes aware of other nodes in the cluster and joins them. In order to message these child nodes, it will call the write method as these child nodes do not need to establish a server but only connect to the raft nodes and send messages.

But I can see this becoming an issue when you're starting to use persistent connections as the created Raft node will already have a persistent connection to each of the child nodes in the cluster and it would create another one every time you write. If this is the problem you're facing we could add a reference to the main raftnode when we create a child and store it as a parent property. So on the server you could store all persistent connections according to their names in an object on the parent and have your child nodes reference that connection when writing data. The only problem would be that receiving replies would be harder. But it's definitely something that we can solve.

But I think this issue more specific to liferaft than sumo so I'm going to move this discussion over there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant