[Ovmsdev] A promiscous wifi client

[Stephen Casner]

On Mon, 20 Nov 2017, Mark Webb-Johnson wrote:

> The general approach of async net libraries like mongoose seem to be
> that they don’t allow blocking, and that is why the send doesn’t
> send immediately. That said, I’ve seen implementations that at least
> _try_ to send immediately (and only queue it if that fails); however
> that can complicate the transmitter (which has to deal with the two
> possible cases).

It seems that it would not that difficult for mg_send() to use a
no-wait select() to check whether the socket is available for writing,
and if so, to proceed with actually sending it.  This could block if
the buffer space in the network stack is less than what mg_send() has
accumulated, but in most cases it would not block.

> The more general approach seems to be that if we want to send
> something big, we send a chunk, than wait for the MG_EV_SEND message
> to indicate that chunk has been sent, then queue the next chunk to
> go. That seems to work well in Mongoose. My issue is that the
> higher-level protocols in Mongoose don’t support that well (for
> example, HTTP client and server). Kind of disappointing. But, the
> basic low-level networking API seems ok.

The approach of sending in chunks does not fit well with our command
and console software architecture.  In particular for SSH, mg_send()
is called from the callback function in ConsoleSSH class that is
called when the wolfssh code wants to do sendto().  It is possible to
return EWOULDBLOCK to wolfssh, in which case the EWOULDBLOCK gets
returned from wolfSSH_stream_send() that is called from printf().  But
with everything in the NetManTask it is not possible to wait in the
printf() function because we have to return from the MG_EV_RECV event
callback to let NetManTask actually do the sending.

I wrote a new test function that is the RFC 864 character generator
like some systems implemented on port 19 in the early days of the
Internet.  It outputs a configurable number of 72-character lines,
defaulting to 1000.  Through SSH on my test unit only the first 134
lines survived, the rest were discarded.

Now, we can simply declare that in the interest of saving RAM we won't
be concerned about the output limits if we don't expect large
outputs in this application.  Or I could make changes to Mongoose
along the lines of what I suggested above.

                                                        -- Steve