tunnel upstream is unusably slow

[David Woodhouse]

On Wed, 2014-04-02 at 12:55 +0200, Ortwin Glück wrote:
> Also strace shows that the write() by scp returns EAGAIN very often even
> though the selector gets a signal that the fd is ready for writing:

Thanks for the report.

It would be useful if you were to strace openconnect itself, and see
precisely what it's doing. If you could show the tcpdump both from the
tunnel interface *and* the private network between client and server
while this is happening, it would also be enlightening.

> Maybe it's just (buggy) control of your selectors that is introducing
> the delays, I don't know. But there seems to be a design problem here:
> 
> Looking at the code in mainloop.c I see that input and output are
> handeled by the same thread:

Using a single thread isn't fundamentally bad; it's not hard to get a
state machine right. We shouldn't suffer too much bufferbloat (or TX
starvation due to floods of incoming packets) because we have a limit on
the queue lengths. And if the "do the RX, then do the TX" flow is
actually shown to be an issue then it's easy enough to fix that without
resorting to threads.

Having said that, I *have* considered threads anyway, but for the right
reasons. I want to be able to encrypt outgoing packets and decrypt
incoming packets *simultaneously*, and for that I *do* need threads. I
accept patches :)  But I don't think it's the short-term solution to
your problem.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20140402/1915333f/attachment.bin>