2013-07-20 09:49:47 utc |
edulix |
wouldn't it make sense to migrate the openwferu-users group to ruote-users group? |
2013-07-20 09:59:01 utc |
jmettraux |
edulix: hello |
2013-07-20 10:00:37 utc |
jmettraux |
plus side: it'd fit the "ruote" we currently have, minus side: "if you want to search the discussion archive you have to look at openwferu-users and at ruote-x" |
2013-07-20 10:08:39 utc |
edulix |
jmettraux: sooner or later it'd only make sense to do the migration |
2013-07-20 10:09:14 utc |
edulix |
btw, I'm trying to do a curious workflow that I think ruote does not allow (at least not easily) |
2013-07-20 10:09:17 utc |
jmettraux |
unless ruote dies |
2013-07-20 10:10:11 utc |
edulix |
jmettraux: long live ruote! |
2013-07-20 10:10:22 utc |
jmettraux |
:-) |
2013-07-20 10:12:02 utc |
jmettraux |
what's the curious workflow? |
2013-07-20 10:12:35 utc |
edulix |
jmettraux: well I want to execute in different participants at the same time a set of workitems |
2013-07-20 10:12:42 utc |
edulix |
one workitem per participant |
2013-07-20 10:12:45 utc |
edulix |
*but* |
2013-07-20 10:13:21 utc |
edulix |
1. I want to limit in each participant the number of possible workitems of the same kind that they can execute at the same time, |
2013-07-20 10:15:15 utc |
edulix |
so that's a kind of queue |
2013-07-20 10:15:22 utc |
jmettraux |
there is no 2. ? |
2013-07-20 10:15:22 utc |
edulix |
2. I want to execute something in the participants before the workitem slot is going to be reserved which will return some data to the orchestrator, and do something similar if the "slot" is timedout |
2013-07-20 10:15:52 utc |
edulix |
and I can even tell you why I need this if you want :P |
2013-07-20 10:16:05 utc |
edulix |
(maybe I'm doing it wrong!) |
2013-07-20 10:16:07 utc |
jmettraux |
people voting? |
2013-07-20 10:16:53 utc |
edulix |
jmettraux: well it's related to voting, but it's the tally process |
2013-07-20 10:17:48 utc |
jmettraux |
https://gist.github.com/jmettraux/b1a5a2642106e410f34f ? |
2013-07-20 10:18:13 utc |
edulix |
I have to execute verificatum which will do the tally process. each participant is an authority which participate in the cryptographic tally , and they execute verificatum. to execute verificatum, each participant needs to setup a port for the communication |
2013-07-20 10:18:31 utc |
edulix |
this port is the one that needs to be reserved and unreserved |
2013-07-20 10:19:35 utc |
jmettraux |
https://gist.github.com/jmettraux/85cc4a91d53573b2c2a9 <- could it be simplified to that? 1. and 2. are the concerns of the partcipant implementation |
2013-07-20 10:19:55 utc |
jmettraux |
the orchestrator would just give the hot potato to the participant implementation |
2013-07-20 10:19:57 utc |
edulix |
jmettraux: interesting gists, feels like magic to me (I'm python guy :) |
2013-07-20 10:20:55 utc |
jmettraux |
https://gist.github.com/jmettraux/47519f2c06ec6e54cad3 is perhaps easier to read |
2013-07-20 10:21:10 utc |
jmettraux |
http://ruote.rubyforge.org/exp/concurrent_iterator.html |
2013-07-20 10:22:20 utc |
edulix |
jmettraux: what does the :pre => true do? |
2013-07-20 10:22:57 utc |
jmettraux |
it would be just you signaling the participant implementation that you want it to do "2.", whereas without :pre => true, it would be "1." |
2013-07-20 10:23:13 utc |
jmettraux |
but I believe one participant call is sufficient |
2013-07-20 10:23:27 utc |
edulix |
jmettraux: but the participant is not reserving slots right? |
2013-07-20 10:23:40 utc |
jmettraux |
according to your description, the orchestrator doesn't need to know about slots or whatever |
2013-07-20 10:24:07 utc |
jmettraux |
1. and 2. feel OK together in the same participant invocation |
2013-07-20 10:24:27 utc |
jmettraux |
hence my 2nd (and 3rd) gists |
2013-07-20 10:24:39 utc |
edulix |
jmettraux: each participant need to know the reserved ports of the other participants |
2013-07-20 10:24:47 utc |
edulix |
sorry if I didn't make that clear |
2013-07-20 10:25:08 utc |
jmettraux |
really? why? |
2013-07-20 10:25:32 utc |
jmettraux |
shouldn't they be happy sticking with the port they receive[d]? |
2013-07-20 10:25:41 utc |
edulix |
jmettraux: because each participant will execute an instance of verificatum running in that port, and each participant will be conected to each other that way |
2013-07-20 10:26:01 utc |
edulix |
jmettraux: well that port might be in use in that participant already |
2013-07-20 10:26:13 utc |
jmettraux |
ok |
2013-07-20 10:28:32 utc |
edulix |
actually, one of the singularities I also have is that each participant is independent of each other/decentralized, it's similar to email servers: email servers communicate with each other but they do not share the whole database of email of the whole world. I was told that I could somehow emulate this with ruote, but I don't know exactly how |
2013-07-20 10:29:45 utc |
jmettraux |
couldn't you do without ruote? |
2013-07-20 10:30:20 utc |
edulix |
jmettraux: I could create my own thing, but then I'd have to maintain it |
2013-07-20 10:30:20 utc |
edulix |
:P |
2013-07-20 10:30:33 utc |
edulix |
actually, I'm doing that, but I'm seeing that it's not trivial |
2013-07-20 10:31:06 utc |
jmettraux |
your participants communicate with each other, couldn't they have a protocol and let some kind of process emerge? |
2013-07-20 10:31:17 utc |
jmettraux |
instead of having an orchestrator enforce that process? |
2013-07-20 10:32:08 utc |
edulix |
I don't know, it's getting increasingly difficult |
2013-07-20 10:32:29 utc |
edulix |
having an orchestrator makes things easier :P |
2013-07-20 10:33:54 utc |
jmettraux |
https://gist.github.com/jmettraux/fcd2a731e0c66af64e3f <- expanding the two-pass thing, first pass for slot registration, second pass for slot "consumption" |
2013-07-20 10:36:13 utc |
jmettraux |
the first slot could be dropped if there is a "slot registry", something central (sorry, not federated), that allows for participants/slots lookup, but I guess you don't want that |
2013-07-20 10:36:59 utc |
edulix |
that still lacks the register slot -> timeout because other participant didn't register so we want to free out slot till later > deregister slot > the other participants register their slots > register again slot |
2013-07-20 10:37:20 utc |
edulix |
that's why I was thinking, will it be very difficult to create my own new workflow item? =) |
2013-07-20 10:37:50 utc |
jmettraux |
wait, you register against what? |
2013-07-20 10:37:50 utc |
edulix |
something that has a workflow item with three functions: register, deregister, execute |
2013-07-20 10:38:18 utc |
edulix |
jmettraux: not register, I reserve slots sorry for the language |
2013-07-20 10:38:26 utc |
edulix |
slot == port |
2013-07-20 10:39:12 utc |
jmettraux |
couldn't there be a hash function? For example, given its IP address, the participant always uses the same slot |
2013-07-20 10:39:36 utc |
edulix |
nope |
2013-07-20 10:39:54 utc |
edulix |
the same remote ip could have more than one slot at the same time |
2013-07-20 10:39:58 utc |
jmettraux |
the participants would share the hash function and always be able to compute the slot give some x information (other participant name, IP address, etc) |
2013-07-20 10:40:10 utc |
jmettraux |
no nope: the IP address is an example |
2013-07-20 10:40:21 utc |
jmettraux |
your participants have unique names? |
2013-07-20 10:40:35 utc |
jmettraux |
how big is the slot space? |
2013-07-20 10:40:46 utc |
edulix |
they have something unique yes, each participant |
2013-07-20 10:41:00 utc |
jmettraux |
is the slot space bigger than the participant space? |
2013-07-20 10:41:12 utc |
edulix |
not necessarily |
2013-07-20 10:41:30 utc |
edulix |
each participant have a different number of slots |
2013-07-20 10:41:38 utc |
edulix |
might be 2, 7, whatever |
2013-07-20 10:41:46 utc |
edulix |
depending on their computing power |
2013-07-20 10:42:42 utc |
edulix |
sorry that I have to go jmettraux, thanks very much for your help, I'll continue around here later |
2013-07-20 10:43:17 utc |
jmettraux |
good afternoon! |
2013-07-20 10:43:56 utc |
jmettraux |
is the slot space equivalent to 0 to MAX_INTEGER? |
2013-07-20 12:27:13 utc |
jmettraux |
edulix: https://gist.github.com/jmettraux/d0c9b036e7a515eccab0 <- this is probably better, 1st step: participant "distributor" attributes slots, 2nd step: the participants work concurrently, |
2013-07-20 12:27:29 utc |
jmettraux |
each with its attributed slot, and they each know others' slots |