FreeLists / openbeosnetteam / [openbeosnetteam] buffer cloning

["Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>]

Hi there,

I'm about to implement buffer cloning. In the current design, any 
changes you make to the underlying data will be shared, too.
That means, that you must not change incoming data (you can remove 
headers, but you must not change the data itself).
I know that I already violated that rule in the ICMP protocol, but that 
may just be a temporary thing :))

Anyway, is that something we can live with? Or should I implement a 
copy-on-write behaviour for them?
I'm not sure how expensive it would be, but we could have smart copy-on
-write (1) and dumb copy-on-write (2) - as well as and dumb-but-risky 
copy-on-write (3):

1) smart:
On changes, it checks if the relevant part of the buffer is shared with 
another buffer. This can be done by checking the reference count of the 
buffer header, and if it's larger 1, we would need to scan all data 
nodes for that buffer.
This way, we would only copy the buffer if necessary, so if we just 
stripped a header, there would be no need to copy the underlying data 
(as we would detect writes to that area later on).

2) dumb:
On all write changes, we copy the buffer if it is shared (ie. has a 
reference count above 1). Depending on the actual usage, this might be 
more expensive than smart copying, though.
Stripping headers could still be ignored (as adding another header 
would be regarded as a copy).

3) dumb-but-risky:
We allow all changes that are not direct write changes. Ie. if you 
remove a header, and then later prepend another one, this change would 
not be detected. It would be in the protocols burden not to do such 
things (and just know it better).

I think that for our needs, dumb-but-risky could be okay, but I'm not 
entirely sure.
To a possible use case, see this example:
        you receive a packet
                a packet monitor gets a copy of it
                a raw listener gets a copy of it
                IPv4 strips its header
                the ICMP protocol gets it, makes some changes to it, and 
replies it.

With 3), the ICMP protocol would need to be smart enough to know that 
it needs another buffer to create the reply packet. With 1) and 2) the 
ICMP protocol would automatically get a copy (and wouldn't need to 
bother). In this case, 3) and 2) would be equally cheap.

Bye,
   Axel.