lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Micael (abc)
Subject: Re: [lwip-devel] brain storming about "socket2"
Date: Thu, 15 Jan 2009 11:13:16 +0100 (CET)
User-agent: SquirrelMail/1.4.16

Den On, 2009-01-14, 23:53 skrev Jonathan Larmour:
>> :-)
>>
>> Okay, let me rephrase that...


:-) First I think that I need to apologize to everyone, my mail where
perhaps too negative. Thanks for keeping the discussion on the
appropriate level! My worry was for real though, as the picture being
painted in this discussion group re: lwip-sockets is anything but
clear *.

I think I need to explain where I come from;
I have been writing embedded ethernet code for about 9 years now, my
experience mainly comes from proprietary stacks, such as Interniche.
In the beginning, I used the zero copy API's because I liked the idea.
It worked well. But over the years I have grown tired of not being
able to reuse code, and every time re-learn how a particular zero copy
API works. So now, I instead always try to remove the non-socket API's
just because of this from old designs. I think that I increase the
quality of the code this way, since it is less risk that I have
misunderstood the API and so on.
I guess, If you really need to squeeze the maximum bitrate out of a
specific hardware, zc API's is the way to go. Things like routers I
guess.
But for most app's out there, this is not as important, at leas not in
my area of business.

Yes, socket API is old, and not the most efficient. But it is quite
good, and complete, and most of all it is available on many platforms.

Minor difference such as how fdsets are built up and how to set
options etc doesn't bother me too much, in the different socket
implementations.
This is the reason for me to nowadays always go with sockets.

To be fair, I have not looked into netconn API because of this. But
looking at the wiki, it seams there's no select() support for
instance? How would you be waiting for many simultaneous connections?
Because of differences like this, it does not *seam* to be a easy
replacement for the socket API, at least not in a more complicated
environment.


* Coming back to why I am concerned about sockets in lwip: I fully
realize that an open source project is what everyone contributes to
it, but I get the feeling that most of you active developers are not
using the socket API, and too me, it is not clear where you guys as a
community wants to take lwip/sockets. I also see piero struggling with
different issues that from where I stand, looks like real flaws. I may
be wrong on this account, of course (probably I am!), but still this
worries me, since I know how delicate stack coding is:- I would not
mind doing work with lwip, but as you all know, it takes a good deal
of time to get to know a stack well enough to actually make it better
from an architecture point of view.

Having said that, I very much appreciate the tone of every
participants in this group, and your common knowledge.

Cheers,
 Micael




reply via email to

[Prev in Thread] Current Thread [Next in Thread]