On Thu, 1 Sep 2011, Henrik Nordström wrote:

all are situations where libssh2 may want to internally send a packet in response to other activity, which will fail if the transport is currently blocked.

I've been thinking a bit about this general API problem.

Perhaps we need to remake the parts dealing with the channel layer, to always have a queue for outgoing packets and always when we get something to send to the remote side we convert the entire thing into a complete SSH packet. If that blocks, we'll need to keep the unsent part around until libssh2 gets called again.

If then another function wants to send data over the channel, that would just add a packet to the outgoing queue and thus not ruin the half-unsent packet that's already sitting waiting in the queue.

--

 / daniel.haxx.se
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel

Reply via email to