ruote tmp/log_2013-07-20.html

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 ?
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 <- 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 is perhaps easier to read
2013-07-20 10:21:10 utc jmettraux
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 <- 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: <- 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