[Coco] The Problem with flawed networking options

[Brett Gordon]

The problem with networking on such devices boils down to one of
multiplexing.  Multplexing is the combination of more than one channels of
communication into one logical/physical transmission medium.  Basically,
your Drivewire4 (via it's Vports mechanism) and the ESP8266 takes several
network TCP connections and throws them together on the same line.  Our job
as programmers and implementers, is to demultiplex all these channels and
send them upstream to our Kernels, processes, tasks, etc....  The system is
supposed to work like the multiplexer and demultiplexer even don't exist.
Every user application should be able to look at each channel as a separate
discrete reliable connection.  And because the machines, pocesses, tasks,
threads, on each is side of the connection most definitely work at
different speeds, some sort of flow control is required to maintain a
reliable connection.  This means each logical connection must have it's own
flow control.  This is the logical version of DTR/CTS or DCD/DTR, in
old-fashioned modems.  In Drivewire4 and the ESP8266 this control does not
exist.  In the ESP8266's case, it just breaks up incoming data from the
different TCP connections and blams all the data to the serial port.

example for discussion:

Process A: Is "responsible" for getting data from TCP connect #1.
Process B: Is ' ' ' '  TCP connection #2

You (or your OS) decide Process A must sleep (be turned off) and do nothing
for something else important.  Meanwhile, process B is servicing the data
coming in on TCP connection #2.  There's no way to turn off process A's
incoming data... it just keeps coming!  Process B, however is starving for
TCP information, it can't get it fast enough....

In Drivewire, the only solution is to shutdown flow for *all* channels.
You definitely keep the data consistant and reliable, this way.  But now
process B is starved (indefinitely).   What if we SUSPEND process A (and
walk away).... Eventually, all your buffers** will fill, and your system
will be forced to suspend ALL of the tcp connections.

The esp8266 lacks even the ability to shut down the multiplexed signal.
 (AKA no hardware handshaking).  :(

This is *not* a particularly difficult problem to solve.  TCP/IP itself
solves this problem by providing a way to throttle or even completely
shutdown the dataflow from the other side, FOR EACH CONNECTION.

Please keep this in mind if you are extending the Drivewire Vport stuff, or
attempting to use the ESP8266 for anything other than a one connection at
one time pony.

For this reason, in Fuzix, we've decided to abandon any networking hopes
for Drivewire or the ESP8266.  (This doesn't mean that drivewire isn't
extremely helpful as a tool, and generally a "good thing" - it's only the
networking/vport stuff that isn't worth it. )

*** No amount of buffing will be sufficient to solve this problem - you
*will* run out of memory.

Cheers,

-- 
Brett M. Gordon,
beretta42 at gmail.com