[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Internal buffers
[Thread Prev] | [Thread Next]
[Date Prev] | [Date Next]
- Subject: Re: Internal buffers
- From: Aris Adamantiadis <aris@xxxxxxxxxxxx>
- Reply-to: libssh@xxxxxxxxxx
- Date: Fri, 30 Sep 2016 22:44:28 +0200
- To: libssh@xxxxxxxxxx
Hi, From what I understand, you're using libssh on both client and server ends. Problem happens when writing more than 262144 bytes at once in the channel (this magic number is close to the maximum allowed ssh packet size). It doesn't happen on localhost, probably because the lower latency allows the window to grow back quickly before the second smaller message is sent. I think the bug may be related to the way libssh calculates windows, that is not consistent across sending and receiving. Splitting the packets is an appropriate workaround in the meantime that we debug this issue. Thanks for your report, Aris On 30/09/16 15:01, Michal Vaško wrote: > Hello, > we encountered what it seems a rare bug. We tried to send an SSH message of length more than 200kB and most of the time the other end read it correctly, but the message directly following (of length 4B) was lost somewhere. The strange thing is that it did not happen every single time and never when communicating using localhost. > > I tried to debug it myself, but I failed to find the problem. Even when testing it with libssh verbosity 3, all the writes and reads just confirmed this, it was successfully written, but failed to be read. Also, if I divided the big message into at least 2 separate writes, it solved the problem. Did anyone encounter it? Anyone should be able to reproduce it because out software is open-source, link to the github issue [1]. Thank you for any assistance. > > Kind regards, > Michal vasko > > [1] https://github.com/CESNET/Netopeer2/issues/14 >
Internal buffers | Michal Vaško <mvasko@xxxxxxxxx> |