Re: [lwip-devel] brain storming about "socket2"

[Jonathan Larmour]

Micael (abc) wrote:
> Den On, 2009-01-14, 18:12 skrev Jonathan Larmour:
> 
>>> The present sockets API is only really there as a way for people to port
>>> existing code for less effort. It's not a great choice for writing
>>> something new.
> 
> Interesting! Is that the boiled down truth? I was about to use lwip for my
> new project, which will not use anything but socket interface!! While I
> can certainly understand the need for something lighter in a few
> particular places, I would never consider using anything but sockets for a
> new project myself. I guess I'll be heading back to Interniche if that is
> the case.
> Well, I guess better hearing this now, than later, so thanks for that
> insight!

:-)

Okay, let me rephrase that... it's not the /best/ choice for writing
something new. The netconn API has almost identical concepts, with in some
cases an intrinsic speed advantage that anything using a sockets API
(interniche or otherwise) can't have[1]. If you understand sockets, you'll
understand the netconn API just fine. socket() becomes netconn_new(),
bind() becomes netconn_bind, connect() becomes netconn_connect() etc. so
it's the same concepts - it's only the management of data (using netbufs)
which is different. That's the point of the API - it isn't as "different"
as the raw API, but it can be more efficient than something that a sockets
API (and I mean *any* sockets API, including in Interniche) can manage.

The sockets API (and I mean this generally, not just for lwIP) simply isn't
a great API for efficient operation. Use it if you want portable code by
all means. Or if you don't have time to make the small step of looking at
the netconn API. That's why lwIP has it. But otherwise, if you're looking
for a _lightweight_ IP stack, why not use something more efficient?

An early 1980s bolt-on to a file access API designed for UNIX running on
VAX minicomputers is not necessarily the best choice for modern embedded
systems.

Jifl
[1] netbufs used with the netconn API directly become the pbufs which are
passed to the hardware driver. For those of us using zero-copy drivers in
particular, this is a big win. There's also less indirection intrinsic to
the API itself.
-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------       Opinions==mine