On 6 July 2010 09:51, Julien Viard de Galbert <jul...@vdg.blogsite.org> wrote: > But for the way back, server to client it's different: > The server will likely send a message back to the client, that is to say it's > IP and port number (this one is dynamic!). > So with netsed, the server sends a datagram to (one of) netsed's client socket > (with a dynamic port) then netsed has to retrive the corresponding client ip > and port to forward the datagram.
I see, that would be complicated. Two options I'm not keen on are: 1) one fork per packet, and 2) limiting netsed to at most one client. 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. 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. -- Tim Retout <t...@retout.co.uk> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
