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. 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. '''Paradigmatic 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 (c) is considered negligible, such that there is no requirement for multiple threads of control to intervene, provide input to, or suspend processing. The '''Paradigmatic 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. These two models serve well in many cases, but not in all. (todo: intervening network/control/sensor activity.) <>Enter Category Here