Miguel A.L. Paraz wrote:
> I'm working with a router which can dump copies of all IP headers it sees to
> a UDP port on a given host.
Ok, so you just want to write a drain and filter program.
> I'm now looking into how to write the code that will decipher the headers.
> All I need are the source and destination addresses and ports, and the length
> of the packet, for traffic accounting purposes.
You're asking a rather general question concerning program design and
approach, rather than a specific technical question. So the answer
will be rather more vague than a "do this, then that".
First, you need to know two specifics:
1. What is the record size of each transaction from the router.
2. What is the specific layout of the record from the router
(i.e., how many fields, ASCII or binary, how many bytes per field)
Note that life gets a bit more complicated if the router writes
variable- length records; in that case, you have to determine how to
delineate a record from the input stream. This is usually based on
either a fixed- length leader field that tells you the number of bytes
in the following data portion of the record, or a specific delimiter
denoting end of record. Fixed-length records make the data capture
part of the program easier.
Next, segregate your program by function. You've four main functions:
1. Data capture
2. Packet disassembly
3. Data interpretation
4. Logging
Data Capture
============
The data capture routine(s) should deal only with opening the socket,
conditioning it, and then reading a record or, after you're sure the
data capture is working correctly, integral multiples of records for
efficency. Don't hard-code that; make the buffer size/read request a
tunable so you can play with the buffering.
Note also that if the data throughput is very high, you'll
probably want to write the data capture routine as a separate process
that you can run at a high priority, and transfer its data to another
process that does packet disassembly, interpretation and logging
Packet Disassembly
==================
If you read multiple records, have a packet disassembly layer that
accepts buffers from the data capture routines and produces individual
raw records. This will be a pass-through for cases where the buffer is
only one record.
The next layer should disassemble the packet from the raw ASCII or
binary input into a data structure. Your call whether to discard
fields in which you have no interest at this time, or to retain the
entire structure. I would do the latter, since in debugging you could
then see that you're properly interpreting the raw data, and if in the
future you have any interest in any of the other fields, they're
already parsed and interpreted.
In this layer you also decide on any data conversions, e.g., ASCII to
binary for the packet length.
Data Interpretation
===================
Select the fields of interest if you've left the entire record intact in
the data structure. Compute any intermediate statistics or values (e.g.,
number of packets processed so far, local timestamping, etc.).
Logging
=======
A set of routines solely involved in the tasks of opening and
maintaining the log file or mechanism (e.g., syslog), and formatting
the filtered data and/or statistics provided by the data interpretation
routines.
---------------------------------------------------------------------
I hope this helps. I have a couple of programs that were written as an
example of how to open and write to, and open and read from, a standard
socket, if you'd like.
This should take an experienced developer about 2 days to complete, with
testing, documentation, meetings, and doughnut breaks.
Cheers,
--
Dave Ihnat
[EMAIL PROTECTED]
--
To unsubscribe:
mail -s unsubscribe [EMAIL PROTECTED] < /dev/null
