[email protected] (Niels Möller) skribis: > [email protected] (Ludovic Courtès) writes: > >> lshg/lsh (as of lsh 2.1 on GNU/Linux, x86_64) systematically fails for >> me when passed large data streams on stdin: >> >> --8<---------------cut here---------------start------------->8--- >> $ lsh -G -B fencepost.gnu.org >> Passphrase for key `xxx@yyy': >> >> $ lshg fencepost.gnu.org uname -o >> GNU/Linux >> >> $ cat /dev/zero | lshg fencepost.gnu.org md5sum >> lsh: Protocol error: Write buffer full, peer not responding. >> lsh: write_buffer: Attempt to write data to closed buffer. > > ... > >> Conversely, this works well: >> >> --8<---------------cut here---------------start------------->8--- >> $ cat /dev/zero | lsh fencepost.gnu.org md5sum > >> Any idea what’s wrong or how to debug it?
[...] > Now, I think the problem is that the code reading from a gateway client > socket doesn't check if hard_limit > 0. Not entirely trivial to fix. > What needs to be done is to > > 1. Make gateway_commands.c:do_read_gateway check that flag, > > if (self->connection->chain->hard_limit) > ... > In this case, return zero, but we also need to stop reading from the > socket. Maybe one can have the caller, io.c:do_buffered_read, check if > the return value is zero, and call lsh_oop_cancel_read_fd? > > 2. Somwhow use the wakeup mechanism (invoked from > connection.c:do_connection_flow_controlled) to restart reading from > the gateway socket. Any update on that? :-) Thanks, Ludo’. _______________________________________________ lsh-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/lsh-bugs
