Dynamically Evolving Klaim Nets

1. Dynamically EvolvingKlaim Nets Lorenzo Bettinibettini@dsi.unifi.it Joint work withMichele Loreti, Rosario Pugliese Dipartimento di Sistemi ed Informatica, Firenze http://music.dsi.unifi.it

2. Dynamic Infrastructure • It evolves over time: • New nodes can get connected • Existing nodes can disconnect • Connections and disconnections can be temporary and unexpected • A connection can be established on the fly with wireless devices • Ad-hoc paths to services can be establish to enable communication among components

3. Dynamic Infrastructure • The assumption that the underlying network is always available may be too strong; • Permanent connection may not always be available; • The knowledge of the address of a remote host may be not sufficient to communicate with it; • Necessity of making Node Connectivity explicit in the language.

4. Communication Layer in Klaim • is based on nodes’ location knowledge, • is influenced by: • Allocation environments; • Tuple and Process distribution.

5. Connections and Disconnections Two nodes are disconnected if one doesn’t know the locality of the other s2 s1 TS TS

6. There is a (re)connection when one gets to knowabout the other s2 Connections and Disconnections s2 s1 TS TS

7. s2 Connections and Disconnections Two nodes will be disconnected again when that knowledge is lost s2 s1 TS TS

8. If a process, that knows a node,moves, then the knownnode moves too. Node mobilitycorresponds to mobility of (knowledge of) links s3 TS s3 s3 s3 Node “Mobility” s2 s1 TS TS

9. Clusters & SuperProcesses • A Cluster is a collection of nodes • There can be multiple clusters • Two nodes can interact with each other only if they stay in the same cluster • SuperProcesses are processes that: • Can create new Clusters; • Can add or remove their node to Clusters; • Cannot move

10. New Actions • Create a new cluster: newc(w) • Add a node to a cluster: add(c) • Remove a node from a cluster: rm(c) • Not indexed with a locality • They act on the node they are executed on.

11. c2 s s s Example newc(w) c1 add(c2) rm(c1)

12. Syntax N ::= s :: P  c :: {s} N | N P ::= nil out(et)  act.P  P | P  act.P + act.P  X  A<…> SP ::= P  sact.SP  SP | SP act ::= out(t)@l  in(t)@l  read(t)@l  eval(P)@l  newloc(SP,u)sact ::= add(c)  rm(c)  newc(w)

13. Connection Modes • Tethered mode • Disconnected mode • Untethered mode

14. Tethered mode • WAN connectivity is available • Information can be accessed from any point at any time Idealized situation that takes place only for a limitedcomputers in a network.

15. Disconnected mode • WAN connectivity is available • Users can work offline • When online a user works like in Tethered Mode • When a user goes online reconciliation and/or notification can be needed. Typical for a user that does not own a network access.The user works in isolation and, at some time, connectsto Internet (e.g. via a modem).

16. Untethered mode • WAN connectivity is unavailable • Local-area connectivity may still be available • Communication: • is enabled by wireless devices • is limited to those devices that are in a communication range Usual form for a mobile user, that from time to time entersdifferent areas where connectivity is constrained (e.g. byfirewalls).

17. Tethered mode • All nodes are in the same cluster and there are no SuperProcesses.

18. Disconnected mode • All nodes are in the same cluster • Occasionally some node can be removed and added

19. Untethered mode • Multiple clusters are available • Nodes can change cluster

20. Scenarios • Location dependent connection • Ad-hoc networking • Disconnection

21. Location-dependent Connection • A mechanical engineer visits a plant in the Third World • WAN connectivity is not available • There is a single wireless access point • When connected engineer can access plant’s resources (data and applications)

22. 0101 Location-dependent Connection Plant-accesspoint cap cp 0101 add(cap) rm(cap) Private area

23. Ad hoc networking • A team of experts meet in a site where a new plant must be established • Experts can interact locally by using an ad hoc network, sharing data and resources • Occasionally connection to the headquarters might be needed to check additional information

24. Local area Local area Ad hoc networking Headquarters Headquarters

25. Disconnection • A software engineer works in isolation • At a given point she dials up and gets reconnected to a virtual community server • She downloads work updates • She asks for help and goes offline • Later she reconnects to the virtual community: • She contacts one of the connected experts • She establishes a synchronous communication • After acquiring enough information she logs off • Finally, when she ends her work, she logs on and uploads the artifacts

26. Disconnection c 0100 s2 add(c) rm(c) add(c) add(c) s2 rm(c)

27. Remarks • Proposed extensions can be “expressed” in standard Klaim; • Klaim’s Logical framework can be automatically applied to extended Klaim; • Klaim’s Types for Access Control can be easily extended too. • Proposed extensions can be “expressed” in standard Klaim; • Klaim’s Logical framework can be automatically applied to extended Klaim; • Klaim’s Types for Access Control can be easily extended too.

28. Comparison with Ambients • Clusters do not move • Can intersect • Represent a communication ability, not necessarily an environment • Still locality-aware • More similar to channels

29. Translation in standard Klaim • A cluster c becomes a node sc • If s belongs to c then tuple (s) is in the TS of sc and (cluster, sc) in the TS of s • newc becomes newloc • add(c) becomesout(self)@sc.out(cluster, sc)@self • rm(c) becomesin(self)@sc.in(cluster, sc)@self

30. Translation in standard Klaim • Communication and migration operations are translated into sequences of operations that first test for the presence of a cluster and then perform the operation • A counter should be used in order to exhaustively examine all the clusters to which a node belongs

31. Extending the implementation

32. Connecting to a Klava Net hostnet.dsi.unifi.it $> java Klava.Net Starting Net on port 9999 150.217.14.14 $> java client2 hostnet.dsi.unifi.it 9999 Connecting to hostnet.dsi.unifi.it:9999 ... Login as client2 ... Login successful!

33. Communication in Klava Net s1 s2

34. Net s1 s2 Extending the implementation Net s2 s1

35. c1 c2 s1 s2 s3 Extending the implementation c2 c1 s2 s3 s1

36. Future work • Extend the implementation • Apply the extensions to our existing frameworks • Merge with Structured Nets

37. Structured Nets • Ordering relation on nodes (<): is-parent-of • Routing function (): the nodes that have to be crossed to reach a site • System operations (sys(t)): to access and modify the structure of the net