Here's a patch that does the steps I mentioned in my last email: - remove BlockingTCP - make send_meta return true on EWOULDBLOCK - add logic to main_loop to watch for write availability of meta connections with non-empty buffers and flush them. It fixes the extra packets with TCPOnly and should resolve the problems that made BlockingTCP necessary also. (No testing of that last bit.) The buffer management is a bit dumb: - it never shrinks the buffer - it copies stuff around more than necessary but it's probably not worth fixing unless someone actually encounters problems. The copying is inefficient, but it's probably negligible compared to doing encryption. It also only flushes after cycling the main loop, so it may even double the iterations of the main loop. So it's probably worth adding some flushes earlier on. This was the simplest thing that works, though. -- Scott Lamb <http://www.slamb.org/> -------------- next part -------------- A non-text attachment was scrubbed... Name: tinc-buffer.patch Type: application/octet-stream Size: 9386 bytes Desc: not available Url : http://brouwer.uvt.nl/pipermail/tinc-devel/attachments/20060113/dbbc3431/tinc-buffer.obj
On Fri, Jan 13, 2006 at 04:41:38PM -0800, Scott Lamb wrote:> Here's a patch that does the steps I mentioned in my last email: > > - remove BlockingTCP > - make send_meta return true on EWOULDBLOCK > - add logic to main_loop to watch for write availability of meta > connections with non-empty buffers and flush them.Adding a buffer and testing for writablity will certainly prevent the problems that make BlockingTCP necessary. But, how large do we allow the buffers to grow? What do we do when it reaches a limit? -- Met vriendelijke groet / with kind regards, Guus Sliepen <guus@sliepen.eu.org> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://brouwer.uvt.nl/pipermail/tinc-devel/attachments/20060114/689add14/attachment.pgp