Re: ncat: using UDP with --chat

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

> David Fifield:

> So, this is really the heart of the issue. Whatever the format of
> the messages, the server has to somehow know what addresses to send
> messages to. The wouldn't be an explosion of messages because we
> would still enforce --max-conns, but we would end up sending messages
> to addresses that no longer care about them. But so far no one has
> offered an alternative implementation idea.
>
> But from your description of the server, I think that simple
> connection brokering is not enough for what you want. Things like
> having the server send back a list of recorded tags in response to a
> ":" will require some domain-specific knowledge in the server. That
> is, unless the "server" of this protocol is different from the Ncat
> server, and connects to the Ncat server as a normal client. But then
> you still have the problem of know who to relay messages to.

I'm not sure how to handle this.  In my original concept the entity now
to be realized by Ncat was only a broker, and it as the only one.  Each
participant could serve and receive messages, and one could have made
one of them an observer just logging and replaying (parts of) messages
on request.  I needed a simple and robust system monitoring facility
back then, without any domain or topology knowledge.

Could Ncat in UDP brokering mode record all connecting clients together
with the their last message and a sequence number?  What I originally
wanted was like this:

                      sender/
  client message      response        Ncat behaviour
  ------------------------------------------------------------
  c-1    temp1: 33C   <N><S1><ok>     register c-1 as sender
  c-2    :            <N><S2><ok>     register c-2 as observer
  c-3    sick: yes    <N><S3><ok>     register c-3 as sender
  c-4    temp1:       <C1><S1>33C     register c-4 as
                                      interested in temp1
  c-5    :            <C2><S2>temp1,  don't register c-5,
                      sick            just make it aware
  c-2    ::           <N><S4><ok>     unregister c-2
  c-6    :            <N><S5><ok>     register c-6 as observer
  c-7    :            <timeout>       nothing, expects c-6 to answer
  c-6    ::           <N><S5><ok>     unregister c-6

  legend:

  <N>       sending party is Ncat
  <Cn>      sending party is client-n
  <timeout> nothing is sent, no state change, an error
  <Sn>      sequence number, relates messages and clients
  <ok>      no response text, but no error either

In this example, c-2 and c-6 are special in that either could become an
observer.  c-2 can handle it for some time and does so, c-6 can not and
unregisters immediately.  There could be a client (c-7) asking for tags
between the time c-6 asks, recognizes the new role it should fulfill and
unregisters.  By that time Ncat has c-6 observer registered and expects
it to answer, but this doesn't happen, as c-6 is not wired as an
observer.

The sequence numbers are meant for clients to know if the value they got
sent is new or an old one.

Clients registering successfully as senders  should store the sequence
number from the response sent by Ncat, because they are responsible for
sending it back once other clients ask for the information.

Does all this make sense?  How does the dbus message bus work with
regard to brokering messages?


gruss, clemens
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/