KRoC.net – Overview Adding Mobility to • Extension to KRoC Networked Channel-Types • Allows the distribution of occam- π channels (and channel-types) over networks Mario Schweigler Computing Laboratory, University of Kent • Utilises new occam- π features to improve Canterbury, UK efficiency of implementation CPA 2004: Mario Schweigler: Adding Mobility to KRoC.net 1 CPA 2004: Mario Schweigler: Adding Mobility to KRoC.net 2 Contents Components of KRoC.net • Consists of two essential parts: • Components of KRoC.net – KRoC.net kernel • Related extensions in occam- π – Supportive code • Architecture and terminology • KRoC.net kernel implemented (largely) in • Network-handles occam- π itself • Network-channels and Network-channel-types – Allows efficient and secure implementation (NCTs) • Supportive code to interface the KRoC.net kernel: • Mobility of NCT-ends – Compiler-generated code • Conclusions and future work – Code in the occam- π kernel (KRoC runtime system) CPA 2004: Mario Schweigler: Adding Mobility to KRoC.net 3 CPA 2004: Mario Schweigler: Adding Mobility to KRoC.net 4 Structural Integrity in occam- π Related Extensions • Structural integrity support • Motivation: – New dynamic occam- π features have • Mobile processes introduced hidden communication routes – Process header no longer clearly shows the interface of a process to its environment • Disadvantage compared to classical occam • A bit like in OO languages – but we want to do better! CPA 2004: Mario Schweigler: Adding Mobility to KRoC.net 5 CPA 2004: Mario Schweigler: Adding Mobility to KRoC.net 6 1
Structural Integrity in occam- π Structural Integrity in occam- π – Assignment/Communication: • New set of rules proposed (feedback welcome): GATE channel-type-end parameters have VAL semantics – d) – Definition: they may not be changed inside the process in whose a) Channel-type-end parameters may be qualified as being header they are declared. GATE or HOLE . GATE and HOLE parameters are live . GATE , HOLE and dead channel-type-ends may be freely e) assigned/communicated to each other as long as this does b) All other channel-type-ends are dead (i.e. locally declared not break Rule (d). channel-type-end-variables and parameters not qualified as GATE or HOLE ). – Parameter-Passing: Arguments for GATE parameters may only be live variables f) – Usage: – unless the process is being FORK ed. If the process is c) A process may not communicate over a dead channel-type- being FORK ed, both live and dead arguments are allowed, end. as long as this does not break Rule (d). CPA 2004: Mario Schweigler: Adding Mobility to KRoC.net 7 CPA 2004: Mario Schweigler: Adding Mobility to KRoC.net 8 Structural Integrity in occam- π Structural Integrity in occam- π Inside the scope of a CLAIM , a claimed SHARED channel- g) • Aim is that processes interact with environment type-end may be passed as an argument only to a non- only through formally declared live parameters shared GATE parameter of a process that is not being FORK ed. – GATE s are fixed HOLE parameters are initially undefined when a process h) – HOLE s may be dynamically mapped to another starts. Arguments for HOLE parameters may be outer channel-type-end by the process itself HOLE parameters of matching type which must be currently undefined, or the keyword HOLE . The latter may – External shape of the process does not change only be supplied to FORK ed processes. HOLE parameters • FORK ing may threaten structural integrity as have no return value (i.e. for the calling process they are still undefined when the callee process terminates). well i) Arguments for dead parameters may be dead or HOLE – It is proposed to ‘label’ FORKING PROC s so that the variables – unless the process is being FORK ed. If the calling process is aware that a callee might fork process is being FORK ed, GATE variables are also allowed another process as arguments, as long as this does not break Rule (d). CPA 2004: Mario Schweigler: Adding Mobility to KRoC.net 9 CPA 2004: Mario Schweigler: Adding Mobility to KRoC.net 10 Structural Integrity in occam- π Mobile Processes • Important for KRoC.net: • Impact on KRoC.net: – The header of a MOBILE PROC ess may only contain – Important when moving NCT-ends ‘synchronisation objects’ like channels, barriers, etc., – Since communication is only possible over live ends, as well as GATE or HOLE channel-type-ends. It may there is no need to set up low-level network not contain data items or dead channel-type-ends. infrastructure when an NCT-end is moved into a dead • Clean interface when moving mobile processes variable to remote nodes – Thus, NCT-ends can be passed more efficiently – Moving workspace of the process between many nodes without the overhead of – Moving channel-type-ends that are stored in the unnecessarily setting up low-level network workspace of the process infrastructure on intermediary nodes • Channel-types stretched between nodes CPA 2004: Mario Schweigler: Adding Mobility to KRoC.net 11 CPA 2004: Mario Schweigler: Adding Mobility to KRoC.net 12 2
Definitions Definitions • A node is an occam- π program which is using • A group of nodes forms a logical KRoC.net, i.e. whose main process has declared a application . network-handle (see a few slides later). – In the non-networked world, node and application would be congruent. In the • A network-channel-type (NCT) is a channel-type networked world, an application is made up that connects several nodes, i.e. whose ends are of several nodes. on more than one node. A network-channel is the • Nodes can only communicate over NCTs that networked version of a ‘classical’ occam channel. belong to the same application as they do • Each NCT can only connect nodes of the same application CPA 2004: Mario Schweigler: Adding Mobility to KRoC.net 13 CPA 2004: Mario Schweigler: Adding Mobility to KRoC.net 14 Definitions Definitions • A Channel Name Server (CNS) is an external server • The network-type is the type of a network that administrates applications, nodes and NCTs. infrastructure used by KRoC.net. – Each application has a name that is unique within the – Every network-type has its own KRoC.net kernel . If a CNS by which it is administrated. node declares a network-handle of a particular network-type, an instance of the respective KRoC.net – Within the application, each node and each NCT has a kernel will be started. unique name or automatically assigned ID. Each node has to register with a CNS before it can do any – TCP/IP currently only supported network-type network communication. • Adding support for others will be relatively easy, as the front- end of the KRoC.net kernel (which the supportive code – NCTs are either allocated under an application- interfaces) is the same for all network-types; just the back- unique name explicitly via the CNS, or implicitly by end (the ‘network driver’) needs to be exchanged. moving ends of locally allocated channel-types to remote nodes. CPA 2004: Mario Schweigler: Adding Mobility to KRoC.net 15 CPA 2004: Mario Schweigler: Adding Mobility to KRoC.net 16 Network-Handles Network-Handles • Built on the new concept of structural integrity • Network-handles may be typed . If declared by the main process, they must be typed: • To be able to allocate NCT-ends and network- PROC main (CHAN BYTE keyb, scr, err, channel-ends, a process must declare a network- GATE NET.HANDLE $TCPIP ! net) handle as a GATE in its header ... do stuff using ‘net’ : • Network-handle is the client-end of a channel- – This will create supportive code that calls an instance type defined in KRoC.net library (the server-end of the TCP/IP version of the KRoC.net kernel is held by the KRoC.net kernel): • Network-handles may be untyped if declared in CHAN TYPE NET.HANDLE a non-main process: MOBILE RECORD PROC my.proc (<...>, GATE NET.HANDLE! net, <...>) CHAN NET.HANDLE.REQ req?: ... do stuff using ‘net’ CHAN NET.HANDLE.REPLY reply!: : : CPA 2004: Mario Schweigler: Adding Mobility to KRoC.net 17 CPA 2004: Mario Schweigler: Adding Mobility to KRoC.net 18 3
Recommend
More recommend
