Re: [lwip-devel] more about SO_REUSE and UDP

[Leon Woestenberg]

Hello all,

address@hidden wrote:

> Or better, can Kieran or Florian indicate if they really need patch #1399?
> If it isn't used, and it is not tested, err, why not remove it?
> (and keep things really simple and light weight...)
I guess the patch is OK; it adds typical TCP/IP stack capabilities for 
the socket layer.

However, when SO_REUSE is on, it no longer allows the core low-level API
to support re-used addresses.

> It looks likes the patch changes the behaviour of the PCB API.
Yup... that's why it was disabled through the define's.

> A radical idea: maybe the (udp) pcb list could be turned into
> some sort of (c++ like) map where only unique entries are stored.
>
> This keeps the list as short as possible, and improves search
> speed for unwanted (netbios etc) traffic. Sorting the list as Leon
> mentioned previously works for wanted (reference counted) traffic only.
Good point.

For optimal lookup behaviour (on heavy traffic networks) the alternative
is to have dummy PCB's in the UDP/TCP list, that have a new PCB_DROP 
flag set.

This way, the PCB's *can* be sorted by most-targetted destination port 
to least-targetted port, dynamically with reference count and the 
overall lookup time is reduced to a minimum. Increased overhead due to
sorting though.

Alternatively, maybe there is interest in a option lean and mean (port
based) firewall that simply has a {port, incoming_count, action}
tripplet that is sorted in the same way.

Or, a simple array of length NUM_UDP_PCB, that holds a sorted list of 
used ports to quickly decide whether to drop the packet early.

The latter two approaches would allow re-use of the filter also during
early-reception which some Ethernet chips support. For example, the
cs8900 can generate an early interrupt as soon as only the first part of
a frame is received. The interrupt routine could then do a filter
lookup to early-drop the packet.

However, this would need the lwIP code to temporarely disable the 
Ethernet chip interrupt whenever the filter is modified, due to 
concurrency/race conditions.

Just some thoughts. I think Luke was also doing some work on efficient
lookups.

Regards,

Leon.