There is more to do on this conversion of the Telnet Console to use
mongoose:
- When wifi service is shut down by command, my old implementation
would close the connections to the clients cleanly. The new
implementation with mongoose leaves them hanging. The way to
improve this may lie in the shutdown steps in ovms_netmanager.
- It looks like there may be a memory blocked leaked at each client
disconnection. I need to find that.
- I think I can improve how I handle the receive buffer and save
some more RAM.
I've also thought more about how to convert the SSH Console and will
take a stab at that as well.
-- Steve
On Fri, 17 Nov 2017, Stephen Casner wrote:
On Thu, 16 Nov 2017, Mark Webb-Johnson wrote:
We don't seem to have this issue with the webserver listener; that
uses mongoose (in netmanager). That doesn't have long-lived client
side connections, but the socket listen/accept functionality should
be similar. Not sure how mongoose handles it internally, but the
library seems quite robust.
Mongoose wakes up from the select() periodically to do polling so the
deletion of the task would not happen while in select().
I'm wondering if we can migrate to use that? It would probably save
a bunch of ram (as it doesn't need a task for each thread). We are
mostly single-user anyway.
I have converted console_telnet to use mongoose and netmanager in the
same manner as ovms_webserver. This eliminates the TelnetServer and
TelnetReceiver tasks and saves about 3KB. I have kept TelnetConsole
as a separate task from NetManTask. I'm not convinced that combining
the console functionality into NetManTask is a good idea; I'm afraid
it would introduce some problems with interference between various
operations and may get into trouble with the Log() mechanism. Even if
not, much more surgery would be required.
Perhaps a generic extension to ovms_netmanager where you give it a
tcp port and an object type. Then, it listens on that port and
launches objects of that type (pre-configured to receive mongoose
events as appropriate) for each new connection? Have a base virtual
connection class, that gets inherited by each implementation (ssh,
telnet, etc).
I didn't do it that way for this telnet conversion, but we could
evolve to that if appropriate.
Converting ssh may be possible but would be significantly harder. The
libtelnet design calls for all the actual I/O (recv/send) to be done
outside of the library. That fits with the design of mongoose where
it owns that I/O. However, the wolfssh library is designed for the
library itself to be in control of the I/O.
-- Steve
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsdev