Tord Ingolf Reistad <[EMAIL PROTECTED]> writes: Hi Tord!
> First off I do not really understand what you mean when you say that
> you send more than once in a single method, so could you give some
> more details.
Yeah, I see what you mean -- it was a rather vague... Mikkel and I were
in a hurry to get to a Friday Lecture :-)
The problem is this: In a protocol like Shamir share we want to
broadcast our shares to the other players. The code goes something like
this:
@increment_pc
def method(self, ...):
pc = tuple(self.program_counter)
if self.id == sender:
shares = ...
for peer_id in range(1, self.num_players+1):
self.protocols[peer_id].sendShare(pc, shares[peer_id])
else:
share = self._expect_share(sender, field)
This works fine -- the one sender sends all shares with the same pc, and
all the receivers expect their share using the same pc.
But what happens if we try to send two shares to each player in the
loop? Then they get the same pc since the pc is not incremented anywhere
in the code!
One idea which does not really work is to wrap the call to sendShare in
another Runtime method which *does* increment the pc:
@increment_pc
def send_share(self, share, peer_id):
pc = tuple(self.program_counter)
self.protocols[peer_id].sendShare(pc, share)
@increment_pc
def method(self, ...):
pc = tuple(self.program_counter)
if self.id == sender:
some_shares = ...
more_shares = ...
for peer_id in range(1, self.num_players+1):
self.send_share(some_shares[peer_id], peer_id)
self.send_share(more_shares[peer_id], peer_id)
else:
share = self._expect_share(sender, field)
The problem here is that we increment the pc too much -- we actually
want the pc to increment only once upon entry to the method, and then
once again when the more_shares are sent.
That is what lead us to the idea that we need a program counter per
player. What we want is that the two calls to self.send_share keeps
using the *same two* program counters. So all shares in some_shares are
sent using pc1, and all the more_shares are sent using pc2.
By the way: This problem looks similar to the failing test case in
test_basic_runtime, but don't know yet if they are quite the same.
> But here is my input to the counter situation and some more broad
> thoughts about the program:
>
> [...]
I think I'll have to read and think some more about this final part
before I can comment on it :-)
--
Martin Geisler
pgpKBLSob4ExQ.pgp
Description: PGP signature
_______________________________________________ viff-devel mailing list (http://viff.dk/) [email protected] http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
