Difference between revisions of "Talk:Nodal-wikid.pl"
m |
(Public update cycle and class-trees) |
||
| Line 38: | Line 38: | ||
=== Nodal === | === Nodal === | ||
| + | ==== Class & Instance ==== | ||
| + | Part of the generic organisation model is the splitting and joining of a class into a tree of regions from global scale down to local. Each instance has a public update cycle which determins the booking phase and the "closing time" after which the state for that cycle is finalised and publically available. All update cycles are harmonically related giving rise to the so called syncronous domain. Class trees are dynamic and dependent on regional resource availability. | ||
| + | |||
==== Identity ==== | ==== Identity ==== | ||
| − | The process of | + | The process of managing globally-unique identifiers for nodes in the [[Nodal Network]] is the main applications of the syncronous domain, and the syncronous domain relies on this ''Identity'' application for its own functionality. |
| − | |||
| − | |||
| − | + | Guids are booked in ranges, a range consists of two binary numbers, one is the first guid in the range, the other is the exponent of the number of guids in the range. This guid-booking system forms a class-tree like any other application within the [[Nodal Network]], and the size of the ranges and the update period depend on the scale of the instances operations. | |
==== Persistence ==== | ==== Persistence ==== | ||
Persistence requires the guid application, and visa-versa, so they are both ''siblings''. The editing can be programmed easily into [[server.pl]] since no history is required at this level (because ''history'' is anpther nodal application), so we'll use the current ''NodalSpace::load()'' method using local filesystem storage rather than the local [[XmlWiki]] database. This approach has the advantage of allowing [[peerd]] to become independent of [[wikid.pl]] sooner, and doesn't increase the dependency of the peer on a local wiki or database server. | Persistence requires the guid application, and visa-versa, so they are both ''siblings''. The editing can be programmed easily into [[server.pl]] since no history is required at this level (because ''history'' is anpther nodal application), so we'll use the current ''NodalSpace::load()'' method using local filesystem storage rather than the local [[XmlWiki]] database. This approach has the advantage of allowing [[peerd]] to become independent of [[wikid.pl]] sooner, and doesn't increase the dependency of the peer on a local wiki or database server. | ||
| + | Later, when persistence is described nodally, it will simply be the adding of various storage resources to the repitoir of transport resources used by the class-tree syncronisation. That way change propagates not only to diverse peer-caches, but also to diverse storage media. | ||
<table class=document-code><tr><td>[[+peer dev links]]</table> | <table class=document-code><tr><td>[[+peer dev links]]</table> | ||
Latest revision as of 09:37, 12 May 2006
|
Contents
- 1 Session handlers
- 2 The way it's done now, but still being debugged
- 3 Nodal
- 4 Example peer log including change-propagation bug
- 4.1 First interface connects to server
- 4.2 Peerd connects back to server on new stream
- 4.3 Server receives a change-event from wiki (forwards to interface successfully)
- 4.4 A second interface connects to server
- 4.5 Peerd connects back with a new stream and a second session-handler is spawned
- 4.6 Server receives a second change-event from wiki (but it does NOT forward to either of the two interfaces)
- 4.7 The interfaces are closed
Session handlers
This script will now be used to talk to the session-handlers instead of server.pl. Its server.pl that receives the initial connection request because its the one listening on the socket, but now it will pass its session-handler-handle to nodal-wikid.pl and remove it from its own IO::Select list.
sessionHandler() is listed under nodal-wikid.pl in the script-tree even though its actually spawned by server.pl, because server.pl passes the handle on to the peerd() instance and takes no further interest in it (removes it from its IO::Select list).
How does it do this? server.pl has a handle to nodal-wikid.pl (the $::peerdHandle) because it connects back to its parent when it spawns. When server.pl spawns a session-handler it passes both the newly connecting peer.swf handle and the global $::peerdHandle handle as spawn-parameters. --Nad 10:04, 17 Apr 2006 (NZST)
- Note that from the perspective of the peerd thread, all incoming information appears to come from server.pl, because the session-handler threads connect using the $::peerdHandle which was created by peerd's initial connection to server.pl. This means that peerd must determine which of the streams is really the parent and then can treat all others as session-handlers. --Nad 15:45, 18 Apr 2006 (NZST)
- This may not be quite the right way of doing it, because it means all the session-handlers are sharing the one stream... --Nad 15:53, 18 Apr 2006 (NZST)
The way it's done now, but still being debugged
New interface connection
- A peer.swf sends a connect message to peer:port
- server.pl receives the message and asks peerd to connect back on a new stream. The new peer.swf stream-identity is also passed in the message to peerd.
- peerd receives the message and responds by establishing a new connection back to server.pl passing the peer.swf stream-identity back again.
- server.pl receives this message back from peerd and spawns a new session-handler passing both the peer.swf handle and the handle of the new peerd stream.
- The session-handler sends an introduction to the peer.swf
Change notification from an XmlWiki
- A page in the wiki is saved and the notify-peer.php transform executes
- notify-peer.php sends a change command to peer:port
- server.pl receives the messages and forwards it to the peerd thread
- peerd updates the nodal structure and propagates changes to each session-handler
- the session-handlers forward the nodal changes to their respective peer.swf's
Change notification from a peer.swf
- The stream between the peer.swf and its session-handler thread are already established
- The peer.swf's session-handler receives the incoming data
- The session-handler may respond directly to the peer.swf, or
- Propagates changes up to the peerd.
Nodal
Class & Instance
Part of the generic organisation model is the splitting and joining of a class into a tree of regions from global scale down to local. Each instance has a public update cycle which determins the booking phase and the "closing time" after which the state for that cycle is finalised and publically available. All update cycles are harmonically related giving rise to the so called syncronous domain. Class trees are dynamic and dependent on regional resource availability.
Identity
The process of managing globally-unique identifiers for nodes in the Nodal Network is the main applications of the syncronous domain, and the syncronous domain relies on this Identity application for its own functionality.
Guids are booked in ranges, a range consists of two binary numbers, one is the first guid in the range, the other is the exponent of the number of guids in the range. This guid-booking system forms a class-tree like any other application within the Nodal Network, and the size of the ranges and the update period depend on the scale of the instances operations.
Persistence
Persistence requires the guid application, and visa-versa, so they are both siblings. The editing can be programmed easily into server.pl since no history is required at this level (because history is anpther nodal application), so we'll use the current NodalSpace::load() method using local filesystem storage rather than the local XmlWiki database. This approach has the advantage of allowing peerd to become independent of wikid.pl sooner, and doesn't increase the dependency of the peer on a local wiki or database server.
Later, when persistence is described nodally, it will simply be the adding of various storage resources to the repitoir of transport resources used by the class-tree syncronisation. That way change propagates not only to diverse peer-caches, but also to diverse storage media.
| +peer dev links |
Example peer log including change-propagation bug
First interface connects to server
Thu May 11 23:47:36 2006 : [server/stream3] New connection: Stream5 Thu May 11 23:47:36 2006 : [server/stream5] PEER command "connect" received from an instance of "interface" Thu May 11 23:47:36 2006 : [peerd] Message from server.pl: "connect-request/stream5"
Peerd connects back to server on new stream
Thu May 11 23:47:36 2006 : [server/stream3] New connection: Stream6 Thu May 11 23:47:36 2006 : [server/stream6] PEER command "session" received from an instance of "peerd/stream5" Thu May 11 23:47:36 2006 : [server/stream6] Spawned child (10787) for "sessionHandler" Thu May 11 23:47:36 2006 : [sessionHandler/10787] Session-handler( stream6, stream5, stream5 )
Server receives a change-event from wiki (forwards to interface successfully)
Thu May 11 23:47:50 2006 : [server/stream3] New connection: Stream5 Thu May 11 23:47:53 2006 : [server/stream5] PEER command "change" received from an instance of "notify-peer.php" Thu May 11 23:47:53 2006 : [server/stream5] Stream5 disconnected. Thu May 11 23:47:53 2006 : [peerd] Message from server.pl: "change/notify-peer.php" Thu May 11 23:47:53 2006 : [sessionHandler/10787] Msg received on stream6: "change/notify-peer.php"
A second interface connects to server
Thu May 11 23:48:11 2006 : [server/stream3] New connection: Stream5 Thu May 11 23:48:11 2006 : [server/stream5] PEER command "connect" received from an instance of "interface" Thu May 11 23:48:11 2006 : [peerd] Message from server.pl: "connect-request/stream5"
Peerd connects back with a new stream and a second session-handler is spawned
Thu May 11 23:48:11 2006 : [server/stream3] New connection: Stream7 Thu May 11 23:48:11 2006 : [server/stream7] PEER command "session" received from an instance of "peerd/stream5" Thu May 11 23:48:11 2006 : [sessionHandler/8327] Session-handler( stream7, stream5, stream5 ) Thu May 11 23:48:11 2006 : [server/stream7] Spawned child (8327) for "sessionHandler"
Server receives a second change-event from wiki (but it does NOT forward to either of the two interfaces)
Thu May 11 23:48:28 2006 : [server/stream3] New connection: Stream5 Thu May 11 23:48:28 2006 : [server/stream5] PEER command "change" received from an instance of "notify-peer.php" Thu May 11 23:48:28 2006 : [server/stream5] Stream5 disconnected. Thu May 11 23:48:28 2006 : [peerd] Message from server.pl: "change/notify-peer.php"
The interfaces are closed
Thu May 11 23:48:38 2006 : [sessionHandler/8327] Handles closed, Exit. Thu May 11 23:48:40 2006 : [sessionHandler/10787] Handles closed, Exit.
