Re: RFC: BSD Socket (like) API


Paul Sokolovsky
 

Hello Jukka,

On Mon, 27 Mar 2017 12:37:40 +0300
Jukka Rissanen <jukka.rissanen@linux.intel.com> wrote:

[]
The current approach is that we value lightweight nature of Zephyr,
and
looking towards finding a minimal set of changes (additions) to
provide
BSD Sockets *like* API to Zephyr.
The definition of what is BSD Socket *like* system seems to differ
from person to person.
That's true, and the reason why I informally proposed the "process-wise"
definition above: "minimal set of changes (additions) to provide
BSD Sockets *like* API to Zephyr."

For me the current net_context API in Zephyr
is quite BSD socket like, meaning that the API provides similar
functions that are found in BSD socket API like open, close, bind,
connect, accept etc. So it is quite easy to port the application in
this respect.
That's also true, and I right from the start got a habit to call
net_context "a socket". The API calls you mention are all indeed work
(likely almost) the same. The big difference comes with recv() call -
whereas BSD Sockets API has it conventionally pull-style, in Zephyr
it's push-style, where data gets delivered to an app via a callback.
That's one single feature which makes porting 3rd-party applications
complicated and cumbersome.


The bigger difference between BSD socket API and Zephyr net_context
API is:
* net_context API uses net_buf to pass data. The net_buf does not
provide linear memory but data needs to be partitioned when sending
and read in chunks when receiving. We have helpers defined in nbuf.h
for handling reading/writing data in this case. The issue with linear
memory case is that it uses much more memory as we need to be prepared
to receive at least 1280 byte size chunks of data (IPv6 min data
packet size).
Right. And that part is covered by BSD Sockets' own API - the data is
passed via app-owned buffers, not system-owned buffers. That means that
by definition, BSD Sockets don't support zero-copy operation. While an
obvious drawback, it has its positive sides to, like it offers
possibility for better system vs app separation for security.

* The net_context is asynchronous and caller needs to have callbacks
defined. The BSD socket API is synchronous. The net_context can be
used in synchronous way so this is a smaller issue imho.
As you may already noticed, I prefer to call this distinction
"push-style vs pull-style", because it pinpoints the problem better. The
net_context used "in synchronous way" doesn't provide BSD Sockets
behavior for receives. For that to work, incoming (but unprocessed) data
needs to be queue *per socket*, until an app requests it. And indeed,
that's the one big initial change I would need to make.

Having a BSD socket API on top of net_context will use more memory so
if one is concerned about memory consumption, then using native API
should be preferred.
+100, BSD Sockets like API is not a replacement for native API, only a
helper to port existing applications (mostly libraries in the
real-world cases, I may imagine, but only practice will tell how
people will use it).

[]

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

Join devel@lists.zephyrproject.org to automatically receive all group messages.