<div class="gmail_quote">I asked this question onĀ  Stackoverflow (even offered a bounty) and IRC:<br><br><a href="http://stackoverflow.com/questions/13117502/twisted-conch-flow-control" target="_blank">http://stackoverflow.com/questions/13117502/twisted-conch-flow-control</a><br>

--<br><div>
        <p>I have a Twisted Conch SSH server and the typical scenario is this:</p>

<p>git via OpenSSH client   &gt;&gt;--- WAN1 ---&gt;&gt; Twisted conch svr &gt;&gt;--- WAN2 --&gt;&gt; Git server</p>

<p>There will be occassions that the &#39;git push&#39; is sending data faster 
over WAN1 than I can proxy it over WAN2, so I need to tell the client to
 slow down (well before any TCP packet loss causes adjustments the TCP 
window size) to avoid buffering too much on the Twisted server. Reading 
the RFC for SSH this is accomplished with not acknowledging via adj 
window this will then cause the git push to block on syscall write to 
the pipe backed by openssh. </p>

<p>Looking at conch/ssh/connection.py:L216 in the method  def 
ssh_CHANNEL_DATA(self, packet):
I can accomplish this with setting localWindowSize to 0, and inflight 
data will still land as the predicate on 230 should still pass (give 
localWindowLeft). I am wondering if this is the correct approach or am I
 missing something blindly obvious with regards to flow control with 
Twisted SSH Conch? *</p>

<p>Note: I acknowledge there are methods placeholders for stopWriting 
and startWriting on (channel) that I can override so I have hooks to 
control the other side of the transmission &#39;git pull&#39;, but Im interested
 in first leg. Also IPush/IPull producer dont seem applicable at 
this level and I cant see how I can tie in these higher abstraction 
without butchering conch? </p><span class="HOEnZb"><font color="#888888">

    </font></span></div><span class="HOEnZb"></span>-- <br></div>Matt Freeman - @nonuby - <a href="http://blog.nonuby.com" target="_blank">http://blog.nonuby.com</a><br><br>