***Tcl and Network/Process Control***

Tcl is very good for network/process-control systems because it has an event system built in, because it's strong on string manipulation, and most recently because it has [coroutines].  This is not surprising, really, because of its pedigree.  Tcl, as an embedded control language, has this kind of thing in its DNA (as the cliche goes.)

The purpose of this page it to explore, in abstract, the kinds of facilities Tcl provides across the whole range of network/process-control systems, and which language cliches are useful when Tcl facilities must be blended together, and where Tcl could be improved to suit these applications.

***Ideal Client/Server***

Most (if not all) network/control systems involve message passing of some kind. Request-response, indication-confirmation: a chunk of data arrives, something is done with it, and a chunk of data is returned to the caller.

'''Ideal Server''':  

   1. `session` starts,
   2. `request` is received,
   3. `processing` occurs,
   4. `response` is sent
   5. repeat 2-4
   6. `session` terminates.

''Lexicon'': `session` above can be synonymous with ''transaction'', ''connection'', ''pipeline''.

A simple example is a time-of-day server.  (1,2) A connection opens (implying a request,) (3) the current time of day is calculated and formatted, and (4) returned. (5,6) The connection is closed by the recipient.

This simple case is amply served by event-driven code which runs to completion.  Any time taken to perform `processing` is considered negligible, such that there is no requirement for multiple threads of control to intervene, provide input to, or suspend `processing`.

The '''Ideal Client''' looks very similar to the server:

   1. establish `session`,
   2. send `request`,
   3. wait for `response`,
   4. receive `response`,
   5. repeat 2-4,
   6. `session` terminates.

Each client state has 1:1 mapping to a presumed/hypothetical ideal server state.  And this is how we like it.  It makes life simpler to reason about.

An ideal client can be written [[Connect(); foreach request $requests {Send(); Receive();} Disconnect()]], and the current execution state '''is''' the current communication state ... the client can put its grubby index finger on one place in the code, and say "we have Connected, Sent, Received or Disconnected.  This is a considerable benefit in writing and reasoning about client code.

The idealised model is also useful in that it expresses (in plain English) the passivity of the server.  All of the verbs describing server processing are in the passive voice, all of the verbs describing client processing are in the active voice - consistent with how we think about clients and servers.


***Complexity 1 - the multi-client server***

These two models serve well in many cases, but not in all. In particular, the implicit control flow in the ideal client is mostly linear (or clearly nested loops) and single-threaded.



 (todo: intervening network/control/sensor activity.)

<<categories>>Enter Category Here