See my >>s (NB: I snipped some of your stuff to keep the msg length down)
-----Burton
=============================================
> Yes, distinguishing between UDP and TCP would solve this specific case.
And
> that's probably a good thing. Complex, however... you would have to
> potentially double a lot of memory structures or implement some type of
> sparse array...
Umm. I haven't looked at the code (and little good would it do), but isn't a
potential solution just something like tcp_traffic_counter[port]++ and
udp_traffic_counter[port]++?
>>Yes, but - you would have to follow the code and data through EVERY single
>>reference and split the arrays, double elements in various structures,
etc.
<snip>
Perhaps a better (than now) approximation of actual traffic could be
obtained the following way:
Build a static-sized table of 'most recent outgoing and incoming
communication'. This table could be used in an LRU fashion. It contains
entries of the type (originating IP; port; IP protocol; destination IP;
port). Any further communication is matched against these table entries; if
a match is found, the traffic is assigned to the protocol associated with
the destination port used when the entry was created.
Example:
our box at 1.1.1.1 queries a DNS server at 2.2.2.2; the source port is 5900,
the destination port is 53, and the protocol is udp.
We'de have the following table entry:
1.1.1.1; 5900; 17 (for udp); 2.2.2.2; 53
When 2.2.2.2 answers, the program sees that there already is an entry for
2.2.2.2:53 (udp) in the table, and assigns the traffic to DNS.
I'm not sure if I'm making myself clear...?
The size of the lookup table could be a run-time parameter. I guess it's not
its memory consumption that would limit its useful size; lookup times are
more of an issue. A data structure with efficient searching and 'shifting'
would have to be used. ('Shifting' because new entries replace the oldest
ones.)
I'm not saying this is a good solution, just something that could be
considered.
>>Why bother re-inventing the wheel?
>>If you're going to live with the overhead, just pluck the current kernel
state
>>out of /proc/net/ip_conntrack that way you have 1) the same data as the
kernel
>>and 2) live off the kernel's memory allocation.
>>What I don't know is what is the overhead of reading and parsing the
/proc/net
>>data for every single packet... I'm guessing it's a killer, given NTop
can't keep up
>>now with high-traffic situations, hence the accuracy option.
> You could TRY patching the UDP code to try the lower port # first:
This does sound like a good idea, actually. I don't think 'low' port numbers
are often used for outgoing connections (and when they are, the source port
number typically equals the destination port number, as in NTP), so if one
end of the communication uses a privileged port, that is likely to be a
better indication of the protocol than the high client port.
If both ports are 'high', well... It'd be nice if I could tell ntop that for
example anything having to do with my local tcp port 5900 is VNC and should
be classified as such, never mind the other end.
Some kind of 'static mapping' file could be specified on the command line,
with contents like this:
# protocol IP port
tcp 1.1.1.1 1234
udp 2.2.2.2 8080
Later, for communication that matches any of the above lines, source or
destination, is classified using the port number on the line (and the
information from protocols.list).
Actually, a feature like this would solve almost all of my problems
regarding this traffic distribution metering problem.
The only thing left to do would be monitoring protocols other than tcp, udp
and icmp. :)
>> Did you try the patch? I would be interested in knowing if the results
match
>> your needs, before I submit it to Luca...
A happy new year to everyone!
>> Ditto
_______________________________________________
Ntop mailing list
[EMAIL PROTECTED]
http://listmanager.unipi.it/mailman/listinfo/ntop
