<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Strange. When I tested mongoose, I got a close event (<span style="color: rgb(111, 66, 193); font-family: SFMono-Regular, Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 12px; white-space: pre; background-color: rgb(255, 255, 255);" class="">MG_EV_CLOSE</span>) for each open connection, when the interface went down.<div class=""><br class=""></div><div class="">Regards, Mark.<br class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 18 Nov 2017, at 5:05 AM, Stephen Casner <<a href="mailto:casner@acm.org" class="">casner@acm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">There is more to do on this conversion of the Telnet Console to use<br class="">mongoose:<br class=""><br class=""> - When wifi service is shut down by command, my old implementation<br class=""> would close the connections to the clients cleanly. The new<br class=""> implementation with mongoose leaves them hanging. The way to<br class=""> improve this may lie in the shutdown steps in ovms_netmanager.<br class=""><br class=""> - It looks like there may be a memory blocked leaked at each client<br class=""> disconnection. I need to find that.<br class=""><br class=""> - I think I can improve how I handle the receive buffer and save<br class=""> some more RAM.<br class=""><br class="">I've also thought more about how to convert the SSH Console and will<br class="">take a stab at that as well.<br class=""><br class=""> -- Steve<br class=""><br class="">On Fri, 17 Nov 2017, Stephen Casner wrote:<br class=""><br class=""><blockquote type="cite" class="">On Thu, 16 Nov 2017, Mark Webb-Johnson wrote:<br class=""><br class=""><blockquote type="cite" class="">We don't seem to have this issue with the webserver listener; that<br class="">uses mongoose (in netmanager). That doesn't have long-lived client<br class="">side connections, but the socket listen/accept functionality should<br class="">be similar. Not sure how mongoose handles it internally, but the<br class="">library seems quite robust.<br class=""></blockquote><br class="">Mongoose wakes up from the select() periodically to do polling so the<br class="">deletion of the task would not happen while in select().<br class=""><br class=""><blockquote type="cite" class="">I'm wondering if we can migrate to use that? It would probably save<br class="">a bunch of ram (as it doesn't need a task for each thread). We are<br class="">mostly single-user anyway.<br class=""></blockquote><br class="">I have converted console_telnet to use mongoose and netmanager in the<br class="">same manner as ovms_webserver. This eliminates the TelnetServer and<br class="">TelnetReceiver tasks and saves about 3KB. I have kept TelnetConsole<br class="">as a separate task from NetManTask. I'm not convinced that combining<br class="">the console functionality into NetManTask is a good idea; I'm afraid<br class="">it would introduce some problems with interference between various<br class="">operations and may get into trouble with the Log() mechanism. Even if<br class="">not, much more surgery would be required.<br class=""><br class=""><blockquote type="cite" class="">Perhaps a generic extension to ovms_netmanager where you give it a<br class="">tcp port and an object type. Then, it listens on that port and<br class="">launches objects of that type (pre-configured to receive mongoose<br class="">events as appropriate) for each new connection? Have a base virtual<br class="">connection class, that gets inherited by each implementation (ssh,<br class="">telnet, etc).<br class=""></blockquote><br class="">I didn't do it that way for this telnet conversion, but we could<br class="">evolve to that if appropriate.<br class=""><br class="">Converting ssh may be possible but would be significantly harder. The<br class="">libtelnet design calls for all the actual I/O (recv/send) to be done<br class="">outside of the library. That fits with the design of mongoose where<br class="">it owns that I/O. However, the wolfssh library is designed for the<br class="">library itself to be in control of the I/O.<br class=""><br class=""> -- Steve<br class="">_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.teslaclub.hk" class="">OvmsDev@lists.teslaclub.hk</a><br class="">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev<br class=""></blockquote>_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.teslaclub.hk" class="">OvmsDev@lists.teslaclub.hk</a><br class="">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev<br class=""></div></div></blockquote></div><br class=""></div></div></body></html>