On Tue, Jul 06, 2010 at 12:08:01AM +0100, Tim Retout wrote: > On 5 July 2010 23:38, Julien Viard de Galbert <[email protected]> wrote: > > > > * whenever a client send a datagram to a server it expects one and only > > one datagram back > > I think this is quite limiting. There is no concept of a "connection", > so datagrams are not related to each other in this way. It would just > about handle DNS, but what if a client makes several DNS requests in > quick succession? What if packets get lost (since UDP does not > guarantee reliability)? It seems like an awful lot of fork() calls. > > netsed does not need to know when either end closes the socket - it > can just sit there listening forever, and forwarding on data as it > gets received. So, you probably need a select() loop to wait for new > data, read some in, and then send it on... is forking necessary?
Well I see your point, when it comes to sockets, forking is never necessary, it's just sometime easier... So for the client to server datagram it's easy, it becomes: client to netsed and netsed to server, and netsed can blindly forward everything. 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. Should I implement some kind of connection traking as described here: http://www.sns.ias.edu/~jns/wp/2006/01/12/iptables-connection-tracking-udp/ That's looking like the thing to do to me, but this whould be a major change to netsed's architecture... and a lot more work than expected :) > A use case might involve DNS manipulation - change all responses with > one IP address to return another IP address, perhaps. Well for DNS it's probably as easy to setup dnsmasq (and it's already working), but why not ! Julien VdG -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
