On 5 July 2010 23:38, Julien Viard de Galbert <[email protected]> wrote: > Hello fellow netsed interested people ;) > > netsed does not have UDP support, I plan to implement it, but it's not as > easy as it seams: > UDP is by nature not connected, so it's not possible to know when the client > or server has closed it's socket... > > As the requirement are not clear (I guess user seen netsed fail to work with > UDP have switched to other solutions) I'm planning to take the following > assumption: > > * 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? A use case might involve DNS manipulation - change all responses with one IP address to return another IP address, perhaps. -- Tim Retout <[email protected]> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
