Nmap Development mailing list archives
Re: ncat: using UDP with --chat
From: clemens fischer <ino-news () spotteswoode dnsalias org>
Date: Thu, 22 Oct 2009 13:21:11 +0200
David Fifield:
On Tue, Oct 13, 2009 at 07:08:32PM +0200, clemens fischer wrote:it said: $ ncat -u -l 9999 --chat Ncat: UDP mode does not support connection brokering. If this feature is important to you, write nmap-dev () insecure org with a description of how you intend to use it, as an aid to deciding how UDP connection brokering should work. QUITTING. My idea is to use UDP chat mode as a kind of emergency IPC mechanism together with "--allow" between cooperating processes on machines without eg. posix mesage queues. Connecting clients would tag their messages themselves, like: $ echo "temperature1: 33C" | ncat -u localhost 9999 Other clients would see and evaluate the entire line and respond in a similiar way.Cool, thanks for the note. One of the problems we've had in defining connection brokering for UDP is knowing which clients to relay data to. When the Ncat broker receives the "temperature1: 33C" message, where does it send it? Presumably it should be sent to all interested processes, but the broker has to know about those somehow. One idea we've had is to consider any host that has ever sent UDP data to the broker to be a "connected" client, perhaps with timeouts for inactive hosts. This would require each participating process to "sign in" by sending a message, to make the broker aware of them. Is that something that would work for you? It would help if you would sketch more of the IPC architecture. You've shown how the clients will send to each other; what do they do to receive?
I was thinking about this a bit. Currently I lean towards this idea: Messages are of two categories. Every message starts with a tag, ending in a possibly configurable tag-separator. After the tag-separator can be any text. If that text is empty, the process is indicating interest in further messages of the "type" with this tag. Textual tag-separators in the tag have to be transmitted either escaped with the customary backslash or doubled, ie. given a colon as the tag-separator, "temp\:1:" might be a valid tag, or "temp::1:" (implementors choice). An implementation may choose to allow querying the messages available so far by sending an empty tag. So, sending ":" alone would make the server send back the tags learned so far. This is for monitoring or for "special clients". It would be very nice if the hosts allowed to monitor such a network could be made configurable, but the --allow* and --deny* options should do fine. I like the idea of the timeouts for inactive hosts, but I fear that selecting by "connected on this UDP-port" alone could lead an explosion of message-load. regards, clemens _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
Current thread:
- ncat: using UDP with --chat clemens fischer (Oct 13)
- Re: ncat: using UDP with --chat David Fifield (Oct 15)
- Re: ncat: using UDP with --chat clemens fischer (Oct 22)
- Re: ncat: using UDP with --chat David Fifield (Oct 25)
- Re: ncat: using UDP with --chat clemens fischer (Nov 09)
- Re: ncat: using UDP with --chat David Fifield (Nov 09)
- Re: ncat: using UDP with --chat clemens fischer (Nov 18)
- Re: ncat: using UDP with --chat David Fifield (Nov 24)
- Re: ncat: using UDP with --chat clemens fischer (Oct 22)
- Re: ncat: using UDP with --chat David Fifield (Oct 15)