Add "cookie" or other identification mechanism to SimpleLocalnet

[mboes]

From @edsko on October 23, 2012 13:59

so that we have multiple independent Cloud Haskell applications running on the same network.

Copied from original issue: #56

[mboes]

From @edsko on October 23, 2012 15:11

(Possibly it might suffice to make the multicast port configurable.)

[ciez]

service name may already be sent with whereisRemoteAsync

it is received with WhereIsReply service mpid

see Control-Distributed-Process

[qnikst]

@ciez, sorry can you elaborate how registry API is relevant to this ticket? If you want to tell that we have similar problem for that API, please open relevant ticket in the distributed-process package

[ciez]

so that we have multiple independent Cloud Haskell applications running on the same network.

WhereIsReply handler may choose to handle or ignore specific service.
for example

This is not secure however the ticket headline mentions identification not authorisation

[qnikst]

This task is about d-p-simplelocalnet, the problem is that it does network wide send on multicast address thus all nodes even from the different network will see each other.
Idea behind this ticket is that we should provide cookie inside each notification, thus node can decide wether it want to add node to the list of known nodes or not.
So in my understanding this layer should be complete invisible to the higher d-p framework. Possibly I'm missing your idea about how to solve this.

[ciez]

interesting. I tried to make raketka nodes discover peers via multicast but could not. so I went for specified (in config) peers.

at least on my pc it behaves like this: same service nodes see each other, send messages to each other. Broadcast looks up peer pids from node's own state.

just checked: service name certainly makes a difference: same service -> connected, different service -> messages are not sent/delivered.

basically, WhereIsReply String works as a cookie.

can send complete working code on request. Raketka is only a base project.

[qnikst]

This task is about multicast functionality that will not work properly in case if there are 2 independent d-p clusters in the same network, basically about this code:

https://github.com/haskell-distributed/distributed-process-simplelocalnet/blob/master/src/Control/Distributed/Process/Backend/SimpleLocalnet.hs#L178

https://github.com/haskell-distributed/distributed-process-simplelocalnet/blob/master/src/Control/Distributed/Process/Backend/SimpleLocalnet.hs#L232-L245

distributed-process-simplelocalnet always uses same multicast address and the same port, so if you will want to start 2 independent clusters, and will send a request - then clients from both clusters will reply. So findPeers function will return both your and someones else nodes! I really don't see how whereIs may be relevant here, d-p layer is not involved here.

If you have thoubles using multicast then you may want to consult on irc, or if you had particular problem/faced bug - then create an issue.

[ciez]

yes it is likely we discuss different things. I am just saying that - although unintended - my code works exactly as requested by @mboes: multiple clusters run in parallel with cpu peaking without messages crossing - as far as I can tell.

This behaviour suits me ok the way it is.

findPeers - this I think did not work for me. Or maybe I just used it wrongly.

this is a problem though. Any chance someone might take a look?