search

lightem90 / testMRMW

MRMW for deployment on test system
0 stars 0 forks source link

Init messages handling #7

Closed xit4 closed 9 years ago

xit4 commented 9 years ago

As seen at lines https://github.com/lightem90/testMRMW/blob/2cbf5ba6410e180a18aba6d2ab93691289f0dcdf/src/NetworkPrimitives/ConnectionManager.java#L186 

initIsOver = handleInit(m,initIsOver);
    if (initIsOver)
        parseInput(m, (SocketChannel) key.channel());

handleInit() is called with a message m and a boolean initIsOver which is true at first and is modified in handleInit() itself for later usages.

I don't understand the meaning of this. Why do we need initIsOver?

xit4 commented 9 years ago

i temporarily avoided the issue by making handleInit() always return false. no idea why it should return true in the first place.

lightem90 commented 9 years ago

Because I thought that if an init was received we had to check handleInit() the next time at first for an "end_handshake" message. But I think that init-init_ack-end_handshake are useless messages if a node (everytime that calls finishConnect from a connectable key) starts a non-blocking read operation. These messages are useless imho

xit4 commented 9 years ago

so, should everything be moved to finishconnect() ? how are nodes going to fill replicas without knowing the exact view of the connected node? start a read() every time? I do agree that the init messages are removable but they also handle replica initialization and leader communication for newly connected nodes. on this last point: if 1-6 connect and elect 6 everything is fine; when 7 connects the sees there is quorum and starts election electing itself as leader cause his ID is bigger. somebody has to tell him that the cluster already has a leader. continuing on this point: i think the leader election we implemented should handle this case without us doing anything. If a new node with higher ID joins the cluster, he should start the election and elect the leader already present in the system. for our example: 6 is leader for nodes 1-6; 7 connects and has 6 and 7 as seemCrd; 7 does not have support of quorum so is discarded, 6 is the leader.

lightem90 commented 9 years ago

yup ok, we can leave init and init_ack but we have to figure out the right place and what they should contain (leader_id as well?). maybe when a server accepts a connection he sends a message to the init client (with unknown id) in this way the connecting client(server) can do the synchronization? So maybe move init from finishConnect() to accept() method

lightem90 commented 9 years ago

refer to https://github.com/lightem90/testMRMW/issues/9