Re: ncat: using UDP with --chat

[clemens fischer <ino-news () spotteswoode dnsalias org>]

> 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/