weiszg / csc Goto Github PK

trace:
Stabilisation core error at 9092
java.lang.NullPointerException
at uk.ac.cam.gw361.csc.Stabiliser.migrateResponsibilities(Stabiliser.java:115)
at uk.ac.cam.gw361.csc.Stabiliser.doStabilise(Stabiliser.java:99)
at uk.ac.cam.gw361.csc.Stabiliser.stabilise(Stabiliser.java:47)
at uk.ac.cam.gw361.csc.Stabiliser.run(Stabiliser.java:35)

Entities stored by CSC are usually indexed by their content hashes. However file lists (stored per user) are indexed by public keys. Their authenticity is protected by a signature. During stabilisation, different versions of these file lists have to be identified as they will have the same index (public key doesn't change). Currently a file list is determined to be newer if the peer advertising it advertises a different fileHash from what we have. This means that if an old peer comes back alive, it can overwrite the new file lists with its old ones. At least this is a race condition.

After running the Simulator for a while and suspending, connection errors should clear in a bit and the system should reach a stable state with no more error messages. However, there's still a lot of junk flowing about connection errors. Peers are trying to connect to others who are long dead.

When downloading the file list of a person (signed rather than content hashed), occasionally we get file not found from the peer that's supposed to own the file. This shouldn't happen. Moreover, it is handled improperly, as for example we could fail over to the files' replicas or at least produce a better error message.

to a more cryptographically secure hash function

The Simulator (but maybe even individual instances) running for long enough results in the following error:

Jan 10, 2016 7:15:57 PM sun.rmi.transport.tcp.TCPTransport$AcceptLoop executeAcceptLoop
WARNING: RMI TCP Accept-0: accept loop for ServerSocket[addr=0.0.0.0/0.0.0.0,localport=52309] throws
java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:714)
at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:950)
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1368)
at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTransport.java:415)
at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:372)
at java.lang.Thread.run(Thread.java:745)

At this time there are 2048 threads for the associated java process. Conclusion is that threads aren't properly closed.

Transfers are split up into 1M chunks. When any of those fail, the whole operations fails. This can happen due to temporary hiccups in the system. These transfers should later be retried from the point they failed, otherwise large enough transfers might never get through.

At the moment, fingers are defined to be the largest peer lower than me-2^i.
However, routing inherently works forward because each new step returns the largest neighbour lower than the result - ie. we go upwards. This is why fingers never end up being used: they only store information that is useful when we want to take steps backwards. Otherwise its closest forward pointer is half the keyspace and this large of a jump rarely happens.
To fix this, define fingers as the largest peer lower than me+2^i.
However, this creates another problem: previously, the number of fingers amortised from log(keySpace) to log(users) because finding that the first finger is also a valid finger for lots of other fingers (ie. it is lower than the threshold for others) allowed for updating many simultaneously. This cannot be done the same way because we'll be finding predecessors of additive increasing fingers, so a finger will never be valid as the next one in this sense.
However, another way of amortising to log(keySpace) is possible: look at the first successor of me. All the fingers that point to lower than this are spurious so do not deal with them but deal with all the rest. On average, my neighbour is about 1/N distance away. This might fluctuate but not much from an exponential point of view so roughly the same number of fingers are necessary, as many as it takes for 2^k/N>1. Which is still log(keySpace).