Live data from Hacker News

WolfIP: Lightweight TCP/IP stack with no dynamic memory allocations

github.com

31–40 of 51 posts

Re: WolfIP: Lightweight TCP/IP stack with no dynamic memory allocations

#31
post #27
post #5

Earlier quoted context omitted.

As the project is GPL’ed I guess they sell a commercial version. GPL is toxic for embedded commercial software. But it can be good marketing to sell the commercial version. Edit: I meant commercial license

“GPL is toxic for embedded commercial software” Why is that?

Many bare metal or RTOS systems consist of a handful of statically linked programs (one or two bootloaders and the main application), many companies would rather find a non-GPL library rather than open up the rest of the system's code. Sometimes a system contains proprietary code that may not be open sourced as well.

Re: WolfIP: Lightweight TCP/IP stack with no dynamic memory allocations

#32

Are there TCP/IP stacks out there in common use that are allocating memory all the time?

Yes, it is pretty common.

However sometimes the buffers are pooled so buffer allocator contention only occurs within the network stack or within a particular nic.

Re: WolfIP: Lightweight TCP/IP stack with no dynamic memory allocations

#33
post #22

Earlier quoted context omitted.

It has a fixed maximum number of concurrent sockets, and each socket has queues backed by per-socket fixed-size transmit and receive buffers (see `rxmem` and `txmem` in `struct tsocket`[1]). This is fine, because in TCP, each side advertises remaining buffer space via the window size header field [2] (possibly with its meaning modified by the window scale option during the initial handshake - see [3] & `struct PACKED…

Ok. So I guess it doesn't try to go very fast.

If it's a memory-constrained embedded device you're sending a handful of bytes of telemetry every now and then, not aiming for gigabit speeds. In fact it couldn't get to megabit speeds even if it wanted to. For something like that this is perfect.

Re: WolfIP: Lightweight TCP/IP stack with no dynamic memory allocations

#34
post #19

Are there TCP/IP stacks out there in common use that are allocating memory all the time?

Yes, TCP is pretty hungry for buffers. The bandwidth*delay product can eat gigs of memory on a server. You have to be ready to retransmit anything that's in flight / haven't received the ack for yet.

Needing memory doesn't have to mean allocating memory over and over. Memory allocation is expensive. If someone is doing that reusing memory is going to be by far the best optimization.

Re: WolfIP: Lightweight TCP/IP stack with no dynamic memory allocations

#35

Earlier quoted context omitted.

It's just not worth it. the only thing keeping it alive is people being overly zealous over it. if the cost to implement is measured as '1', the cost to administer it is like '50'.

what. have you seen ipv4 block pricing?

there keep arising more solutions, public ip usage hasn't been increasing as it did in past decades either. most new device increase is on mobile where cgnat works ok.

Re: WolfIP: Lightweight TCP/IP stack with no dynamic memory allocations

#36
post #12

Earlier quoted context omitted.

It's just not worth it. the only thing keeping it alive is people being overly zealous over it. if the cost to implement is measured as '1', the cost to administer it is like '50'.

Eh. IPv6 is probably cheaper to run compared to running large scale CGNAT. It's well deployed in mobile and in areas without a lot of legacy IPv4 assignments. Most of the high traffic content networks support it, so if you're an eyeball network, you can shift costs away from CGNAT to IPv6. You still have to do both though. Is it my favorite? No. Is it well supported? Not everywhere. Is it going to win, eventually? Pr…

it depends on who you're talking about but no disagreement with cost for ISPs. For endusers (including CSPs) it's another story.

Even on its own it's hard to support, but for most people they have to maintain a dual stack. v4 isn't going away entirely any time soon.

Re: WolfIP: Lightweight TCP/IP stack with no dynamic memory allocations

#37
post #11

Earlier quoted context omitted.

It's just not worth it. the only thing keeping it alive is people being overly zealous over it. if the cost to implement is measured as '1', the cost to administer it is like '50'.

my 15 year old Macbook does IPv6 and IPv4 effortlessly

that's great, but when you have a networking issue, you have to deal with two stacks for troubleshooting. it would be much less effort to use just ipv4.

You're not paying for IPv4 addresses I'm sure, so did ipv6 solve anything for you? This is why i meant by zealots keeping it alive. you use ipv6 for the principle of it, but tech is suppose to solve problems, not facilitate ideologies.

Re: WolfIP: Lightweight TCP/IP stack with no dynamic memory allocations

#38
post #9

It only implements IPv4 which explains to a degree that why IPv6 isn't ubiquitous: it's costly to implement.

Matter (a smart home connectivity standard in use by many embedded devices) is using IPv6. Doesnt seem to be a problem there.

Re: WolfIP: Lightweight TCP/IP stack with no dynamic memory allocations

#39
post #11

Earlier quoted context omitted.

my 15 year old Macbook does IPv6 and IPv4 effortlessly

that's great, but when you have a networking issue, you have to deal with two stacks for troubleshooting. it would be much less effort to use just ipv4. You're not paying for IPv4 addresses I'm sure, so did ipv6 solve anything for you? This is why i meant by zealots keeping it alive. you use ipv6 for the principle of it, but tech is suppose to solve problems, not facilitate ideologies.

> it would be much less effort to use just ipv4.

Or just use IPv6-only. Thats what I do.

Legacy ipv4 only services can be reached via DNS64/NAT64

Re: WolfIP: Lightweight TCP/IP stack with no dynamic memory allocations

#40
post #19

Earlier quoted context omitted.

Yes, TCP is pretty hungry for buffers. The bandwidth*delay product can eat gigs of memory on a server. You have to be ready to retransmit anything that's in flight / haven't received the ack for yet.

Needing memory doesn't have to mean allocating memory over and over. Memory allocation is expensive. If someone is doing that reusing memory is going to be by far the best optimization.

Well, allocating and freeing according to need is reusing. Modern TCP perf is not bottlenecked by that. There's pools of recycled buffers that grow and shrink according to load etc.
Post reply on HN