start documenting the packet class family - explain why deriving from QObject is clever

1 files changed, 50 insertions, 17 deletions

diff --git a/libopie2/opienet/opcap.h b/libopie2/opienet/opcap.h
index 6bf7416..fe88e68 100644
--- a/libopie2/opienet/opcap.h
+++ b/libopie2/opienet/opcap.h
@@ -70,3 +70,45 @@ class QSocketNotifier;
  *======================================================================================*/
-// FIXME how many OPackets do we've at a time? QObject seams to be a big for that usage
+
+/** @brief A class representing a data frame on the wire.
+ *
+ * The whole family of the packet classes are used when capturing frames from a network.
+ * Most standard network protocols in use share a common architecture, which mostly is
+ * a packet header and then the packet payload. In layered architectures, each lower layer
+ * encapsulates data from its upper layer - that is it
+ * treats the data from its upper layer as payload and prepends an own header to the packet,
+ * which - again - is treated as the payload for the layer below. The figure below is an
+ * example for how such a data frame is composed out of packets, e.g. when sending a mail.
+ *
+ * <pre>
+ *                                                       | User Data |     == Mail Data
+ *                                         | SMTP Header | User Data |     == SMTP
+ *                           | TCP Header  | SMTP Header | User Data |     == TCP
+ *               | IP Header | TCP Header  | SMTP Header | User Data |     == IP
+ *  | MAC Header | IP Header | TCP Header  | SMTP Header | User Data |     == MAC
+ *
+ * </pre>
+ *
+ * The example is trimmed for simplicity, because the MAC (Medium Access Control) layer
+ * also contains a few more levels of encapsulation.
+ * Since the type of the payload is more or less independent from the encapsulating protocol,
+ * the header must be inspected before attempting to decode the payload. Hence, the
+ * encapsulation level varies and can't be deduced without actually looking into the packets.
+ *
+ * For actually working with captured frames, it's useful to identify the packets via names and
+ * insert them into a parent/child - relationship based on the encapsulation. This is why
+ * all packet classes derive from QObject. The amount of overhead caused by the QObject is
+ * not a problem in this case, because we're talking about a theoratical maximum of about
+ * 10 packets per captured frame. We need to stuff them into a searchable list anyway and the
+ * QObject also cares about destroying the sub-, (child-) packets.
+ *
+ * This enables us to perform a simple look for packets of a certain type:
+ * @code
+ * OPacketCapturer* pcap = new OPacketCapturer();
+ * pcap->open( "eth0" );
+ * OPacket* p = pcap->next();
+ * OIPPacket* ip = (OIPPacket*) p->child( "IP" ); // returns 0, if no such child exists
+ * odebug << "got ip packet from " << ip->fromIPAddress().toString() << " to " << ip->toIPAddress().toString() << oendl;
+ *
+ */
+
 class OPacket : public QObject
@@ -97,3 +139,2 @@ class OPacket : public QObject
 
-//FIXME same critic as above -zecke
 class OEthernetPacket : public QObject
@@ -118,3 +159,3 @@ class OEthernetPacket : public QObject
  *======================================================================================*/
-//FIXME same
+
 class OWaveLanPacket : public QObject
@@ -148,3 +189,3 @@ class OWaveLanPacket : public QObject
  *======================================================================================*/
-//FIXME same as above -zecke
+
 class OWaveLanManagementPacket : public QObject
@@ -177,3 +218,3 @@ class OWaveLanManagementPacket : public QObject
  *======================================================================================*/
-//FIXME is QObject necessary? -zecke
+
 class OWaveLanManagementSSID : public QObject
@@ -195,3 +236,3 @@ class OWaveLanManagementSSID : public QObject
  *======================================================================================*/
-// FIXME same as above -zecke
+
 class OWaveLanManagementRates : public QObject
@@ -212,3 +253,2 @@ class OWaveLanManagementRates : public QObject
 
-//FIXME same....
 class OWaveLanManagementCF : public QObject
@@ -229,3 +269,2 @@ class OWaveLanManagementCF : public QObject
 
-//FIXME same
 class OWaveLanManagementFH : public QObject
@@ -245,3 +284,3 @@ class OWaveLanManagementFH : public QObject
  *======================================================================================*/
-//FIXME same
+
 class OWaveLanManagementDS : public QObject
@@ -264,3 +303,2 @@ class OWaveLanManagementDS : public QObject
 
-//FIXME guess what?
 class OWaveLanManagementTim : public QObject
@@ -281,3 +319,2 @@ class OWaveLanManagementTim : public QObject
 
-//FIXME same as above ( Qobject )
 class OWaveLanManagementIBSS : public QObject
@@ -330,3 +367,3 @@ class OWaveLanDataPacket : public QObject
  *======================================================================================*/
-// Qobject needed?
+
 class OWaveLanControlPacket : public QObject
@@ -347,3 +384,2 @@ class OWaveLanControlPacket : public QObject
 
-// QObject needed?
 class OLLCPacket : public QObject
@@ -357,3 +393,2 @@ class OLLCPacket : public QObject
   private:
-  //FIXME how to get that header?
     const struct ieee_802_11_802_2_header* _header;
@@ -365,3 +400,2 @@ class OLLCPacket : public QObject
 
-// Qobject as baseclass?
 class OIPPacket : public QObject
@@ -392,3 +426,3 @@ class OIPPacket : public QObject
  *======================================================================================*/
-// QObject?
+
 class OUDPPacket : public QObject
@@ -412,3 +446,2 @@ class OUDPPacket : public QObject
 
-// Qobect needed?
 class OTCPPacket : public QObject