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>
