วันก่อนคุยกับอาจารย์ก็ถามแกว่า
| What do you think about implementing in OOP language like Java instead C?
แกก็บอกว่า
OOP is certainly possible, but much of what needs to be done probably
can't be done in Java.

Analysis could, data retrieval and archiving etc could, but actual packet
capture can't, or at least, can't any way I know of. Aside from anything
else, this needs to be very very fast, if it is to catch every packet
(a GBps network with minimum sized packets can carry about 2 million
packets a second - that means, capturing the packet, analysing it,
and saving whatever state needs to be saved needs to be able to be done
in about 1/2 microsecond per packet (average) - or at least something
approaching that, if it takes 1 microsecond, half the packets get missed).

You don't need to give me the java sales pitch, I know what it is good
for, and what it isn't.
เจอแบบนี้...หน้าหงายย

There is no requirement that all the parts of this project be implemented
in the same language though, if java is better for some parts, that's fine.

It does have to all run on unix type systems though, and lots of them.

ก็เลยถามอีกไปว่า
| Well,If Java is too slow for this situation.what about C# running on mono?

I don't know enough about C# to know - what's important is that you can
link to C library code, because that's what the library that actually fetches
the packets is written in, and you certainly want to use that, not attempt
to do it all by yourself.


| If I use C++ or C for all part may be there are a lot of bugs.

That's not necessarily a bad thing ... Finding them helps you learn.
แฮะๆ..ยิ้ม ^^ คงม่ายหวายม้าง..segmentation fault เอาง่ายๆ อะดิ

| Anyway,why does statspy and collect run on differrent platforms?that I know
| statspy runs on SunOS and collect runs on *BSD.Is there some significant?

They don't have to. collect will run on just about anything - it's just
a simple network application that reads data. statspy is the process
(in NNStat) that actually fetches the packets from the net and analyses them.
That didn't use the pcap library (which didn't exist when NNStat was initially
written), so did the packet fetching itself - that's a very system dependent
operation, the way it is done varies from one system to another. That's
partly why NNStat no longer works on anything that matters - the methods
that statspy used to collect packets don't exist on modern systems.

The reason the two processes are separate, and don't need to run on the same
system (though they can) is to allow staspy processes to be put on all the
systems on the network that are necessary to monitor all of the traffic (a
statspy can only see packets on nets that it connects to). On the other hand,
it is usually more convenient if all the data collection, and analysis, is
done on one central system. That's where collect runs. If there's only
one LAN to monitor, then statspy can run on a system connected to it, and
collect may as well run on the same system. If there are 20 or 30 LANS to
monitor, statspy can run on a system connected to each, then collect just
run on one system, talk to each of the statspy processes, and get the data
from them, saving it all locally.

This is the right model to use, with the collection and the archiving/analysis
parts of the overall process separated.

It is only the packet collection part which needs to be fast, it is also the
only part that needs to be linked with the pcap library - the data collection,
and analysis (report generation) stuff can be written in anything that you
like.

kre

ขอบคุณฮะอาจารย์