Author: derek Date: Thu Nov 9 18:02:28 2006 New Revision: 163 Added: sofaswitch/trunk/callflow/docs.cfg Removed: sofaswitch/trunk/callflow/callflow.dxy Modified: sofaswitch/trunk/Makefile sofaswitch/trunk/callflow/Makefile.am sofaswitch/trunk/callflow/docs/executionflow.dxy sofaswitch/trunk/callflow/docs/overview.dxy sofaswitch/trunk/intro.html sofaswitch/trunk/message.cxx Log: Work on improving the current documentation. Add in links to CallFlow utility, so this is part of SofaSwitch docs. Modified: sofaswitch/trunk/Makefile ============================================================================== --- sofaswitch/trunk/Makefile (original) +++ sofaswitch/trunk/Makefile Thu Nov 9 18:02:28 2006 @@ -29,20 +29,22 @@ all: - @cd sofa ; make both - @cd am ; make both - @cd voip ; make both - @cd mcu ; make both - @cd server ; make both - @cd sound ; make both + @cd sofa ; make both + @cd am ; make both + @cd callflow; make both + @cd mcu ; make both + @cd server ; make both + @cd sound ; make both + @cd voip ; make both all2: @cd sofa ; make -j 2 both - @cd am ; make -j 2 both - @cd voip ; make -j 2 both - @cd mcu ; make -j 2 both - @cd server ; make -j 2 both - @cd sound ; make -j 2 both + @cd am ; make -j 2 both + @cd callflow; make both + @cd mcu ; make -j 2 both + @cd server ; make -j 2 both + @cd sound ; make -j 2 both + @cd voip ; make -j 2 both @@ -50,18 +52,20 @@ @rm -fR $(HOME)/sofa_docs @rm -fR html @doxygen docs.cfg - @cd am ; doxygen docs.cfg - @cd mcu ; doxygen docs.cfg - @cd server ; doxygen docs.cfg - @cd sound ; doxygen docs.cfg - @cd sofa ; doxygen docs.cfg - @cd voip ; doxygen docs.cfg - @mv am/html html/am - @mv mcu/html html/mcu - @mv server/html html/server - @mv sofa/html html/sofa - @mv sound/html html/sound - @mv voip/html html/voip + @cd am ; doxygen docs.cfg + @cd callflow ; doxygen docs.cfg + @cd mcu ; doxygen docs.cfg + @cd server ; doxygen docs.cfg + @cd sofa ; doxygen docs.cfg + @cd sound ; doxygen docs.cfg + @cd voip ; doxygen docs.cfg + @mv am/html html/am + @mv callflow/html html/callflow + @mv mcu/html html/mcu + @mv server/html html/server + @mv sofa/html html/sofa + @mv sound/html html/sound + @mv voip/html html/voip @mv html $(HOME)/sofa_docs Modified: sofaswitch/trunk/callflow/Makefile.am ============================================================================== --- sofaswitch/trunk/callflow/Makefile.am (original) +++ sofaswitch/trunk/callflow/Makefile.am Thu Nov 9 18:02:28 2006 @@ -10,7 +10,7 @@ docs:dox dox: - doxygen callflow.dxy + doxygen docs.cfg veryclean:distclean Added: sofaswitch/trunk/callflow/docs.cfg ============================================================================== --- (empty file) +++ sofaswitch/trunk/callflow/docs.cfg Thu Nov 9 18:02:28 2006 @@ -0,0 +1,223 @@ +# Doxyfile 1.4.6 + +#--------------------------------------------------------------------------- +# Project related configuration options +#--------------------------------------------------------------------------- +PROJECT_NAME = CallFlow +PROJECT_NUMBER = 1.0.0 +OUTPUT_DIRECTORY = +CREATE_SUBDIRS = NO +OUTPUT_LANGUAGE = English +USE_WINDOWS_ENCODING = NO +BRIEF_MEMBER_DESC = YES +REPEAT_BRIEF = YES +ABBREVIATE_BRIEF = +ALWAYS_DETAILED_SEC = NO +INLINE_INHERITED_MEMB = NO +FULL_PATH_NAMES = YES +STRIP_FROM_PATH = +STRIP_FROM_INC_PATH = +SHORT_NAMES = NO +JAVADOC_AUTOBRIEF = NO +MULTILINE_CPP_IS_BRIEF = NO +DETAILS_AT_TOP = NO +INHERIT_DOCS = YES +SEPARATE_MEMBER_PAGES = NO +TAB_SIZE = 8 +ALIASES = +OPTIMIZE_OUTPUT_FOR_C = NO +OPTIMIZE_OUTPUT_JAVA = NO +BUILTIN_STL_SUPPORT = NO +DISTRIBUTE_GROUP_DOC = NO +SUBGROUPING = YES +#--------------------------------------------------------------------------- +# Build related configuration options +#--------------------------------------------------------------------------- +EXTRACT_ALL = YES +EXTRACT_PRIVATE = NO +EXTRACT_STATIC = NO +EXTRACT_LOCAL_CLASSES = YES +EXTRACT_LOCAL_METHODS = NO +HIDE_UNDOC_MEMBERS = NO +HIDE_UNDOC_CLASSES = NO +HIDE_FRIEND_COMPOUNDS = NO +HIDE_IN_BODY_DOCS = NO +INTERNAL_DOCS = NO +CASE_SENSE_NAMES = YES +HIDE_SCOPE_NAMES = NO +SHOW_INCLUDE_FILES = YES +INLINE_INFO = YES +SORT_MEMBER_DOCS = YES +SORT_BRIEF_DOCS = NO +SORT_BY_SCOPE_NAME = NO +GENERATE_TODOLIST = YES +GENERATE_TESTLIST = YES +GENERATE_BUGLIST = YES +GENERATE_DEPRECATEDLIST= YES +ENABLED_SECTIONS = +MAX_INITIALIZER_LINES = 30 +SHOW_USED_FILES = YES +SHOW_DIRECTORIES = NO +FILE_VERSION_FILTER = +#--------------------------------------------------------------------------- +# configuration options related to warning and progress messages +#--------------------------------------------------------------------------- +QUIET = NO +WARNINGS = YES +WARN_IF_UNDOCUMENTED = YES +WARN_IF_DOC_ERROR = YES +WARN_NO_PARAMDOC = NO +WARN_FORMAT = "$file:$line: $text" +WARN_LOGFILE = +#--------------------------------------------------------------------------- +# configuration options related to the input files +#--------------------------------------------------------------------------- +INPUT = src docs . +FILE_PATTERNS = *.h *.dxy +RECURSIVE = NO +EXCLUDE = +EXCLUDE_SYMLINKS = NO +EXCLUDE_PATTERNS = +EXAMPLE_PATH = +EXAMPLE_PATTERNS = +EXAMPLE_RECURSIVE = NO +IMAGE_PATH = src docs +INPUT_FILTER = +FILTER_PATTERNS = +FILTER_SOURCE_FILES = NO +#--------------------------------------------------------------------------- +# configuration options related to source browsing +#--------------------------------------------------------------------------- +SOURCE_BROWSER = NO +INLINE_SOURCES = NO +STRIP_CODE_COMMENTS = YES +REFERENCED_BY_RELATION = YES +REFERENCES_RELATION = YES +USE_HTAGS = NO +VERBATIM_HEADERS = YES +#--------------------------------------------------------------------------- +# configuration options related to the alphabetical class index +#--------------------------------------------------------------------------- +ALPHABETICAL_INDEX = YES +COLS_IN_ALPHA_INDEX = 5 +IGNORE_PREFIX = +#--------------------------------------------------------------------------- +# configuration options related to the HTML output +#--------------------------------------------------------------------------- +GENERATE_HTML = YES +HTML_OUTPUT = html +HTML_FILE_EXTENSION = .html +HTML_HEADER = +HTML_FOOTER = +HTML_STYLESHEET = +HTML_ALIGN_MEMBERS = YES +GENERATE_HTMLHELP = NO +CHM_FILE = +HHC_LOCATION = +GENERATE_CHI = NO +BINARY_TOC = NO +TOC_EXPAND = NO +DISABLE_INDEX = NO +ENUM_VALUES_PER_LINE = 4 +GENERATE_TREEVIEW = NO +TREEVIEW_WIDTH = 250 +#--------------------------------------------------------------------------- +# configuration options related to the LaTeX output +#--------------------------------------------------------------------------- +GENERATE_LATEX = NO +LATEX_OUTPUT = latex +LATEX_CMD_NAME = latex +MAKEINDEX_CMD_NAME = makeindex +COMPACT_LATEX = NO +PAPER_TYPE = a4wide +EXTRA_PACKAGES = +LATEX_HEADER = +PDF_HYPERLINKS = NO +USE_PDFLATEX = NO +LATEX_BATCHMODE = NO +LATEX_HIDE_INDICES = NO +#--------------------------------------------------------------------------- +# configuration options related to the RTF output +#--------------------------------------------------------------------------- +GENERATE_RTF = NO +RTF_OUTPUT = rtf +COMPACT_RTF = NO +RTF_HYPERLINKS = NO +RTF_STYLESHEET_FILE = +RTF_EXTENSIONS_FILE = +#--------------------------------------------------------------------------- +# configuration options related to the man page output +#--------------------------------------------------------------------------- +GENERATE_MAN = NO +MAN_OUTPUT = man +MAN_EXTENSION = .3 +MAN_LINKS = NO +#--------------------------------------------------------------------------- +# configuration options related to the XML output +#--------------------------------------------------------------------------- +GENERATE_XML = NO +XML_OUTPUT = xml +XML_SCHEMA = +XML_DTD = +XML_PROGRAMLISTING = YES +#--------------------------------------------------------------------------- +# configuration options for the AutoGen Definitions output +#--------------------------------------------------------------------------- +GENERATE_AUTOGEN_DEF = NO +#--------------------------------------------------------------------------- +# configuration options related to the Perl module output +#--------------------------------------------------------------------------- +GENERATE_PERLMOD = NO +PERLMOD_LATEX = NO +PERLMOD_PRETTY = YES +PERLMOD_MAKEVAR_PREFIX = +#--------------------------------------------------------------------------- +# Configuration options related to the preprocessor +#--------------------------------------------------------------------------- +ENABLE_PREPROCESSING = YES +MACRO_EXPANSION = NO +EXPAND_ONLY_PREDEF = NO +SEARCH_INCLUDES = YES +INCLUDE_PATH = +INCLUDE_FILE_PATTERNS = +PREDEFINED = +EXPAND_AS_DEFINED = +SKIP_FUNCTION_MACROS = YES +#--------------------------------------------------------------------------- +# Configuration::additions related to external references +#--------------------------------------------------------------------------- +TAGFILES = +GENERATE_TAGFILE = +ALLEXTERNALS = NO +EXTERNAL_GROUPS = YES +PERL_PATH = /usr/bin/perl +#--------------------------------------------------------------------------- +# Configuration options related to the dot tool +#--------------------------------------------------------------------------- +CLASS_DIAGRAMS = YES +HIDE_UNDOC_RELATIONS = YES +HAVE_DOT = YES +CLASS_GRAPH = YES +COLLABORATION_GRAPH = YES +GROUP_GRAPHS = YES +UML_LOOK = NO +TEMPLATE_RELATIONS = NO +INCLUDE_GRAPH = YES +INCLUDED_BY_GRAPH = YES +CALL_GRAPH = YES +GRAPHICAL_HIERARCHY = YES +DIRECTORY_GRAPH = YES +DOT_IMAGE_FORMAT = png +DOT_PATH = +DOTFILE_DIRS = +MAX_DOT_GRAPH_WIDTH = 1400 +MAX_DOT_GRAPH_HEIGHT = 1800 +MAX_DOT_GRAPH_DEPTH = 10 +DOT_TRANSPARENT = NO +DOT_MULTI_TARGETS = NO +GENERATE_LEGEND = YES +DOT_CLEANUP = YES +#--------------------------------------------------------------------------- +# Configuration::additions related to the search engine +#--------------------------------------------------------------------------- +SEARCHENGINE = NO Modified: sofaswitch/trunk/callflow/docs/executionflow.dxy ============================================================================== --- sofaswitch/trunk/callflow/docs/executionflow.dxy (original) +++ sofaswitch/trunk/callflow/docs/executionflow.dxy Thu Nov 9 18:02:28 2006 @@ -7,7 +7,7 @@ \image html forloop.png -it will enter the forloop, and go around and around until the termination +it will enter the for loop, and go around and around until the termination condition is met. While processing each of the nodes in the supplied graph, it is ignoring Modified: sofaswitch/trunk/callflow/docs/overview.dxy ============================================================================== --- sofaswitch/trunk/callflow/docs/overview.dxy (original) +++ sofaswitch/trunk/callflow/docs/overview.dxy Thu Nov 9 18:02:28 2006 @@ -11,11 +11,12 @@ functionality and ease of integrating with exWidgets) and has been released under the MPL license. -Last updated 15 September 2006 Copyright (C) 2006 Indranet Technologies Ltd, All right reserved -\section WhyCallFlow Why do we neeed CallFlow ? +Author, Derek J Smithies, <derek@indranet.co.nz> + +\section WhyCallFlow Why do we need CallFlow ? My (DJS) initial thoughts on the design of SofaSwitch was that there would be individual entities (server, voip, am etc) all controlled by a custom script, written in some scripting language. I wrote the entities first, and @@ -26,18 +27,25 @@ original design. This had the unfortunate outcome of making those scripts invalid. A second lesson was learnt - python is not very good on threads. Things like the global interpreter lock started to get in the -way. python script. +way. Further, the scripts became a maintainence nightmare. This was +discouraging. At this stage, I was uncertain. Should I change to a different (and more superior) scripting language? Some thought and discussion showed that python -is the way to go. Choosing an unknonw (but superior?) language like XYZ would +is the way to go. Choosing an unknown (but superior?) language like XYZ would indeed solve the above problems, but introduce two new problems: 1)it is now much harder to get get going in the project and 2)it becomes much harder to -install sofaswitch. Minor considerations such as, "we might loose +install SofaSwitch. Minor considerations such as, "we might loose cross-platform features if we switch to XYZ" were part of the problem space. +Worse still, by demanding the scripting language is written in Python (or +Perl, or Lua, or C, etc) I was raising the bar for the system administrator +before he/she could use SofaSwitch. They were now reqired to learn the +scripting language and how SofaSwitch works. Everyone understands flowcharts - +if only there was a scripting language based on flowcharts. + Clearly, the way ahead was to write a custom utility to write the python -controlscripts. Now, we expect that some may wish to write their own python +control scripts. Now, we expect that some may wish to write their own python scripts. This is fine - you are welcome to learn from our current codebase. Given the modular structure of SofaSwitch, this is inevitable. Different modules will be glued together in different ways. @@ -48,19 +56,22 @@ \section WhatDo What does CallFlow do ? In this section, I describe, in overview, what CallFlow does -\li Draw the diagram of the call handling for one call +\li Draw the diagram of the particular processing required. \li Compile this to python, which creates two files. The first file describes the graph, and the second file describes the handling of the graph. The second file is "hardwired" to load that particular graph file. However, the second file is is, essentially, the same between every compile. \li You use Python to execute the second file, which loads the graph file. +\li Multiple threads of execution in the Python control script are handled + easily, by loading in graph files. Thus, on detecting an incoming call + (for example) a graph file to deal with one incoming voip call is loaded - \subsection history History \li 15 September 2006 - Created by Derek J Smithies \li 21 September 2006 - Add Why section Derek J Smithies +\li 10 November 2006 - spelling & textual improvements Derek J Smithies */ Modified: sofaswitch/trunk/intro.html ============================================================================== --- sofaswitch/trunk/intro.html (original) +++ sofaswitch/trunk/intro.html Thu Nov 9 18:02:28 2006 @@ -18,11 +18,12 @@ <large> <center> -<li><a class="el" href="jopal/html/index.html">voip handler</a> </li> +<li><a class="el" href="voip/html/index.html">voip handler</a> </li> <li><a class="el" href="mcu/html/index.html">conference utility</a> </li> <li><a class="el" href="server/html/index.html">message server</a> </li> <li><a class="el" href="am/html/index.html">answering machine</a> </li> <li><a class="el" href="sound/html/index.html">sound card utility</a> </li> +<li><a class="el" href="callflow/html/index.html">GUI to generate control code</a> </li> </center> </large> Modified: sofaswitch/trunk/message.cxx ============================================================================== --- sofaswitch/trunk/message.cxx (original) +++ sofaswitch/trunk/message.cxx Thu Nov 9 18:02:28 2006 @@ -2,14 +2,10 @@ \page pageMessageProtocol Message Protocol -The protocol used for control communications is described here, in the -following sections. Also described is the relationship between different -components, which is required for the communications protocol to make any -"sense". \li \ref secIntroduction \li \ref secMessageContents -\li \ref secSupervisorWorker +\li \ref secSofaSwitchEntities \li \ref secCurrentCommands \li \ref secServerCommands \li \ref secTransferUdp @@ -21,29 +17,44 @@ \section secIntroduction Introduction -Workers and Supervisors are the doers - entities that control voice -calls. The distinction between them is explained in section -\ref secSupervisorWorker. +As stated before, SofaSwitch consists of many different running applications, +where each different application may run on a different machine and will have +a different purpose. Consequently, there is a need for a standardised method +of communication between the applications which will work transparently across +OS's, hardware types, and network types. -The method by which one Worker/Supervisor sends messages to another -Worker/Supervisor is very simple. A text message is composed, sent to -the server via a TCP socket, which then relays the message on to the -desired destination. Thus, we have a star network. Every -Worker/Supervisor has one TCP connection to the server, for -sending/receiving messages relevant to/from the server. +The protocol used for control communications is described in this page. Also +described is the relationship between different components, which is required +for the communications protocol to make any "sense". -We are opposed to "micro management". Thus, a Supervisor is not required to -worry about the details of any one voice circuit. In fact, the only control a -Supervisor will have over any voice circuit is to create the Worker to handle -that voice circuit. Note however that the Supervisor will be able to report -the status of individual workers/voice circuits. +We describe the syntax for placing the control messages inside TCP +packets. Some justification is given for the choices made. However, there +will be some topics that no amount of justification/discussion will be +convincing enough. -Similarily, when two Workers have to arrange the transfer of audio -data between themselves, it is none of the Controller's business. The -controller should merely say to one worker, "arrange audio transfer -with that worker". Consequently, the Controller is not aware of what -port the Worker is using for audio +A key element in understanding why we chose where communication flows is that +we are opposed to "micro manaagement". By "micro management", we refer to the +practice where one part of the software has an excessive interest in the +minute details of another component in the software. For more details, see +\htmlonly +<a href="http://en.wikipedia.org/wiki/Micromanagement">wikipedia-micro management</a> +\endhtmlonly + +To illustrate, the Controlling entity directs two nodes to send audio between +them. There are two distinct methods for implementing this: +\li for the Controller to work out what ports are available in the two nodes, + and then advise both nodes to which port to send the audio data + \li two nodes are told they are talking to each other by the Controller. + Then, the two nodes discuss amongst themselves + how they communicate (which could be via tcp, bridging, pipes, etc) + +The first approach is micro management - the Controller does not need to know +about ports. Worse, it constrains the two nodes to only talk via network +ports. The second approach is harder - the nodes are all given some +"intelligence" and have to be able to respond to a wider range of messages. + + \section secMessageContents The contents of all messages Control communication is always via text messages on TCP sockets. The last @@ -56,37 +67,41 @@ Connect to this server. This server will then spawn of a TCPConnection class to listen for all further communications from switch. Node switch then sends a zero terminated string of - <center> "switch"0 </center> +to this server. This string identifies the remote node to this server. On +receipt of this string, the server can make a unique label for the +TCPConnection class, and add it to the internal list. Once the TCPConnection +class has been added to the internal list, full bidirectional comms is now +possible with node "switch". -to this server. This string identifies the remote node to this server. -On receipt of this string, the server can make a unique label for the -TCPConnection class, and add it to the internal list. Once the -TCPConnection class has been added to the internal list, full -bidirectional comms is now possible with node "switch". +The server assumes all remote nodes will correctly choose a valid unique ID. +My preference is that the supervisor connects with a label such as +"controller", "voip", or "am". Workers spawned by that supervisor have a +number appended to the supervisor's label. Thus, the voip supervisor connects +as "voip". All workers spawned by the voip supervisor will be called "voip1", +"voip2", etc. This naming scheme makes debugging somewhat easier, as you can +identify, from the label, the origin/destination of a message. + In some cases, the connecting node has no idea what unique ID to specify. It -will (in this case) use the string "?" and let the server assign a unique ID. +will (in this case) use the string "?"0 and let the server assign a unique ID. The connecting node can then use the command "whoami" to enquire of the server -to find out what unique ID was assigned. +to find out what unique ID was assigned. This indentification process is ideal +for Controllers. You can invoke a script which launches a new Controller to do +some adjustment, without worrying about "will this script correctly pick a +unique id?". -The server assumes all remote nodes will correctly choose a valid -unique ID. My preference is that the supervisor connects with a -label such as "controller", "voip", or "am". Workers spawned by -that supervisor have a number appended to the supervisor's -label. Thus, the voip supervisor connects as "voip". All workers -spawned by the voip supervisor will be called "voip1", "voip2", -etc. This naming scheme makes debugging somewhat easier, as you can -identify, from the label, the origin/destination of a message. - -A message sent to the server has the format -remoteNode : message - +A control message, which is sent via the server has the format +<center> + remoteNode : message +</center> The server changes the message, and sends it to the remote node as +<center> sourceNode : message +</center> Thus, this server has changed the message. This is acceptable, as it means that the receiving node is able to determine who sent the @@ -97,41 +112,77 @@ To illustrate, suppose A sends the message "status" to B. A sends to the sever - +<center> "B:status"0 (string, with a trailing zero byte) +</center> the server receives this packet and then sends to B - +<center> "A:status"0 (string, with a trailing zero byte) +</center> Note - the quotes are there to illustrate it is a string, and are not included in the packet. -\section secSupervisorWorker Supervisor and Worker -It is important to note that a sofaswitch application will have two distinct endpoints in it. -The application will have 1 Supervisor and multiple Workers. +\section secSofaSwitchEntities Entities provided by SofaSwitch +There are several distinct entities used by SofaSwitch. It is important to +understand the difference between them, and how the entities interact. + <center> <table width="600"> -<tr><td> Worker </td><td> handles commands associated with one particular voip circuit. - Thus, for a voice over IP application, there will be X workers - for the X active voice calls in the voip application. +<tr><td> Worker </td><td> handles commands associated with one particular audio circuit. + In a voip application, which is capable of handling 30 (say) concurrent calls, + there will be (at most) 30 active Workers. </td></tr> <tr><td> Supervisor</td><td> responsible for establishing (as required) new - Workers. It can be used to terminate the sofaswitch - application. Messages which are appropriate for a - particular Worker are never ever sent via the - supervisor </td></tr> -</table>. + Workers. It can be used to terminate the SofaSwitch + application. Messages which are appropriate for a particular + Worker are never ever sent via the Supervisor +</td></tr> +<tr><td>Server</td><td> is responsible for passing control messages between + different SofaSwitch entities. There is only one instance of + a Server in the SofaSwitch network, so all control messages + pass through the Server. Thus, the Server knows about every + active SofaSwitch entity. +</td></tr> +<tr><td>Controller</td><td> is responsible for generating control mesasges to + get things to happen. It is this entity who initiates + responses from the SofaSwitch system as real world events + happen. There may be multiple active Controllers - this is a + matter of implementation for the user. +</td></tr> +</table> </center> -Even the controller can be split up into a Worker/Supervisor -distinction. The Worker in the controller sends commands appropriate -to managing one current call. The Supervisor creates Workers to handle -new calls, as required. +Even the controller can be split up into a Worker/Supervisor distinction. The +Worker in the controller sends commands appropriate to managing one current +call. The Supervisor creates Workers to handle new calls, as required. How the +Controller is configured/written is entirely up to the user. We have provided +Python examples, and a graphical editor to generate those Python examples, but +the user may choose to implement a completely different system. + +Workers and Supervisors exist together inside one running application to +handle voice calls. The Worker is the only entity who "touches" raw audio +data. Everything else worries about control. The Supervisor is in direct +contact with 1 (or more) Workers. Thus, the supervisor is responsible for +Worker creation/initiation/deletion. There are several SofaSwitch +applications (am, mcu, voip), each of which contain one Supervisor and +multiple workers. By sending audio between the different workers, we can +create the functionality of a voice switch. + +We have a "star" shaped network, as all control messages go via the +server. However, this is not strictly true as raw audio will pass directly +between any two workers. Alternatively, audio is never ever passed through the +server. This design decision was made so that any extra burst of processing +required on the server will not slow down/interrupt audio traffic. Further, +removing audio traffic from the server reduces the load on the server +considerably. + \section secCurrentCommands Worker/Supervisor commands + The following commands are provided in this protocol. They are designed to be sent from a Worker/Supervisor to a Worker/Supervisor. Most will be sent by Workers, but there is no check @@ -186,10 +237,9 @@ Some commands are actioned by the server, and not passed on to the destination node. These commands do not have a destination node specified. They are therefore of the format: - - +<center> "command"0 - +</center> which contains no colon character, and is terminated by a zero byte. As before, the quotes are there to illustrate it is a string, and are not included in the packet. @@ -209,11 +259,13 @@ are. This command is useful when we are some controller who has connected to the server and asked the server to generate a unique Id for us. It is also a debugging tool from the command - prompt case - we can enquire of the server to check our ID. + prompt case - we can enquire of the server to report our ID. </td></tr> -<tr><td>adviseontermination remNode</td></td>This commands the server to (on this node - terminating) send a message to the specified node (remNode). The message - will advise remNode that this this node has died. +<tr><td>adviseontermination remNode</td><td>This commands the server to (on + this node terminating) send a message to the specified node + (remNode). The message will advise remNode that this this + node has died. Thus, the controller will get a message if the + box running the answer machine (for example) is unplugged. </td></tr> </table> </center>