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