On Tue, Jul 06, 2010 at 10:55:21PM +0100, Tim Retout wrote: > Two options I'm not keen on are: 1) one fork per packet, and 2) > limiting netsed to at most one client. Sure, I didn't want that either...
> I've got a vague intuition that for each new client, you will be able > to create a new socket pointing to the remote host/port. Each of > these should be on a different high port, and replies will come back > to that port, I think? Then you "just" need to pair up client > addresses with remote sockets, and have a 30s timeout on the remote > sockets to clean them up after we're done waiting for replies. Well yes, that about what I was thinking by "connection tracking", it's implemented now ! > So yes, this is "connection" tracking, but should not be *that* > difficult to implement (although I have not done it myself). I'm > assuming the tcp implementation also uses select() now. Well, the tcp implementation was still using fork, now the code is shared with udp so no more forks :) I still have to write some udp tests and pack a release, but the code is on my public git. Best regards Julien VdG -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
