Hello, 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.
But here is my input to the counter situation and some more broad thoughts about the program: I try to imagine that one day VIFF will not be a separate program, but only a library/subroutine in some larger program. This larger program might want to do multiple MPC computations at the same time and might have different algorithms that it can handle, these algorithms are dynamically allocated. The counter system will have to handle all these cases. So let me draw a larger picture: You start with a set of MPC algorithms/protocols, e.g. algorithms a', b' and c'. Now for each algorithm you have to define a set of roles. E.g. for algorithm a', you have roles 1, 2, 3 and 4. Each role has a predefined set of information it uses as input to the MPC protocol and a predefined set of information it gets out of the MPC protocol. You also have a set of players A, B, C, D, E, etc. Lets make this more concrete, if algorithm a' is a location finder. Then roles 1,2,3 give as input to the MPC protocol their current position. Role 1 also gives the distance 1-2 and 1-3 as input to the MPC protocol. Role 2 also gives the distance 2-3 as input to the MPC protocol. Role 4 on the other hand gives the distance 1-4, 2-4 and 3-4. Role 4 is the only one to receive any output from the MPC protocol. It receives as output its current position. So role 1 has 3 inputs, role 2 has 2 inputs, role 3 has 1 input, role 4 has 3 inputs and 1 output. Now lets also assume that algorithm b' is some other algorithm with 3 players, where each role 1,2 and 3 has one input and gets one output. Finally lets say that player A can if anybody asks him participate in algorithm a' as role 1, 2 or 3 (not 4), and algorithm b' as role 1 or 3. Then A should be able to handle simultaneously the following: Algorithm a' in role 1, with B as role 2, C as role 3, E as role 4. Algorithm b' in role 3, with C as role 1, B as role 2. Algorithm b' in role 1, with E as role 1, F as role 2. and so on... Now the nice thing about this set-up is that each instance of the triplet algorithm, role and current set of players can be hashed into an unique value. The algorithms and roles can be pre-approved and checked for information leaks by a human. The algorithms and roles can the by dynamically linked to players at runtime. Each instance of the triplet can be run as a separate thread, and the program counter in each tread can operate independent of the other threads. As long as the unique identifier is transmitted to the other players they should also be on the same page as to which algorithm and which instance of the algorithm the messages should be transmitted to. Just my idea as to a multi-threaded, dynamical VIFF system. Tord Martin Geisler wrote: > Hello everybody, > > Mikkel has pointed out that the current system with a single program > counter is not enough if we need to send more than once in a single > method. > > We think the best solution is to introduce multiple program counters, > so that each player maintains a counter for each other player in the > network. > > The idea is that since the players might do different amount of > sending and receiving, one global program counter is not enough. > > > More concretely, we imagine that it will be enough if increment_pc > increments all program counters by one, and sendData and _expect_data > only increment the program counter associated with the sending or > receiving player. > > > We send this out here since we would love to hear other ideas! > _______________________________________________ viff-devel mailing list (http://viff.dk/) [email protected] http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
