Single node determines cycle transactions

Development & Technical discussion about Timekoin.
Forum rules
Bug Collecting Database is Click Here
GitHub Account is Click Here
Post Reply
warmach
Posts: 404
Joined: Thu Jun 21, 2012 5:18 pm

Single node determines cycle transactions

Post by warmach »

Timekoin uses majority rule to determine if a transaction is accepted in a cycle. If the transaction is sent through a series of slow peers, it may not make it to the entire network in time. If that happens, all peers fight over what transactions are included. As we have seen, this can result in frustrating behavior of our servers.

Proposal:

Have one single server be chosen to determine a cycle's transactions, much like how a bitcoin miner chooses the transactions to include. We could use the election functionality but choose the server from the generation peer list. The server then could send out a transaction cycle summary message. If your server is missing a transaction, it could poll the network for it. If it has an extra transaction, it would delete it. If your serv was the originator of a deleted transaction, it would then rebroadcast the transaction for inclusion in the next cycle.

Thoughts?
User avatar
tiker
Posts: 81
Joined: Wed Jun 20, 2012 2:13 pm
Contact:

Re: Single node determines cycle transactions

Post by tiker »

That would add more traffic between the servers and would present new problems around trust on the single server elected, as well as potential issues if that elected server goes offline, runs slowly, etc.

The best thing is to keep several peers connected and avoid the permanent peers with the "Permanent Peer Priority" setting enabled.

With today's update sending transactions to the "First Contact Peers" list as well should help getting around the slower peers.
warmach
Posts: 404
Joined: Thu Jun 21, 2012 5:18 pm

Re: Single node determines cycle transactions

Post by warmach »

I am not sure it would create more traffic than there is when servers try to determine a majority for a transaction. I think it will create less overall.

I guess a server op could choose to not accept transactions from a particular server or address. If that would happen the transaction would be rebroadcast and it is unlikely that the same server op would be randomly chosen again. I am not sure how much trust is needed.

You are right, there would need to be a backup mechanism for offline or slow servers. It could just be that all servers prepare their own transaction summary and if the chosen server does not send out the summary in time, a new server is chosen. With that, it might rake 1-2 minutes to finalize the previous cycle.

Sending the transactions to the first contact can do nothing but help.
User avatar
tiker
Posts: 81
Joined: Wed Jun 20, 2012 2:13 pm
Contact:

Re: Single node determines cycle transactions

Post by tiker »

What if it were a generation broadcast that was blocked? Can't rebroadcast generation transactions the next round.

As far as the extra traffic goes, you've got the existing broadcasts now, then you get the extra queries to the master to find out if you're up-to-date, then you've got the traffic to determine if you're missing or have extra transactions. Now, I'm assuming you want to wait until a short time before the end of the cycle before communicating to the master and finding out if you're up-to-date.

Now is that master is going to get hammered with queries from the entire server list asking to see if they're all up to date? If that master is offline, or slow to respond to everyone, then the cycle ends, half the servers will be happy, others will be guessing / hoping and then falling back to the existing protocol of checking the hash with the peers.

It would also be bad for TimeKoin servers that do not have internet connectivity (large company intranets) using a single TimeKoin server as a bridgehead to the rest of the network.
User avatar
PoisonWolf
Posts: 186
Joined: Fri Apr 12, 2013 10:39 am

Re: Single node determines cycle transactions

Post by PoisonWolf »

tiker wrote: The best thing is to keep several peers connected and avoid the permanent peers with the "Permanent Peer Priority" setting enabled.
Can you explain what the Permanent Peer Priority setting does? And why it shouldn't be used with Permanent Peers (the blue peers that are manually inserted).

I ask because I just enabled this setting on one of my servers (and got rid of all the blue folks) and I'm now seeing a lot of "No Active Peers to Poll" messages....
User avatar
tiker
Posts: 81
Joined: Wed Jun 20, 2012 2:13 pm
Contact:

Re: Single node determines cycle transactions

Post by tiker »

PoisonWolf wrote: Can you explain what the Permanent Peer Priority setting does? And why it shouldn't be used with Permanent Peers (the blue peers that are manually inserted).
Permanent peers by themselves just keeps them connected permanently.

The peer priority setting forces TimeKoin to look at the permanent peers only for functions it would normally ask all of the connected peers such as checking if the generation peers hash is correct.
Post Reply