Added support for message broadcast via RPC

[savreline]

Here are the changes that allow to broadcast messages via RPC with the same vector clock. An end-to-end example has been added in example/RpcBroadcast/RpcBroadcast.go and the ShiViz output of this example in .images/shiviz_broadcast.png. The example and ShiViz output has been linked from the README. Also, a quick smoke test has been added to govec_test.go.

The changes are only really needed to enable broadcasting within the RPC framework, as if RPCs are not used, the end-user has full control to call GoLog.PrepareSend just once per several calls to conn.Write. On the other hand, when using RPCs, calls to GoLog.PrepareSend are automatically made on each RPC call and automatically tick the clock several times.

[codecov-io]

Codecov Report

Merging #63 (87a0e91) into master (bdb6c59) will decrease coverage by 1.96%. The diff coverage is 88.88%.

@@            Coverage Diff             @@
##           master      #63      +/-   ##
==========================================
- Coverage   62.14%   60.17%   -1.97%     
==========================================
  Files           3        3              
  Lines         383      334      -49     
==========================================
- Hits          238      201      -37     
+ Misses        109       96      -13     
- Partials       36       37       +1     

Impacted Files	Coverage Δ
govec/govec.go	62.98% <88.88%> (-0.54%)	:arrow_down:
govec/vrpc/vrpc.go	56.86% <0.00%> (-5.26%)	:arrow_down:
govec/vclock/vclock.go	54.66% <0.00%> (-4.29%)	:arrow_down:

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update bdb6c59...87a0e91. Read the comment docs.

[shayanh]

I don't exactly understand the rationale behind adding this. I think you're merging a set of events into one event, but they are actually different events. Is that for the better visualization with ShiViz? Can you describe a little bit more why such a feature can be useful?

[savreline]

The goal is to allow the GoVector vector clocks to be used with the framework of the casual broadcast, as described in Baldoni and Raynal. Fundamentals of Distributed Computing: A Practical Tour of Vector Clock Systems. IEEE Distributed Systems Online 2002; Figure 2, attached below for reference. In the example below, a message is broadcast from P1 to P1, P2, P3; so three messages are sent out with the same clock [1 0 0]. Without this patch, GoVector ticks the clock every RPC call and would sent out messages with clocks [1 0 0], [2 0 0], [3 0 0] which is not necessarily accurate (and yes, also messy to visualize in ShiViz).

[savreline]

I believe the comments and conflicts should be addressed now.

I have also updated naming and comments in RpcClientServer example to follow the same convention.