Undaunted by hurdles, I've altered the implementation to utilize TCP from UDP. The TCP offering, sadly, was not nearly as straightforward as UDP. Sadly, one can't use tcpip - it's marked for deprecation. Even sadder, one can't use the 'tcpserver' implementation offered within Matlab, either. Its one connection limit, followed by session specific data, means there's literally no way to write to one tcpserver and relay the data to a second to read out from, as the session that writes the data doesn't enable another session to read the information - even if the tcpserver could handle two connections. Worse - try finding a session layer router - preferably implemented to run on an OS.
Of course, OCP, or more likely MQTT, achieves the goal...I guess I am just providing alternatives for others along the way, as this seems one of the least documented paths.
So..... back to the TCP solution....
One needs to utilize a TCP server on the host OS of the simulation. I used netcat on macOS. Once that's out of the way, the rest is downhill. Steps are, (some on the host OS, some with the Simulink/Matlab evironment):
- create a FIFO as a communication path between pipeline stages: "mkfifo data"
- start a 'producer' server and send data to FIFO: ... "nc -v -k -l 1090 >data"
- start a 'consumer' server and move data from FIFO to server.... "nc -v -k -l 1091 <data"
- use the Instrument Toolbox "TCP Send", and have the producer send to the IP address/port combination
- use the Instrument Toolbox "TCP Recieve", and have the consumer receives from the IP address/port combination
With those five wonderfully easy steps, one can utilize the Instrument Toolbox and craft up a distributed event simulation using Matlab/Simulink - yet - with downsides (which is why the OCP or MQTT options are the more desirable)
The issues I am still working out are:
a.) timing of data into and out of the FIFO, seems skewed to the producer
b.) time dialation to the consumer, as the FIFO provides zero time-tags to the data
