Ip_conntrack extend mechanism and extension

Ip_conntrack adds a stream record mechanism for stateless IP addresses. Where can you store anything related to a stream? In principle, ip_conntrack should be something that can be infinitely expanded, but in fact, the kernel designer or the ip_conntrack designer of Netfilter did not leave any interfaces and mechanisms for user programmers to extend it, you can only use the existing Connection Tracing Mechanism. Although you can use the nf_ct_extend_register interface to register an nf_ct_ext_type, this interface is only used by the kernel source code tree. You cannot define an external nf_ct_ext_type.
Since there is an nf_ct_extend_register, why not set an nf_ct_ext_type from the outside and register it? Apart from the data structure defined in C language, I cannot explain myself to implement deserialization. I think this is a defect in the ip_conntrack code tree, but it may be caused by the difference between the kernel development mode and the application development mode. In general, the kernel API is very unstable. For applications, the kernel system call interface should be as stable as possible. As for internal systems, it is completely a black box. In addition, kernel development requires a certain degree of knowledge, not only you are familiar with some programming skills and familiar with API documentation. The above reason, or my personal guess, has led to the failure to make any modifications to the structure of ip_conntrack. All you can do is implement the logic. How does the Linux kernel implement this restriction? It's easy to put the relevant header file into the header file directory of kernel development. In fact, as long as it is the header file of that directory, you don't expect to modify any struct and declarations, because those are involved in the CRC calculation.
After understanding that the extend of ip_conntrack is not actually scalable, the following shows how the old wet is extended. First, let's take a look at how the extend structure of ip_conntrack is organized. In fact, I think this kind of organization is very good, very compact, and not prone to memory fragments. It is so compact because all extend-related content is continuous in the memory. Continuous memory, of course, does not have non-sequential memory for pointer addressing, but it is also good to use the offset. The bigger advantage is the comparison of application/copy/release, so you do not need to consider the issue of deep copy and shallow copy. Similar data structures include the representation of iptables rule in the kernel.
The biggest advantage of the continuous memory representation is that it can be expanded at will, because it relies entirely on offsets to locate the location. If you know OO languages such as C ++ and JAVA, you will know that, in the memory layout of a common class, the base class is always at the beginning. The so-called extension is at the memory position followed by the base class, thus forming a subclass, of course, this is just for implementation. Here we will not talk about ideas! Of course, this is not a sexual reproductive behavior, because sexual reproduction has never been continuous. You cannot say that a child is a father (a part of a father ...), however, in the continuous memory world, we can say:

struct B {       struct A a;       ....       char *privatedata};

It is A struct a. After all, I can cut out the fields of struct B following field. After knowing all this, I can extend all the nf_ct_ext_types predefined for any Linux system! In fact, I only need to extend a pointer! Although I advocate the layout of continuous memory, I still prefer flexibility. After all, the current Memory price is no longer expensive. Why do I care about the memory. Just expand a pointer. You can interpret it as a mechanism! Let's use a picture to explain:

After understanding the figure above, you can understand the definition below. You don't need to change the structure of nf_conn_counter, just change the size of it, that is:

struct nf_conn_counter {    u_int64_t packets;    u_int64_t bytes;};

The size of is not sizeof (struct nf_conn_counter), but sizeof (struct nf_conn_counter) + sizeof (char *), which is defined:

struct nf_conn_counter {    u_int64_t packets;    u_int64_t bytes;    char *p;};

However, this changes the definition of the nf_conn_counter struct. However, considering the above struct, the memory structure is equivalent:

struct my_st {    struct nf_conn_counter nfc;    char *p;};

In this way, the definition of the struct is not changed. In fact, the struct my is actually "A" struct nf_conn_counter. After that, there will be no more changes to it, only modify the len field of nf_ct_ext_type. The rest of the work is to set or retrieve the custom struct as follows:
Struct my_st * ms = (struct my_st *) a_instance_of_struct_of_nf_conn_counter;
Retrieve the pointer of my_st. Next, you can access p in my_st. The author explains what p is. Why do I not advocate continuous memory but use a pointer? The key is that I don't think every conntrack needs this field. To save the memory, I only need to use pointers to allocate memory for the required struct.
This is the old wet practices, JAVA programming ideas, really have ideas. The old wet is very low-level, does not know programming, does not conform to the taste of programming experts, but the old wet understand wet thinking, old wet know how cruel the world of this machine to enable people, how sad a digital world is, it is hard for programmers to understand, especially those who live on programming...