Retest pysyncobj

[bakwc]

Recently I improved pysyncobj delay in non-batch mode. 0.4 seconds delay seems to be very slow. I would appreciate it if you retest syncobj again.

Also you mentioned you had some issues with running pysyncobj on different physical machines, I'd like to know what exactly was wrong, may be I can help you or fix some bug if there is one.

Also I noticed you use xmlrpclib as a client library. There is a few issues with it:

• xmlrpc is not a fastest rpc library, it adds some delays cause of xml parcing etc.
• there is unnecessary round trips - client should send write requests to a leader node. As I understand for now client sends requests to a random node. In this case - the request is redirected from that node to a leader, same for response - it is redirected from leader back to node, and only then to client.
  I suggest to test pysyncobj directly, without clients. In that case each node acts both as node and as client.

[GianlucaBortoli]

I'll certainly have a look at your improvements. This is a project for a distributed algorithms course at university we did this summer, so we didn't plan to further improve or extend it.
However, we can test it again in our spare time with your new version of pysyncobj. Unfortunately, we cannot assure you anything about timings. Btw, feel free to improve krafters with a pull request if you want to add the distributed support we didn't implemented for pysyncobj (because of the problems we encountered).
Regarding the use of xmlrpclib, I see your point, but we are only interested in comparing multiple implementations. I agree that if we take the results in an absolute manner, they're biased by the rpc calls delays. On the other hand, if this is used to test all the implementations we chose, they have the same rpc structure, so that theyre comparable one another.