considering Software / hardware.
The blobs need to communicate with adjacent blobs.
Think that a telecomms network can be thought of as hardware, managed by blobs of software.
Every thing is managed by it's own blob of software represented by an object.
Process B would have its own blob of software.
Now group these objects into an array indexed by a name.
The example below is from a travelling post office coach. An array of parcels indexed by a label.
Have an associative array of objects.
Index the associative array by a string representing the instance of the object.
a[ "nodeName" ] = object()
The objects need the minimum of these methods.
.ts() - time slice called periodically, to process any received messages. .mailBox() - accept messages from other objects.
The Main loop would iterate through the objects calling the objects .ts() routine.
To communicate each object would send messages to each other's mailBox() function.
The circuits could be wet string, copper, time slice, VoIP RTP streams.
The switch is a software or hardware space time switch - Its a point of in-direction.
So there you have it.
http://www.mongodb.org/ - mongodb is a database using similar concepts.
It uses JSON and JavaScript
http://www.dougrice.plus.com/dev/WetString.htm - a web page with JavaScript and objects. - view its source.
JavaScript Simulator of Railway Block system. An array of Railway signal boxes signalling to each other.: http://www.dougrice.plus.com/wetString/blockSignalling/signalling.htm Theory: http://ccgi.dougrice.plus.com/cgi-bin/wiki.pl?Signalling
Given that the Process probably has a state machine which is broken down to functions called when an event happens. How are these grouped? How is the source code organised?
http://www.dougrice.plus.com/hp/Theory/rt_c.txt is an example to lay out code in a tidy way.
Each Process has a server to accept events, and a client to send events.
Each Process object implements a state machine where the code for each event needs to run without long waits.
The object stores the state data, ( or points to state data stored on its behalf in a database )
Are the functions named using process_state_event or process_event_state?
Each process is stored in an object. There are methods for each event. These could then call a method from a set of methods one for each event_state combination.
Group by:
Object[type][instanceId]_State_Event
There may be an number of different types of objects. The InstanceId is a label that identifies each instance of the object. In my example these could be Signal Box Name. Instance Type is signal box.( http://www.dougrice.plus.com/wetString/blockSignalling/signalling.htm )
Classic State Machine:- Documentation as in SDL diagrams. The state information is stored within the object. There may be a pointer to an array of data structures. ( ITU Q.703 and Q.704 have examples of this. )
Group by:
Object[type][instanceId]_Event_State
Event Driven State Machine:- Events are Interrupts, or polls of interrupt flags that indicate something to process. Windows has a dispatcher, and micro controllers have interrupt vectors. Test harnesses may have When statements. Delphi has call back functions.
Some test harnesses have When statements that allow events to run functions soon after the event is received. These when statements are run when the code sits in a wait awaiting a timer event.
These test harnesses had statements for state machines in the code, but lacked the instanceID. This meant the state machine could not be used for circuits. JavaScript has arrays of objects, which can have methods and data.
AWK is a popular scripting language lacks structures or objects. Associative arrays can be used to structure data.
The grouping can be modelled in AWK scripts using notation like:
array of objects[ "type_instance_parameter" ] = value
if you need storage for each event handler:
array of objects[ "type_instance_event_parameter" ] = value
It might be better to use : _ and . to be more conventional.
Local variables, at various points in the data structure:-
arrayName[ "type[instance].parameter" ] = value arrayName[ "type[instance].event.parameter" ] = value arrayName[ "type[instance].state.parameter" ] = value
arrayName[ "type[instance].event_state.parameter" ] = value
A way of thinking this, is think of containers with a label written on the side. See the Travelling Post office picture above.
Each container can store what it stores, but two containers cannot store the same item, and no two containers are allowed to have identical labels.
If multiple containers have the same label, the contents must be considered distributed and there must be a way to cope with this. This could be that case when the containers are on multiple machines, and the machine name is not part of the name on the label.
There is a term "primitive" which is a function whose function is defined to explain how it works.
The Client Server model is a well known model. Is it suited for my wet string theory.
A Server awaits connections from the clients. How long does the connection exist for?
SIP school lesson 1 states that a SIP soft-phone client has a client and server. The client makes outgoing calls and the server receives incoming calls. A SIP soft-phone has to register with the proxy to enable it to receive calls.
| endpoint A | endpoint B | endpoint C | endpoint D |
| unknown | known | known | unknown |
Unknown to known must be Client Server
Peer to Peer need known to known
Given that the processes in a telephony system, have concurrent calls modelled using independent callers.
The Poisson Distribution characterises this. ( http://en.wikipedia.org/wiki/Poisson_distribution ). Calls start and end with no knowledge to each other. The order of events is not known, so an event driven model is normally used. Some events have parameters using name=value tags. These can occur in any order with in the message, so extracting parameters is also "event driven".
You have to link the objects together.
For C7 the objects are linked by the message Transfer part, MTP ( ITU Q.70x ).
To the user part, MTP is available or not. If not available, then user parts do not buffer messages, and timers are required to protect the protocols from lock up.
ISUP has timers that cause messages to be resent. This implies that the messages are not buffered by MTP.
![[Home]](../ipstats.gif)
while(true){
poll for timer events
get message and pass it to process for processing.
poll for messages
get message and pass it to process for processing.
}
Most of the examples block
-----------------------------------------------------------------------------
-- TCP sample: Little program to dump lines received at a given port
-- LuaSocket sample files
-- Author: Diego Nehab
-- RCS ID: $Id: listener.lua,v 1.11 2005/01/02 22:44:00 diego Exp $
-----------------------------------------------------------------------------
local socket = require("socket")
host = host or "*"
port = port or 8080
if arg then
host = arg[1] or host
port = arg[2] or port
end
print("Binding to host '" ..host.. "' and port " ..port.. "...")
s = assert(socket.bind(host, port))
i, p = s:getsockname()
assert(i, p)
cnt = 0
while cnt < 10 do
print("Waiting connection from talker on " .. i .. ":" .. p .. "...")
c = assert(s:accept())
print("Connected. Here is the stuff:")
l, e = c:receive()
while not e do
print(l)
l, e = c:receive()
c:send("ack\n")
end
print(e)
cnt = cnt + 1
end
Talker:-
-----------------------------------------------------------------------------
-- TCP sample: Little program to send text lines to a given host/port
-- LuaSocket sample files
-- Author: Diego Nehab
-- RCS ID: $Id: talker.lua,v 1.9 2005/01/02 22:44:00 diego Exp $
-----------------------------------------------------------------------------
local socket = require("socket")
host = host or "localhost"
port = port or 8080
if arg then
host = arg[1] or host
port = arg[2] or port
end
print("Attempting connection to host '" ..host.. "' and port " ..port.. "...")
c = assert(socket.connect(host, port))
print("Connected! Please type stuff (empty line to stop):")
l = io.read()
while l and l ~= "" and not e do
assert(c:send(l .. "\n"))
l = io.read()
end
The examples above do not seem to have protective timers and the functions block awaiting events.
To get a Peer to Peer typing app, adding flush() to overide buffering seemed to make the examples flow better.
There is a compromise between buffering and flushing as sending a character across TCP/IP can add a lot of protocol "wrapping"
In the examples above you allocate a socket and either accept or connect a connection.
It is my opinion these examples are for short duration connections.
Some peer to peer protocols like C7 ISUP and MTP can lose the MTP, and protective timers and repeat sends handle broken mtp.
Can TCP/IP do this?
It is my opinion these are single port stubs.
I tried to experiment closing the connection c in the listener example without telling the talker.
socket:bind()
while( needed ) begin
c= socket:accept()
c:read()
c:write()
c:close()
end
socket:close()
Likewise: Talker has a socket You do a c = socket:connect() , then a short protocol of c:write then c:read(), then a socket:close()
c: socket:connect()
c:write()
c:read()
c:close()
This is not Peer to peer from known endpoint to known endpoint, and coping with MTP outages using protective timers and periodic repeat of rel or block messages.
The command line is very useful.
I can pipe output from one program into an adjacent program
cat file.txt | more | more | more | more
I can use putchar() to emit a character and use getchar() to read a character. The pipe joins commands.
However getchar() blocks, so can only listen to one adjacent process. putchar() can block if the pipe is busy.
The pip could be a serial device like a UART.
I tried to emulate a Z80 and terminal in a simple C program. My Minimal component Z80 emulator system based on Grant's multicomp.
https://github.com/doug-h-rice/virtual-multicomp
The virtual z80 board has a UART to communicate, so my Terminal also needs a software UART in the code.
The emulated CPU communicates with the host using the UART.
This is summarised as a TX and RX register and two flags TxEmpty and RxFull.
Emulated CPU - UART:-
A write to TX resets TxEmpty. A read from RX resets RxFull.UART - Host:-
A read from TX sets TxEmpty. A write to RX sets RxFull.
If you have a FIFO then there need to be changes.
TxEmpty may need to be TxSpaceAvailable RxFull becomes RxAvailable
Threads are used and the thread may block. I think that a thread is like a Micro controller peripheral.
They can block and if getchar() gets a character, they can signal like microcontroller periperal.
The thread can communicate like a microcontroller peripheral and the main program can poll or use a call back function.
Can you consider a Microcontroller as a Multi Processor device?
Each peripheral is clocked and can interupt the processor and act in their own right.
Images below copyright Microchip.
clocks
Timer0
Interesting stuff!